История версий
Требования

Введение

Быстрый старт

Развертывание

Моделирование данных

Подключение

Запись данных

Миграция

Запросы

Операции и обслуживание

Настройка производительности

Устранение неполадок

Справочник

Справочник по SQL

Часто задаваемые вопросы

Миграция данных из MatrixDB 4 в MatrixDB 4

Данный раздел документации в основном представляет лучшие практики миграции данных из MatrixDB 4 в MatrixDB 4.

1. Подготовка среды

После принятия решения о выполнении важной операции необходимо тщательно подготовиться, как в практическом, так и в психологическом плане (поскольку вы можете столкнуться с проблемами в любой момент). Психологическая подготовка у каждого своя. Мы предоставим вам относительно полный план, включая опциональные шаги, как показано ниже:

Номер Шаги подготовки Инструкции Опционально
1 Резервное копирование данных кластера источника Миграция данных выполняет только чтение из кластера источника, не производя запись, поэтому не вызывает риска повреждения данных Да
2 Установка и развертывание целевого программного обеспечения базы данных Нет, обязательный шаг
3 Развертывание мониторинга для целевого кластера Зависит от требований Да
4 Запретить все DDL-операции со стороны бизнеса Этот шаг критически важен и может создать риски для процесса миграции. Отнеситесь к нему серьезно. Нет, обязательный шаг
5 Прервать все бизнес-соединения Этот шаг критически важен и может создать риски для процесса миграции. Отнеситесь к нему серьезно. Нет, обязательный шаг
6 Сбор информации о кластере источника и целевом кластере Информация о программном и аппаратном обеспечении, топология кластера источника, топология целевого кластера и т.д. Нет, обязательный шаг
7 Резервное копирование исходной информации кластера источника DDL, имена схем, информация о пользователях и т.д. Нет, обязательный шаг
8 Добавить белый список на все узлы кластера источника и целевого кластера Нет, обязательный шаг
9 Создать пользователя для целевого кластера Нет, обязательный шаг
10 Создать DDL для целевого кластера В MatrixDB пересоздание индексов после выполнения операций миграции более эффективно. Поэтому при создании DDL для целевого кластера до миграции рекомендуется создавать инструкции без индексов Нет, обязательный шаг
11 Восстановить структуру таблиц Нет, обязательный шаг

На основе приведенной выше таблицы приведем конкретные примеры.

1.1 Резервное копирование данных кластера источника

Миграция данных выполняет только операции чтения и не производит запись в данные кластера источника, поэтому не влечет риска повреждения данных. Однако, если вы все еще обеспокоены или имеете другие бизнес-требования, требующие сохранения данных, вы можете использовать инструмент mxbackup для выполнения параллельного резервного копирования кластера.

1.2 Установка и развертывание целевого программного обеспечения базы данных

Примечание!
Рекомендуем не развертывать зеркальные узлы (Mirrors) при развертывании кластера, а добавлять их после завершения миграции для повышения эффективности.

Примечание!
Имена хостов целевого кластера не должны совпадать с именами хостов кластера источника!

См. стандартную документацию по развертыванию кластера:

1.3 Развертывание мониторинга для целевого кластера

См. документацию по мониторингу и оповещениям:

1.4 Запретить все DDL-операции со стороны бизнеса

Примечание!
До официальной остановки всех сервисов со стороны бизнеса на стороне кластера MatrixDB 4 источника не допускается выполнение любых DDL-операций, включая создание объектов, изменение объектов, добавление или удаление полей, а также запрещается выполнение команд CREATE, ALTER, TRUNCATE и DROP.

1.5 Прервать все бизнес-соединения

Измените файл pg_hba.conf на мастере кластера MatrixDB 4 источника.

$ vim  pg_hba.conf

Добавьте адреса клиентов бизнеса в следующем формате, чтобы отключить удаленный доступ.

host     all         all         <Client IP Address>/<Subnet Mask Bits>       reject

Затем перезагрузите конфигурацию, чтобы применить изменения:

$ gpstop -u

1.6 Сбор информации о кластере источника и целевом кластере

