Миграция базы данных из Managed Service for MySQL в MySQL

Статья создана

Перед началом работы
Перенос данных с использованием сервиса Yandex Data Transfer
Перенос данных с помощью внешней репликации

Примечание

Миграция данных из стороннего кластера MySQL описана в статье Миграция базы данных из стороннего кластера MySQL в Managed Service for MySQL.

Чтобы перенести базу данных, развернутую в кластере Managed Service for MySQL, на сторонний кластер MySQL:

Перенесите данные.
Закройте старую базу данных на запись.
Переведите нагрузку на сторонний кластер.

Поддерживается миграция между разными версиями: например, можно перенести базы из MySQL версии 5.7 в версию 8. При этом мажорная версия MySQL на стороннем кластере должна быть не ниже версии на кластере Managed Service for MySQL.

Перенести данные из кластера-источника Managed Service for MySQL в сторонний кластер-приемник MySQL можно двумя способами:

Перенос данных с использованием сервиса Yandex Data Transfer.

Этот способ позволяет перенести базу целиком без остановки обслуживания пользователей.

Подробнее см. в разделе Какие задачи решает сервис Yandex Data Transfer.
Перенос данных с помощью внешней репликации.

Внешняя репликация позволяет мигрировать базы данных между кластерами MySQL, используя встроенные средства СУБД.

Используйте этот способ только в том случае, если перенос данных с помощью Yandex Data Transfer по каким-либо причинам невозможен.

Перед началом работы

Подготовьте кластер-приемник:

Создайте базу данных MySQL любой подходящей конфигурации.
Убедитесь, что к хостам кластера-приемника можно подключиться из интернета.

Дополнительно для переноса с помощью внешней репликации MySQL:

Убедитесь, что все хосты кластера-источника доступны по публичному IP-адресу, чтобы кластер-приемник мог подключаться к источнику. Для этого:
- Добавьте хосты с публичными IP-адресами.
- Удалите хосты без публичных IP-адресов.
Установите на хосты кластера-приемника серверные SSL-сертификаты Managed Service for MySQL. Они требуются для подключения к публично доступному кластеру-источнику.
При необходимости настройте межсетевой экран (firewall) и группы безопасности, чтобы можно было подключаться из кластера-приемника к кластеру-источнику, а также к каждому кластеру в отдельности (например, с помощью утилиты mysql).
Убедитесь, что с хостов кластера-приемника можно подключиться к хостам кластера-источника.
Убедитесь, что можно подключиться к кластеру-источнику и к кластеру-приемнику с SSL.

Перенос данных с использованием сервиса Yandex Data Transfer

Подготовьте базу данных кластера-источника.
Подготовьте базу данных кластера-приемника.
Создайте эндпоинты и трансфер:
Вручную

С помощью Terraform
1. Создайте эндпоинт для источника:
  - Тип базы данных — MySQL.
  - Настройки подключения — Кластер MDB.
    
    Укажите идентификатор кластера-источника.
2. Создайте эндпоинт для приемника:
  - Тип базы данных — MySQL.
  - Настройки подключения — Пользовательская инсталляция.
    
    Укажите параметры подключения к кластеру-приемнику.
3. Создайте трансфер типа Копировать и реплицировать, использующий созданные эндпоинты.
4. Активируйте трансфер.
1. Если у вас еще нет Terraform, установите его.
2. Скачайте файл с настройками провайдера. Поместите его в отдельную рабочую директорию и укажите значения параметров.
3. Скачайте в ту же рабочую директорию файл конфигурации трансфера и эндпоинтов data-transfer-mmy-mysql.tf.
4. Укажите в файле конфигурации:
  - параметры эндпоинта-источника;
  - параметры эндпоинта-приемника.
5. Выполните команду terraform init в директории с конфигурационными файлами. Эта команда инициализирует провайдер, указанный в конфигурационных файлах, и позволяет работать с ресурсами и источниками данных провайдера.
6. Проверьте корректность файлов конфигурации Terraform с помощью команды:
  terraform validate
  Если в файлах конфигурации есть ошибки, Terraform на них укажет.
7. Создайте необходимую инфраструктуру:
  1. Выполните команду для просмотра планируемых изменений:
    
    terraform plan
    
    Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
  2. Если вас устраивают планируемые изменения, внесите их:
    
    Выполните команду:
    
    terraform apply
    
    Подтвердите изменение ресурсов.
    
    Дождитесь завершения операции.
  В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления.
  
  Трансфер активируется автоматически после создания.
