Перенести Amazon RDS for MySQL в База данных Azure для MySQL с использованием входящей репликации данных

Вы можете использовать такие методы, как экспорт и восстановление дампа MySQL, экспорт и импорт в MySQL Workbench или Azure Database Migration Service, чтобы перенести базы данных MySQL в База данных Azure для MySQL — Flexible Server. Рабочие нагрузки можно перенести с минимальным временем простоя с помощью сочетания средств с открытым кодом, таких как mysqldump или mydumper и myloader с репликацией данных.

Репликация входных данных — это метод, который реплицирует изменения данных с исходного сервера на целевой на основе метода позиционирования двоичного файла журнала. В этом сценарии экземпляр MySQL, работающий в качестве источника (на котором происходят изменения базы данных), записывает обновления и изменения как события в двоичный журнал. Сведения в двоичном журнале хранятся в разных форматах в соответствии с записанными изменениями базы данных. Реплики настроены на чтение двоичного журнала из источника и выполнение событий в двоичном файле журнала в локальной базе данных реплики.

Настройте репликацию данных в База данных Azure для MySQL — гибкий сервер, чтобы синхронизировать данные с исходного сервера MySQL на целевой сервер MySQL. Вы можете выполнить выборочное переключение приложений с первичной (или исходной базы данных) на реплику (или целевую базу данных).

См. статью Перенос баз данных из Amazon Web Services в Azure, которая содержит примеры сценариев миграции, которые могут соответствовать вашему сценарию использования.

В этом руководстве вы узнаете, как настроить репликацию данных между исходным сервером, на котором запущена служба реляционных баз данных Amazon (RDS) для MySQL и целевой сервер, на котором выполняется гибкий сервер База данных Azure для MySQL.

Соображения о производительности

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

Расположение клиента

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

• Для экземпляров гибкого сервера База данных Azure для MySQL клиентский компьютер должен находиться в той же виртуальной сети и зоне доступности, что и целевой сервер базы данных.
• Для исходных экземпляров базы данных Amazon RDS экземпляр клиента должен находиться в том же виртуальном частном облаке Amazon и в той же зоне доступности, что и сервер базы данных-источника. В предыдущем случае можно перемещать файлы дампа между клиентскими компьютерами с помощью протоколов передачи файлов, таких как FTP или SFTP, или отправлять их в хранилище BLOB-объектов Azure. Чтобы сократить общее время миграции, необходимо сжать файлы перед переносом.

Емкость клиента

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

• Если дамп или восстановление предполагает обработку данных в режиме реального времени, например сжатие или распаковку, выберите класс экземпляра с по крайней мере одним ядром ЦП на каждый поток дампа или восстановления.
• Убедитесь в наличии достаточной пропускной способности сети для экземпляра клиента. Используйте типы экземпляров, поддерживающие функцию ускорения работы в сети. Дополнительные сведения см. в разделе "Ускорение работы в сети" в руководстве по сетевым подключениям виртуальных машин Azure.
• Убедитесь, что уровень хранилища клиентского компьютера обеспечивает ожидаемую емкость для чтения и записи. Рекомендуется использовать виртуальную машину Azure с хранилищем SSD (цен. категория "Премиум").

Предварительные требования

Для работы с этим руководством вам потребуется следующее:

• Установите mysqlclient на клиентском компьютере, чтобы создать дамп и выполнить восстановление в целевом экземпляре База данных Azure для MySQL Flexible Server.

• Для больших баз данных установите mydumper и myloader для параллельного дампа и восстановления баз данных.

  Примечание.

  Mydumper может работать только в дистрибутивах Linux. Дополнительные сведения см. в разделе Как установить mydumper.

• Создайте экземпляр База данных Azure для MySQL Flexible Server с версией 5.7 или 8.0.

  Внимание

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

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

Убедитесь, что некоторые параметры и функции сконфигурированы и настроены правильно, в соответствии с описанием ниже.

• В целях совместимости следует иметь исходный и целевой серверы базы данных в одной версии MySQL.
• Каждая таблица должна иметь первичный ключ. Отсутствие первичных ключей в таблицах может замедлять процесс репликации.
• Убедитесь, что кодировка исходной и целевой баз данных совпадает.
• Задайте для параметра wait_timeout разумное время. Время зависит от объема данных или рабочей нагрузки, которую необходимо импортировать или перенести.
• Убедитесь, что во всех таблицах используется InnoDB. База данных Azure для MySQL — Flexible Server поддерживает только механизм хранения InnoDB.
• Для таблиц со многими вторичными индексами или большими таблицами во время восстановления отображаются эффекты на производительность. Измените файлы дампа так, чтобы инструкции CREATE TABLE не содержали определения вторичных ключей. После импорта данных повторно создайте вторичные индексы, чтобы избежать снижения производительности во время процесса восстановления.

