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

Экземпляр База данных Azure для MySQL — отдельный сервер можно перенести в База данных Azure для MySQL — гибкий сервер с минимальным временем простоя в приложения с помощью сочетания средств с открытым кодом, таких как mydumper/myloader и Data-in реплика tion.

Примечание.

Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.

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

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

В этом руководстве вы будете использовать mydumper/myloader и data-in реплика tion для переноса примера базы данных (классические модели) из экземпляра База данных Azure для MySQL — отдельный сервер на экземпляр База данных Azure для MySQL — гибкий сервер, а затем синхронизировать данные.

В этом руководстве описано следующее:

• Настройка сетевых параметров для репликации входных данных в различных сценариях.
• Настройка репликации входных данных между основным расположением и репликой.
• Тестирование репликации.
• Переход для завершения миграции.

Необходимые компоненты

Для работы с этим учебником необходимы указанные ниже компоненты.

• Экземпляр отдельного сервера Базы данных Azure для MySQL версии 5.7 или 8.0.

  Примечание.

  Если вы используете отдельный сервер Базы данных Azure для MySQL версии 5.6, обновите экземпляр до версии 5.7, а затем настройте репликацию входных данных. Дополнительные сведения см. в статье Обновление основного номера версии в отдельном сервере Базе данных Azure для MySQL.

• Экземпляр гибкого сервера Базы данных Azure для MySQL. Дополнительные сведения см. в статье Создание экземпляра гибкого сервера Базы данных Azure для MySQL.

  Примечание.

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

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

  Убедитесь, что GTID_Mode одинаково настроен на исходном и целевом сервере.

• Подключение и создание базы данных с помощью MySQL Workbench. Дополнительные сведения см. в статье Использование MySQL Workbench для подключения и запроса данных.

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

• Установка клиента MySQL или MySQL Workbench (клиентские средства) на виртуальной машине Azure. Убедитесь, что можете подключиться как к исходному серверу, так и к реплике. В рамках этой статьи устанавливается клиент MySQL.

• Установка mydumper/myloader на виртуальной машине Azure. Дополнительные сведения см. в статье о mydumper/myloader.

• Загрузка и запуск примера скрипта базы данных для базы данных classicmodels на исходном сервере.

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

Настройка требований к сети

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

• Если общедоступная конечная точка включена в источнике, убедитесь, что целевой объект может подключиться к источнику, включив параметр "Разрешить доступ к службам Azure" в правиле брандмауэра. Дополнительные сведения см. в статье Правила брандмауэра — База данных Azure для MySQL.
• Если частная конечная точка и запрет общедоступного доступа включены в источнике, установите приватную ссылку в той же виртуальной сети, где размещен целевой объект. Дополнительные сведения см. в статье Приватный канал — База данных Azure для MySQL.

Настройка репликации входных данных

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

1. Войдите на виртуальную машину Azure, на которой установлено клиентское средство MySQL.

2. Подключитесь к источнику и целевому объекту с помощью клиентского средства MySQL.

3. Используйте клиентское средство MySQL, чтобы определить, включен ли log_bin в источнике, выполнив следующую команду:

   SHOW VARIABLES LIKE 'log_bin';
   

   Примечание.

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

   Совет

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

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

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

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
   

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

   CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
   GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
   

5. Чтобы создать резервную копию базы данных с помощью mydumper, выполните следующую команду на виртуальной машине Azure, где установлен mydumper\myloader:

   mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt
   

   Совет

   Параметр --trx-consistency-only требуется для транзакционной согласованности при резервном копировании.

   • Эквивалент mydumper для mysqldump --single-transaction.
   • Полезно, если все таблицы — InnoDB.
   • Поток main должен хранить глобальную блокировку только до тех пор, пока потоки дампа не смогут запустить транзакцию.
   • Обеспечивает минимальную продолжительность глобальной блокировки

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

   Переменные этой команды описаны ниже:

   HOW-TO-MANAGE-FIREWALL-PORTAL --host: имя основного сервера

   • --user: имя пользователя (в формате имя_пользователя@имя_сервера, так как сервер-источник работает на отдельном сервере Базы данных Azure для MySQL). Вы можете использовать администратора сервера или пользователя, у которого есть разрешения SELECT и RELOAD.
   • --Password: пароль этого пользователя

   Дополнительные сведения об использовании mydumper см. в статье о mydumper/myloader

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

   cat ./backup/metadata
   

   В этой команде ./backup относится к выходному каталогу, используемому в команде на предыдущем шаге.

   Результаты должны выглядеть, как показано на следующем рисунке:

   

   Не забудьте записать имя двоичного файла, так как оно понадобится на последующих этапах.

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

   myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt
   

   Переменные этой команды описаны ниже:

   • --host: имя сервера-реплики
   • --user: имя пользователя. Вы можете использовать администратора сервера или пользователя с разрешением на чтение и запись, который может восстанавливать схемы и данные в базу данных.
   • --Password: пароль этого пользователя