Важно

Избегайте любых изменений в схеме данных на кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.
Дождитесь перехода трансфера в статус Реплицируется.
Переведите кластер-источник в режим только чтение и переключите нагрузку на кластер-приемник.
На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum lag on delivery, [s]. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.

Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.
Удалите созданные эндпоинты и трансфер:
Вручную

С помощью Terraform
Если вы создали эндпоинты и трансфер вручную, то:
1. Удалите остановленный трансфер.
2. Удалите эндпоинты для источника и приемника.
Если вы создали эндпоинты и трансфер с помощью Terraform, то:
1. В командной строке перейдите в каталог, в котором расположен актуальный конфигурационный файл Terraform с планом инфраструктуры.
2. Удалите конфигурационный файл data-transfer-mmy-mysql.tf.
3. Проверьте корректность файлов конфигурации Terraform с помощью команды:
  terraform validate
  Если в файлах конфигурации есть ошибки, Terraform на них укажет.
4. Подтвердите изменение ресурсов.
  1. Выполните команду для просмотра планируемых изменений:
    
    terraform plan
    
    Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
  2. Если вас устраивают планируемые изменения, внесите их:
    
    Выполните команду:
    
    terraform apply
    
    Подтвердите изменение ресурсов.
    
    Дождитесь завершения операции.
  Все ресурсы, которые были описаны в конфигурационном файле data-transfer-mmy-mysql.tf, будут удалены.

Перенос данных с помощью внешней репликации

Перенесите логический дамп базы данных

Логический дамп — файл с набором команд, последовательное выполнение которых позволяет восстановить состояние базы данных. Он создается с помощью утилиты mysqldump. Чтобы обеспечить полноту логического дампа, перед его созданием приостановите запись в базу данных.

Запросите текущую позицию бинарного лога для консистентности восстановления логического дампа:

SHOW MASTER STATUS;

+-------------------------+----------+--------------+------------------+-----------------------------+
| File                    | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set           |
+-------------------------+----------+--------------+------------------+-----------------------------+
| mysql-bin-log-...000224 |  2058567 |              |                  | d827098b-...00b86:1-1575866 |
+-------------------------+----------+--------------+------------------+-----------------------------+
1 row in set (0.00 sec)

Запишите значения File и Position. Они понадобятся при запуске репликации.

Создайте дамп базы кластера-источника:

mysqldump \
    --databases=<имя базы данных> \
    --routines \
    --host=<FQDN хоста-мастера> \
    --ssl-ca=<путь к SSL-сертификату> \
    --user=<имя пользователя-владельца БД> > <файл дампа>

Совет

Используйте особый FQDN, который всегда указывает на текущий хост-мастер в кластерах Managed Service for MySQL.

Восстановите базу данных из дампа в кластере-приемнике:

Подключение с SSL

Подключение без SSL

mysql --host=<FQDN хоста-мастера> \
      --user=<имя пользователя> \
      --password \
      --port=3306 \
      --ssl-ca=<путь к файлу сертификата> \
      --ssl-mode=VERIFY_IDENTITY \
      --line-numbers \
      <имя базы данных> < <файл дампа>

mysql --host=<FQDN хоста-мастера> \
      --user=<имя пользователя> \
      --password \
      --port=3306 \
      --line-numbers \
      <имя базы данных> < <файл дампа>

Создайте в кластере-приемнике пользователя с полными правами на доступ к переносимой базе данных:

CREATE USER '<имя пользователя>'@'%' IDENTIFIED BY '<пароль>';
GRANT ALL PRIVILEGES ON <имя базы>.* TO '<имя пользователя>'@'%';

Настройте пользователя в кластере-источнике для управления репликацией

MySQL использует модель мастер-реплика при выполнении репликации: кластер-приемник копирует изменения бинарного лога кластера-источника в свой лог, который называется логом ретрансляции (relay log). Хост-реплика воспроизводит изменения из лога ретрансляции, применяя их к собственным данным.

Чтобы получать изменения бинарного лога и управлять потоком репликации в кластере-источнике:

