Миграция базы данных из Managed Service for MySQL® в сторонний кластер MySQL®
Примечание
Миграция данных из стороннего кластера MySQL® описана в статье Миграция данных из стороннего кластера 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-
Создайте эндпоинт для источника:
-
Тип базы данных —
MySQL
. -
Настройки подключения —
Кластер Managed Service for MySQL
.Укажите идентификатор кластера-источника.
-
-
Создайте эндпоинт для приемника:
-
Тип базы данных —
MySQL
. -
Настройки подключения —
Пользовательская инсталляция
.Укажите параметры подключения к кластеру-приемнику.
-
-
Создайте трансфер типа Копирование и репликация, использующий созданные эндпоинты.
-
Если у вас еще нет Terraform, установите его.
-
Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.
-
Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его
. -
Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.
-
Скачайте в ту же рабочую директорию файл конфигурации трансфера и эндпоинтов data-transfer-mmy-mysql.tf
. -
Укажите в файле конфигурации:
-
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Создайте необходимую инфраструктуру:
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления
.Трансфер активируется автоматически после создания.
-
Важно
Избегайте любых изменений в схеме данных на кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.
-
-
Дождитесь перехода трансфера в статус Реплицируется.
-
Переведите кластер-источник в режим
только чтение
и переключите нагрузку на кластер-приемник. -
На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum data transfer delay. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
-
Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.
Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.
-
Удалите созданные эндпоинты и трансфер:
ВручнуюTerraformЕсли вы создали эндпоинты и трансфер вручную, то:
Если вы создали эндпоинты и трансфер с помощью Terraform, то:
-
В командной строке перейдите в каталог, в котором расположен актуальный конфигурационный файл Terraform с планом инфраструктуры.
-
Удалите конфигурационный файл
data-transfer-mmy-mysql.tf
. -
Проверьте корректность файлов конфигурации Terraform с помощью команды:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
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Подключение без SSLmysql --host=<FQDN_хоста-мастера> \ --user=<имя_пользователя> \ --password \ --port=3306 \ --ssl-ca=<путь_к_SSL-сертификату> \ --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-hxk9audl********.mdb.yandexcloud.net
Master_User: replica-my
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin-log-rc1a-hxk9audl********-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;
-
Переключите нагрузку на кластер-приемник.
-
Удалите пользователя для управления репликацией в кластере-источнике.
-
Удалите пользователя с полными правами на доступ к переносимой базе в кластере-приемнике, если он больше не нужен.