Соберите информацию о кластере источника и целевом кластере, включая количество физических машин, операционную систему, процессоры, память, тип дисков, использование дисков, информацию о сетевых картах, топологию кластера источника, топологию целевого кластера, лицензию базы данных, конфигурацию групп ресурсов и т.д. Используйте эти данные в соответствии с конкретным сценарием для всесторонней подготовки к миграции. Ниже приведены возможные команды:

Номер Команда Цель
1 free -g Просмотр информации о памяти операционной системы
2 lscpu Просмотр количества процессоров
3 cat /etc/system-release Просмотр версии операционной системы
4 uname -a Вывод всей информации ядра в следующем порядке (результаты -p и -i опущены, если они не определены): имя ядра; имя хоста в сети; номер выпуска ядра; версия ядра; имя аппаратной архитектуры хоста; тип процессора (не переносимо); аппаратная платформа или (не переносимо); имя операционной системы
5 tail -11 /proc/cpuinfo Просмотр информации о процессоре
6 gpcheckperf Проверка производительности сети, пропускной способности и дискового ввода-вывода

1.7 Резервное копирование исходной информации кластера источника

Под суперпользователем используйте инструмент pg_dump для резервного копирования DDL, имен схем, информации о пользователях и т.д. кластера MatrixDB 4 источника.

# Backup global user objects
$ pg_dumpall -g -f global_user.sql

# Backup table structure
$ pg_dump <Source Database Name> -s -f orig.sql          

# Copy a backup
$ cp orig.sql copy.sql

Создает SQL-файл с инструкциями для создания индексов.

$ cat get_index.sql 
WITH soi (oid, toid, SIZE, tschema, tname) AS
  ( SELECT soioid,
           soitableoid,
           soisize,
           soitableschemaname,
           soitablename
   FROM gp_toolkit.gp_size_of_index 
  ),
  childrel (oid, coid)AS
  ( SELECT t.parentrelid::oid, 
           t.relid::oid 
    FROM pg_partitioned_table, pg_partition_tree(partrelid) t 
    where t.isleaf
  ),
  irn (oid, toid, SIZE, tschema, tname, rn) AS
  ( SELECT *,
           row_number() OVER (
            ORDER BY dt.ssize DESC) rn
   FROM
     ( SELECT soi.oid,
              soi.toid ,
              sum(coalesce(dt2.SIZE, soi.SIZE)) ssize ,
                                                soi.tschema,
                                                soi.tname
      FROM soi
      LEFT JOIN
        ( SELECT childrel.oid,
                 soi.SIZE
         FROM soi
         INNER JOIN childrel ON soi.toid = childrel.coid ) dt2 ON soi.toid = dt2.oid
      GROUP BY 1,
               2,
               4,
               5 ) dt )
SELECT SQL || ';'
FROM
  ( SELECT pg_get_indexdef(oid) AS SQL ,
           (rn % 12 + (rn / 12)::int) % 12 AS orderkey
   FROM irn
   WHERE toid NOT IN
       (SELECT coid
        FROM childrel) ) dt
WHERE SQL NOT LIKE 'CREATE UNIQUE INDEX%'
ORDER BY dt.orderkey ;

Выполните вышеуказанный SQL через psql.

$ psql -d <Source Database Name> -U mxadmin -t -f get_index.sql > index.sql

1.8 Добавить белые списки на все узлы кластера источника и целевого кластера

Примечание!
Если кластер источника и целевой кластер работают на одном сервере, этот шаг можно пропустить.

На мастере кластера источника и целевого кластера выполните следующую команду, чтобы добавить IP-адреса всех узлов кластера источника и целевого кластера в файл pg_hba.conf. В примере IP-адрес и маска подсети — 172.16.100.2/32 и 172.16.100.3/32.

Примечание!
Если имеется несколько хостов, необходимо указать все IP-адреса в скрипте.

$ cat  config_hba.sh
#!/bin/bash
for line  in `psql -Atc "select hostname||','|| datadir
 from gp_segment_configuration order by datadir desc"`