Создайте пользователя.
Назначьте роль ALL_PRIVILEGES этому пользователю на базу кластера-источника.
Назначьте глобальные привилегии REPLICATION CLIENT и REPLICATION SLAVE этому пользователю.

Кластер-приемник будет подключаться к кластеру-источнику от имени этого пользователя.

Запустите репликацию в кластере-приемнике

Измените файл конфигурации кластера-приемника /etc/mysql/my.cnf для начала репликации:
```
[mysqld]
...
log_bin = mysql-bin
server_id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index

gtid-mode = on
enforce-gtid-consistency = on
```
Где:
- log_bin — имя бинарного лога в кластере-приемнике.
- server_id — идентификатор кластера-приемника. Значение по умолчанию — 1, но для репликации необходимо, чтобы значения идентификаторов кластера-источника и кластера-приемника различались.
- relay-log — путь к логу ретрансляции.
- relay-log-index — путь к индексу лога ретрансляции.
Также для репликации включите настройки gtid-mode и enforce-gtid-consistency. В кластерах Managed Service for MySQL они включены всегда.
Перезапустите сервис mysql:
```
sudo systemctl restart mysql
```
Подключитесь к кластеру-приемнику от имени пользователя с полными правами на доступ к переносимой базе данных.

Включите репликацию базы данных и отключите репликацию служебных баз данных (по умолчанию они реплицируются):

CHANGE REPLICATION FILTER
    REPLICATE_DO_DB=(
        <имя базы кластера-приемника>
    ),
    REPLICATE_IGNORE_DB=(
        sys,
        mysql,
        performance_schema,
        information_schema
    );

Чтобы назначить мастера для кластера-приемника, укажите параметры хоста-мастера кластера-источника:

Совет

Используйте особый FQDN, который всегда указывает на текущий хост-мастер в кластерах Managed Service for MySQL.

CHANGE MASTER TO
      MASTER_HOST = '<FQDN хоста-мастера>',
      MASTER_USER = '<пользователь для репликации>',
      MASTER_PASSWORD = '<пароль пользователя>',
      MASTER_LOG_FILE = '<значение File из запроса позиции бинарного лога>',
      MASTER_LOG_POS = <значение Position из запроса позиции бинарного лога>,
      MASTER_SSL_CA = '<путь к SSL-сертификату>',
      MASTER_SSL_VERIFY_SERVER_CERT = 0,
      MASTER_SSL = 1;

Запустите воспроизведение лога ретрансляции:
```
START SLAVE;
```

Начнется процесс миграции данных из базы кластера-источника в базу кластера-приемника.

Отслеживайте процесс миграции

Используйте команду, которая показывает статус репликации:

SHOW SLAVE STATUS\G

*************************** 1. row ***************************
           Slave_IO_State: Waiting for master to send event
              Master_Host: rc1a-hxk9audl2lsi53hc.mdb.yandexcloud.net
              Master_User: replica-my
              Master_Port: 3306
            Connect_Retry: 60
          Master_Log_File: mysql-bin-log-rc1a-hxk9audl2lsi53hc-mdb-yandexcloud-net.000225
      Read_Master_Log_Pos: 1702815
           Relay_Log_File: 6b6d647a39b6-relay-bin.000084
            Relay_Log_Pos: 409
            ...

Статус репликации показывают значения полей:

Slave_IO_State, Slave_SQL_Running_State — состояние I/O потока бинарного лога и потока лога ретрансляции. При успешной репликации активны оба потока.
Read_Master_Log_Pos — последняя позиция, прочитанная из лога хоста-мастера.
Seconds_Behind_Master — отставание реплики от мастера (в секундах).
Last_IO_Error, Last_SQL_Error — ошибки репликации.

Подробнее о статусе репликации см. в документации MySQL.

Закончите миграцию

Снимите нагрузку с кластера-источника и убедитесь, что приложение не пишет данные в базу кластера-источника. Для этого можно изменить пользовательскую настройку кластера-источника MAX_UPDATES_PER_HOUR на 1.
Дождитесь снижения до нуля характеристики Seconds_Behind_Master. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после создания логического дампа.
Остановите репликацию в кластере-приемнике:
```
STOP SLAVE;
```
Переключите нагрузку на кластер-приемник.
Удалите пользователя для управления репликацией в кластере-источнике.
Удалите пользователя с полными правами на доступ к переносимой базе в кластере-приемнике, если он больше не нужен.