Миграция данных MySQL в База данных Azure для MySQL — репликация изменений MySQL

Выполнение миграции изменений репликации с помощью автономного сценария с параметром "Включить согласованность транзакций" позволяет предприятиям переносить свои базы данных в Azure, пока базы данных остаются в эксплуатации. Другими словами, миграция может быть завершена с минимальным временем простоя для критически важных приложений, что ограничивает влияние на доступность уровня обслуживания и неудобства для конечных клиентов.

Текущая реализация

Чтобы получить файл журнала двоичных файлов и положение для репликации входящих изменений, необходимо выполнить сценарий автономной миграции с помощью команды "Включить согласованность транзакций". Пользовательский интерфейс портала DMS отображает двоичное имя файла журнала и расположение, выравниваемое по времени получения блокировок в источнике для согласованного моментального снимка. Это значение можно использовать в нашей репликации изменений для потоковой передачи входящих изменений.

Снимок экрана: экран добавления сведений о источнике.

При выполнении миграции реплицируемых изменений, когда целевой объект почти подключен к исходному серверу, остановите все входящие транзакции в исходную базу данных и дождитесь, пока все ожидающие транзакции не будут применены к целевой базе данных. Чтобы убедиться, что целевая база данных обновлена на исходном сервере, запустите запрос "SHOW MASTER STATUS;", а затем сравните эту позицию с последним зафиксированным событием binlog (отображается в разделе "Ход миграции"). Если две позиции одинаковы, целевой объект догнал все изменения, и вы можете начать переключение.

Как работает репликация изменений

Текущая реализация основана на изменениях потоковой binlog с исходного сервера и их применении к целевому серверу. Как и репликация данных, это упрощает настройку и не требует физического подключения между источником и целевыми серверами.

Сервер может отправлять binlog в виде потока, содержащего двоичные данные, как описано здесь. Клиент может указать начальную позицию журнала для запуска потока. Имя файла журнала описывает позицию журнала, позицию в этом файле и при необходимости GTID (глобальный идентификатор транзакции), если режим gtid включен в источнике.

Изменения данных отправляются в виде событий "строка", которые содержат данные для отдельных строк (до и (или) после изменения в зависимости от типа операции, которая вставляется, удаляется или обновляется. Затем события строк применяются в их необработанном формате с помощью инструкции BINLOG: MySQL 8.0 Reference Manual :: 13.7.8.1 BINLOG Statement. Но для миграции DMS на сервер 5.7 DMS не применяет изменения в виде инструкций BINLOG (так как DMS не имеет необходимых привилегий для этого) и вместо этого преобразует события строк в инструкции INSERT, UPDATE или DELETE.

Prerequisites

Чтобы успешно выполнить миграцию реплицируемых изменений, убедитесь, что выполнены следующие предварительные требования:

  • Используйте инструмент командной строки MySQL по вашему выбору, чтобы определить, включён ли log_bin на исходном сервере. Binlog не всегда включен по умолчанию, поэтому убедитесь, что он включен перед началом миграции. Чтобы определить, включена ли log_bin на исходном сервере, выполните команду: SHOW VARIABLES LIKE 'log_bin'

  • Убедитесь, что у пользователя есть REPLICATION_APPLIER или BINLOG_ADMIN разрешение на целевом сервере для применения журнала bin.

  • Убедитесь, что у пользователя есть REPLICATION REPLICA разрешение на целевом сервере.

  • Убедитесь, что у пользователя есть REPLICATION CLIENT и REPLICATION REPLICA разрешение на исходном сервере для чтения и применения журнала bin.

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

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

Limitations

  • При миграции реплицируемых изменений имя базы данных на целевом сервере должно совпадать с именем на исходном сервере.
  • Поддержка ограничена форматом binlog ROW.
  • Репликация изменений DDL поддерживается только в том случае, если выбран параметр репликации определения данных и инструкций администрирования для выбранных объектов в пользовательском интерфейсе DMS. Функция репликации поддерживает репликацию определений данных и инструкций администрирования, возникающих после начальной загрузки и вошедшего в двоичный журнал в целевой объект.
  • Переименование баз данных или таблиц не поддерживается при репликации изменений.

Связанный контент

  • Last updated on