do
    hostname=`echo $line|awk -F "," '{print $1}'`
    datadir=`echo $line|awk -F "," '{print $2}'`

    gpssh -h $hostname -v -e "echo host    all    all    172.16.100.2/32    md5>> ${datadir}/pg_hba.conf"
    gpssh -h $hostname -v -e "echo host    all    all    172.16.100.3/32    md5>> ${datadir}/pg_hba.conf"

done

In the source cluster and the target cluster master, execute the following command to add the host IP address and host name of all nodes of the source cluster and the target cluster to the /etc/hosts file. In the example, the host IP address is 172.16.100.195 and the host name is sdw1.

$ cat  add_hosts.sh 
#!/bin/bash
for line  in `psql -Atc "select distinct  hostname from gp_segment_configuration order by datadir desc"`
do
    gpssh -h $hostname -v -e "echo 172.16.100.195 sdw1 >> /etc/hosts"

done

Then reload the configuration to make the modified configuration file take effect

$ gpstop -u

1.9 Create a user for the target cluster

Execute the following command in the target MatrixDB 4 cluster environment.

$ psql -h <YMatrix Server IP Address> -p  <Target cluster port number> -d <Target database> -U <Target database superuser name> -f global_user.sql

1.10 Create DDL for the target cluster

Execute the following command in the target MatrixDB 4 cluster environment.

$ psql -h <YMatrix Server IP Address> -p  <Target cluster port number> -d <Target database> -U <Target database superuser name> -f orig.sql

1.11 Restore table structure

Use the backup orig.sql file to restore the table structure in the target MatrixDB 4 cluster.

$ time psql -d <Target database name> -f orig.sql > restoreddl.log  2>&1 &

2 Migration execution

Notes!
For detailed parameters, please refer to mxshift

First write the configuration file config_path.toml.

[database]
        [database.source]
        ## Name of database
        db-database= "testdb"
        ## Hostname of database master
        db-host="sdw3"
        ## password of database
        db-password="xxxx"
        ## Port of database master
        db-port=54322
        ## user name of database
        db-user="mxadmin"

    [database.target]
        ## Name of database
        db-database="destdb"
        ## Hostname of database master
        db-host="172.16.100.32"
        ## password of database
        db-password="yyyy"
        ## Port of database master
        db-port=5432
        ## user name of database
        db-user="mxadmin"

[scope]
compress_method="lz4"
gphome="/opt/ymatrix/matrixdb5"
mode="normal"
        [[scope.table-list]]
                schema="test_schema_1"
                name="table_001"
        [[scope.table-list]]
                schema="test_schema_2"
                name="table_002"

        [[scope.exclude-table-list]]
                schema="test_schema_3"
                name="table_003"

         schema-list=["test_schema_1", "test_schema_2"]
         exclude-schema-list=["test_schema_5", "test_schema_8"]

[log]
log-level="info"
## Print log without color.
# no-color=false

[controller]
both-way=true
concurrency=5

[transfer]
verify=true
[transfer.table-data-where-sql]
enabled=false
global="txdate >= '2022-10-01' AND batchnum >= 100000000"
[[transfer.table-data-where-sql.override]]
        where="abc > 10"
        [transfer.table-data-where-sql.override.table]
        schema="test_schema_1"
        name="table_001"
[[transfer.table-data-where-sql.override]]
        where="tag != 'aabbcc' AND ts > '2022-01-01'"
        [transfer.table-data-where-sql.override.table]
        schema="test_schema_2"
        name="another_table"

[ddl]
enabled=true
# file-path="/tmp/mxshift.sql"
# mode="output"
only-ddl=false
## During the DDL transfer, whether to skip the transfer of resource queue or group, by default, it is true.
# skip-resource-queue-and-group=true
## During the DDL transfer, whether to skip the transfer of tablespace, by default, it is true.
# skip-table-space=true
        [[ddl.replace]]
        ## Only applicable for the case of migration from Greenplum to YMatrix
                category="role"
                [[ddl.replace.pairs]]
                        old="mxadmin"
                        new="mxadmin"

Then perform data migration on the target MatrixDB 4 cluster.

$ mxshift -c config_path.toml

3 Follow-up tasks

3.1 Execute to create an index

Perform the creation of an index on the target MatrixDB 4 cluster.

