Связаться с намиПодключиться

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

Статья создана
Обновлена 2 декабря 2024 г.

Примечание

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

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

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

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

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

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

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

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

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

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

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

  1. Подготовьте базу данных кластера-источника.

  2. Подготовьте базу данных кластера-приемника.

  3. Создайте эндпоинты и трансфер:

    1. Создайте эндпоинт для источника:

      • Тип базы данных — MySQL.

      • Настройки подключения — Кластер Managed Service for MySQL.

        Укажите идентификатор кластера-источника.

    2. Создайте эндпоинт для приемника:

      • Тип базы данных — MySQL.

      • Настройки подключения — Пользовательская инсталляция.

        Укажите параметры подключения к кластеру-приемнику.

    3. Создайте трансфер типа Копирование и репликация, использующий созданные эндпоинты.

    4. Активируйте трансфер.

    1. Если у вас еще нет Terraform, установите его.

    2. Получите данные для аутентификации. Вы можете добавить их в переменные окружения или указать далее в файле с настройками провайдера.

    3. Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его.

    4. Поместите конфигурационный файл в отдельную рабочую директорию и укажите значения параметров. Если данные для аутентификации не были добавлены в переменные окружения, укажите их в конфигурационном файле.

    5. Скачайте в ту же рабочую директорию файл конфигурации трансфера и эндпоинтов data-transfer-mmy-mysql.tf.

    6. Укажите в файле конфигурации:

    7. Проверьте корректность файлов конфигурации Terraform с помощью команды:

      terraform validate

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

    8. Создайте необходимую инфраструктуру:

      1. Выполните команду для просмотра планируемых изменений:

        terraform plan

        Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

      2. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply

        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

      В указанном каталоге будут созданы все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления.

      Трансфер активируется автоматически после создания.

    Важно

    Избегайте любых изменений в схеме данных на кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.

  4. Дождитесь перехода трансфера в статус Реплицируется.

  5. Переведите кластер-источник в режим только чтение и переключите нагрузку на кластер-приемник.

  6. На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum data transfer delay. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.

  7. Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.

    Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.

  8. Удалите созданные эндпоинты и трансфер:

    Если вы создали эндпоинты и трансфер вручную, то:

    1. Удалите остановленный трансфер.
    2. Удалите эндпоинты для источника и приемника.

    Если вы создали эндпоинты и трансфер с помощью Terraform, то:

    1. В терминале перейдите в директорию с планом инфраструктуры.

      Важно

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

    2. Удалите ресурсы:

      1. Выполните команду:

        terraform destroy

      2. Подтвердите удаление ресурсов и дождитесь завершения операции.

      Все ресурсы, которые были описаны в Terraform-манифестах, будут удалены.

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

  1. Перенесите логический дамп базы данных.
  2. Настройте пользователя в кластере-источнике для управления репликацией.
  3. Запустите репликацию в кластере-приемнике.
  4. Отслеживайте процесс миграции до его завершения.
  5. Закончите миграцию.

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

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

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

    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. Они понадобятся при запуске репликации.

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

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

    Совет

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

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

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

    mysql --host=<FQDN_хоста-мастера> \
      --user=<имя_пользователя> \
      --password \
      --port=3306 \
      --line-numbers \
      <имя_БД> < <файл_дампа>

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

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

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

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

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

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

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

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

  1. Измените файл конфигурации кластера-приемника /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® они включены всегда.

  2. Перезапустите сервис mysql:

    sudo systemctl restart mysql

  3. Подключитесь к кластеру-приемнику от имени пользователя с полными правами на доступ к переносимой базе данных.

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

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

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

    Совет

    Используйте особый 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;

  6. Запустите воспроизведение лога ретрансляции:

    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®.

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

  1. Снимите нагрузку с кластера-источника и убедитесь, что приложение не пишет данные в базу кластера-источника. Для этого можно изменить пользовательскую настройку кластера-источника MAX_UPDATES_PER_HOUR на 1.

  2. Дождитесь снижения до нуля характеристики Seconds_Behind_Master. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после создания логического дампа.

  3. Остановите репликацию в кластере-приемнике:

    STOP SLAVE;

  4. Переключите нагрузку на кластер-приемник.

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

  6. Удалите пользователя с полными правами на доступ к переносимой базе в кластере-приемнике, если он больше не нужен.

Предыдущая
Синхронизация данных из стороннего кластера MySQL® в Managed Service for MySQL® с помощью Data Transfer
Следующая
Миграция БД из Managed Service for MySQL® в Object Storage с помощью Data Transfer