Наконец, для подготовки к репликации входных данных сделайте следующее.

• Убедитесь, что целевой экземпляр гибкого сервера База данных Azure для MySQL может подключаться к исходному серверу Amazon RDS для MySQL через порт 3306.
• Убедитесь, что исходный сервер Amazon RDS для MySQL разрешает как входящий, так и исходящий трафик на порту 3306.
• Убедитесь, что вы предоставляете подключение типа "сеть — сеть" к исходному серверу с помощью Azure ExpressRoute или VPN-шлюза Azure. Дополнительные сведения о создании виртуальной сети см. в документации по виртуальным сетям Azure. См. также статьи по быстрому началу с пошаговым описанием.
• Настройте группы безопасности сети сервера исходной базы данных так, чтобы разрешить IP-адрес целевого экземпляра База данных Azure для MySQL Flexible Server.

Настройте целевой экземпляр Базы данных Azure для MySQL

Чтобы настроить целевой экземпляр База данных Azure для MySQL — гибкий сервер, который является целевым сервером для репликации входящих данных:

1. Задайте для параметра max_allowed_packet максимальное значение 1073741824, что составляет 1 ГБ. Это значение предотвращает любые проблемы переполнения, связанные с длинными строками.

2. Установите для параметров slow_query_log, general_log, audit_log_enabled и query_store_capture_mode значение OFF во время миграции, чтобы устранить любые издержки, связанные с ведением журнала запросов.

3. Увеличьте объем вычислительных ресурсов целевого экземпляра База данных Azure для MySQL — Flexible Server до максимального значения — 64 виртуальных ядер. Этот размер предоставляет больше вычислительных ресурсов при восстановлении дампа базы данных исходного сервера.

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

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

   Примечание.

   Максимально доступное количество операций ввода-вывода в секунду определяется размером вычислительных ресурсов. Дополнительные сведения см. в разделе IOPS в статье Вычислительные ресурсы и варианты хранилища в База данных Azure для MySQL — гибкий сервер.

Настройте исходный сервер Amazon RDS для MySQL

Чтобы подготовить и настроить сервер MySQL, размещенный в Amazon RDS, который является источником для репликации входных данных, необходимо выполнить указанные ниже действия.

1. Убедитесь, что на исходном сервере Amazon RDS для MySQL включено ведение двоичного журнала. Убедитесь, что автоматическое резервное копирование включено, либо что для исходного сервера Amazon RDS for MySQL создана реплика для чтения.

2. Убедитесь, что файлы двоичного журнала на исходном сервере сохраняются до тех пор, пока изменения не будут применены на целевом экземпляре База данных Azure для MySQL Flexible Server.

   При использовании репликации входящих данных База данных Azure для MySQL — Flexible Server не управляет процессом репликации.

3. Чтобы проверить срок хранения двоичных журналов на исходном сервере Amazon RDS и определить количество часов, в течение которых хранятся двоичные журналы, вызовите хранимую процедуру mysql.rds_show_configuration:

   call mysql.rds_show_configuration;
   +------------------------+-------+-----------------------------------------------------------------------------------------------------------+
   | name | value | description |
   | +------------------------+-------+-----------------------------------------------------------------------------------------------------------+ |
   | binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
   | source delay | 0 | source delay specifies replication delay in seconds between current instance and its master. |
   | target delay | 0 | target delay specifies replication delay in seconds between current instance and its future read-replica. |
   | +------------------------+------- +-----------------------------------------------------------------------------------------------------------+ |
   | 3 rows in set (0.00 sec) |
   

4. Чтобы настроить период хранения двоичных журналов, выполните хранимую процедуру rds_set_configuration, чтобы двоичные журналы сохранялись на сервере-источнике в течение требуемого периода времени. Например:

   Call mysql.rds_set_configuration('binlog retention hours', 96);
   

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

   Примечание.

   Убедитесь, что достаточно места на диске для хранения двоичных журналов на исходном сервере на основе определенного периода хранения.

Существует два способа записи дампа данных с исходного сервера Amazon RDS для MySQL. Один из подходов заключается в записи дампа данных непосредственно с исходного сервера. Другой подход предусматривает запись дампа из реплики чтения Amazon RDS для MySQL.

• Для записи дампа данных непосредственно с исходного сервера выполните следующие действия.

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

     Вы также можете временно установить для параметра read_only значение 1, чтобы записи не обрабатывались при получении дампа данных.

  2. После того как вы остановите операции записи на сервере-источнике, получите имя файла двоичного журнала и смещение, выполнив команду Mysql> Show master status;.

  3. Сохраните эти значения, чтобы начать репликацию из экземпляра гибкого сервера База данных Azure для MySQL.

  4. Чтобы создать дамп данных, выполните mysqldump, запустив следующую команду:

     $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql
     