$ psql -h localhost -p  <Target cluster port number> -d <Target database name> -U <Target database superuser name> -f index.sql >>idx.out 2>&1 &

3.2 Execute the analyzedb command

Update the library statistics on the target MatrixDB 4 cluster.

$ export PGPORT=<Target cluster port number>
time analyzedb -d <Target database name> -p 10 -a

3.3 Adding Mirror

Add Mirror on the target MatrixDB 4 cluster. The steps are as follows:

# First, check the current cluster instance information
postgres=# SELECT * from gp_segment_configuration order by 1;
 dbid | content | role | preferred_role | mode | status | port | hostname | address |                   datadir
-----+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    1 |      -1 | p    | p              | n    | u      | 5432 | mdw      | mdw     | /home/mxdata_20220925154450/master/mxseg-1
    2 |       0 | p    | p              | n    | u      | 6000 | sdw2     | sdw2    | /home/mxdata_20220925154450/primary/mxseg0
    3 |       1 | p    | p              | n    | u      | 6001 | sdw2     | sdw2    | /home/mxdata_20220925154450/primary/mxseg1
    4 |       2 | p    | p              | n    | u      | 6000 | sdw3     | sdw3    | /home/mxdata_20220925154450/primary/mxseg2
    5 |       3 | p    | p              | n    | u      | 6001 | sdw3     | sdw3    | /home/mxdata_20220925154450/primary/mxseg3
    6 |      -1 | m    | m              | s    | u      | 5432 | sdw1     | sdw1    | /home/mxdata_20220925154450/standby/mxseg-1
(6 rows)

# Create a file with all hostnames
$ cat /home/mxadmin/seg_hosts 
sdw1
sdw2
sdw3
sdw4

# Batch increase of Mirror directory via gpssh command
$ gpssh -f /home/mxadmin/seg_hosts -e 'mkdir -p /home/mxdata_20220925154450/mirror'

# Generate Mirror template file
$ gpaddmirrors -o ./addmirror

# View Mirror template files
$ cat addmirror

# Perform the Add Mirror Operation
$ gpaddmirrors -i addmirror

# Finally, check the cluster instance again
postgres=# SELECT * from gp_segment_configuration order by 1;
 dbid | content | role | preferred_role | mode | status | port | hostname | address |                   datadir
-----+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    1 |      -1 | p    | p              | n    | u      | 5432 | mdw      | mdw     | /home/mxdata_20220925154450/master/mxseg-1
    2 |       0 | p    | p              | n    | u      | 6000 | sdw2     | sdw2    | /home/mxdata_20220925154450/primary/mxseg0
    3 |       1 | p    | p              | s    | u      | 6001 | sdw2     | sdw2    | /home/mxdata_20220925154450/primary/mxseg1
    4 |       2 | p    | p              | s    | u      | 6000 | sdw3     | sdw3    | /home/mxdata_20220925154450/primary/mxseg2
    5 |       3 | p    | p              | s    | u      | 6001 | sdw3     | sdw3    | /home/mxdata_20220925154450/primary/mxseg3
    6 |      -1 | m    | m              | s    | u      | 5432 | sdw1     | sdw1    | /home/mxdata_20220925154450/standby/mxseg-1
    7 |       0 | m    | m              | n    | d      | 7000 | sdw3     | sdw3    | /home/mxdata_20220925154450/mirror/mxseg0
    8 |       1 | m    | m              | s    | u      | 7001 | sdw3     | sdw3    | /home/mxdata_20220925154450/mirror/mxseg1
    9 |       2 | m    | m              | s    | u      | 7000 | sdw2     | sdw2    | /home/mxdata_20220925154450/mirror/mxseg2
   10 |       3 | m    | m              | s    | u      | 7001 | sdw2     | sdw2    | /home/mxdata_20220925154450/mirror/mxseg3
(10 rows)

После завершения вышеуказанных шагов восстановите доступ к бизнесу, наблюдайте за состоянием работы бизнес-приложений и отслеживайте их в течение определенного периода времени (точное время зависит от конкретного сценария). Если система работает стабильно — поздравляем, миграция данных успешно завершена!

Следующая →
История версий