8. В зависимости от принудительного применения SSL на сервере-источнике подключитесь к серверу-реплике с помощью клиентского средства MySQL и выполните следующие действия.

   • Если принудительное применение SSL включено, то:

     i. Загрузите сертификат, необходимый для подключения к серверу Базы данных Azure для MySQL по протоколу SSL, здесь.

     ii. Откройте файл в блокноте и вставьте его содержимое в раздел "ПОМЕСТИТЬ КОНТЕКСТ СЕРТИФИКАТА ОТКРЫТОГО КЛЮЧА ЗДЕСЬ".

     SET @cert = '-----BEGIN CERTIFICATE-----
     PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE
     -----END CERTIFICATE-----'
     

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

     CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);
     

     Примечание.

     Определите расположение и имя файла из сведений, полученных на шаге 6.

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

     CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, '');
     

9. Чтобы запустить репликацию с сервера реплики, вызовите приведенную ниже хранимую процедуру.

   call  mysql.az_replication_start;
   

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

    show slave status \G;
    

    Примечание.

    Если вы используете MySQL Workbench, модификатор \G не требуется.

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

Проверка реплика tion (необязательно)

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

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

   select count(*) from customers;
   

2. Запишите число записей для последующего сравнения.

   Чтобы проверить репликацию, попробуйте добавить данные в таблицы Customers на сервере-источнике, а затем убедитесь, что репликация новых данных выполнена. В этом случае вы добавите две строки в таблицу на основном сервере, а затем убедитесь, что они реплика на сервере реплика.

3. В таблице Customers на сервере-источнике вставьте строки, выполнив следующую команду:

   insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
   (<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');
   

4. Чтобы проверить состояние репликации, вызовите show slave status \G, чтобы убедиться, что репликация работает, как ожидалось.

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

   select count(*) from customers;
   

Проверка успешности перехода

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

1. Настройте соответствующие правила брандмауэра на уровне сервера и виртуальной сети для подключения к целевому серверу. Вы можете сравнить правила брандмауэра для источника и целевого объекта на портале.
2. Настройте соответствующие имена входа и разрешения уровня базы данных на целевом сервере. Вы можете запустить SELECT FROM mysql.user; на исходных и целевых серверах для сравнения.
3. Убедитесь, что все входящие подключения к отдельному серверу Базы данных Azure для MySQL остановлены.

   Совет

   Вы можете настроить отдельный сервер Базы данных Azure для MySQL только для чтения.

4. Убедитесь, что реплика синхронизирована с источником, выполнив команду show slave status \G и убедившись, что значение параметра Seconds_Behind_Master равно 0.
5. Перенаправьте клиентов и клиентские приложения на целевой экземпляр гибкого сервера Базы данных Azure для MySQL.
6. Выполните окончательный переход, выполнив хранимую процедуру mysql.az_replication_stop, которая остановит репликацию на сервере-реплике.
7. Вызовите mysql.az_replication_remove_master, чтобы удалить конфигурацию миграции входных данных.

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

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

• Репликация данных в гибкий сервер База данных Azure для MySQL
• Настройка База данных Azure для MySQL гибкого реплика сервера
• Устранение распространенных ошибок в База данных Azure для MySQL
• Перенос MySQL в База данных Azure для MySQL в автономном режиме с помощью Azure Database Migration Service