• Если остановка записи на исходном сервере невозможна или производительность дампа данных на исходном сервере неприемлема, запишите дамп на сервере-реплике указанным ниже образом.

  1. Создайте реплику чтения Amazon MySQL с той же конфигурацией, что и у исходного сервера. Затем создайте там дамп.

  2. Позвольте реплике для чтения Amazon RDS for MySQL синхронизироваться с исходным сервером Amazon RDS for MySQL.

  3. Когда задержка реплики достигнет 0 на реплике чтения, остановите репликацию, вызвав хранимую процедуру mysql.rds_stop_replication.

     call mysql.rds_stop_replication;
     

  4. После остановки репликации подключитесь к реплике. Затем выполните команду SHOW SLAVE STATUS, чтобы получить имя текущего файла двоичного журнала из поля Relay_Master_Log_File и расположение файла журнала из поля Exec_Master_Log_Pos.

  5. Сохраните эти значения, чтобы запустить репликацию из экземпляра База данных Azure для MySQL — Flexible Server.

  6. Чтобы создать дамп данных из реплики чтения Amazon RDS для MySQL, выполните mysqldump, запустив следующую команду:

     $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql
     

  Примечание.

  Вы также можете использовать mydumper для записи параллельного дампа данных из исходной базы данных Amazon RDS для MySQL. Дополнительные сведения см. в статье «Перенос больших баз данных в База данных Azure для MySQL — гибкий сервер с помощью mydumper/myloader».

Создание связи между исходным сервером и сервером-репликой для запуска репликации входных данных

1. Чтобы восстановить базу данных с помощью собственного средства восстановления MySQL, выполните следующую команду:

   $ mysql -h <target_server> -u <targetuser> -p < dumpname.sql
   

   Примечание.

   Если вы вместо этого используете myloader, см. Миграция больших баз данных в База данных Azure для MySQL — гибкий сервер с помощью mydumper/myloader.

2. Войдите на исходный сервер Amazon RDS для MySQL и настройте пользователя репликации. Затем предоставьте этому пользователю необходимые привилегии.

   • Если вы используете SSL, выполните следующие команды:

     CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
     GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
     SHOW GRANTS FOR syncuser@'%';
     

   • Если вы не используете SSL, выполните следующие команды:

     CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
     GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
     SHOW GRANTS FOR syncuser@'%';
     

   Хранимые процедуры выполняют все функции репликации входных данных. Сведения обо всех процедурах см. в разделе Хранимые процедуры репликации входных данных. Хранимые процедуры можно выполнять в оболочке MySQL или MySQL Workbench.

3. Чтобы связать исходный сервер Amazon RDS for MySQL и целевой сервер База данных Azure для MySQL Flexible Server, войдите в целевой экземпляр База данных Azure для MySQL Flexible Server. Установите сервер Amazon RDS для MySQL в качестве исходного сервера, выполнив следующую команду:

   CALL mysql.az_replication_change_master('source_server','replication_user_name','replication_user_password',3306,'<master_bin_log_file>',master_bin_log_position,'<master_ssl_ca>');
   

4. Чтобы начать репликацию между исходным сервером Amazon RDS для MySQL и целевым экземпляром гибкого сервера База данных Azure для MySQL, выполните следующую команду:

   CALL mysql.az_replication_start;
   

5. Чтобы проверить состояние репликации на сервере реплики, выполните следующую команду:

   show slave status\G
   

   Если параметры Slave_IO_Running и Slave_SQL_Running имеют значение Да, репликация началась и находится в запущенном состоянии.

6. Проверьте значение параметра Seconds_Behind_Master, чтобы определить задержку целевого сервера.

   Если значение равно 0, целевой сервер обработал все обновления с исходного сервера. Если значение отличается от 0, целевой сервер все еще обрабатывает обновления.

Обеспечьте успешное переключение

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

1. Настройте соответствующие имена входа и разрешения на уровне базы данных в целевом экземпляре гибкого сервера База данных Azure для MySQL.
2. Остановите запись данных на исходный сервер Amazon RDS for MySQL.
3. Убедитесь, что целевой экземпляр База данных Azure для MySQL — Flexible Server синхронизировался с исходным сервером и что значение Seconds_Behind_Master имеет 0 в show slave status.
4. Вызовите хранимую процедуру mysql.az_replication_stop, чтобы остановить репликацию, так как все изменения реплицированы в целевой экземпляр База данных Azure для MySQL — Flexible Server.
5. Вызовите mysql.az_replication_remove_master, чтобы удалить конфигурацию репликации входных данных.
6. Перенаправьте клиенты и клиентские приложения в целевой экземпляр гибкого сервера База данных Azure для MySQL.

На этом миграция завершена. Приложения подключены к серверу, на котором работает гибкий сервер База данных Azure для MySQL.

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

• Руководство по переносу баз данных