Share via

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: Отдельный сервер Базы данных Azure MySQL Гибкий сервер Базы данных Azure MySQL

Важно!

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

Примечание.

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

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

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

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

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

Замечания, связанные с быстродействием

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

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

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

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

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

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

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

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

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

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

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

    Примечание.

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

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

    Важно!

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

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

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

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

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

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

Важно!

Если исходный экземпляр Amazon RDS для MySQL имеет GTID_mode значение ON, целевой экземпляр База данных Azure для MySQL гибкого сервера также должен иметь значение ON GTID_mode.

Настройте целевой экземпляр Базы данных 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 гибкого экземпляра сервера до максимального количества 64 виртуальных ядер. Этот размер предоставляет больше вычислительных ресурсов при восстановлении дампа базы данных исходного сервера.

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

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

    Примечание.

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

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

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

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

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

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

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

    mysql> 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 хранимую процедуру, чтобы убедиться, что двоичные журналы хранятся на исходном сервере в течение требуемого времени. Например:

    Mysql> 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 для MySQL догнать исходный сервер Amazon RDS для MySQL.

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

      Mysql> call mysql.rds_stop_replication;

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

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

    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, выполните следующие команды:

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

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

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

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

  3. Чтобы связать исходный сервер Amazon RDS для MySQL и гибкий целевой сервер База данных Azure для MySQL, войдите в целевой экземпляр База данных Azure для MySQL гибкого сервера. Установите сервер 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, выполните следующую команду:

    Mysql> CALL mysql.az_replication_start;

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

    Mysql> show slave status\G

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

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

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

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

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

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

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

Следующие шаги

  • Дополнительные сведения о переносе баз данных на гибкий сервер База данных Azure для MySQL см. в руководстве по миграции баз данных.
  • Посмотрите видео Простой перенос приложений MySQL/PostgreSQL в управляемую службу Azure. Он содержит демонстрацию, в котором показано, как перенести приложения MySQL на гибкий сервер База данных Azure для MySQL.