Поделиться через

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

  • Статья

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

Важно!

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

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

Примечание.

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

Чтобы создать реплику в службе "База данных Azure для MySQL", Репликация входных данных синхронизирует данные с исходного локального сервера MySQL, на виртуальных машинах (VM) или в облачных службах баз данных. Репликация входных данных основана на позиции файла двоичного журнала (binlog) или на функции собственной репликации в MySQL на базе GTID. Дополнительные сведения о репликации binlog MySQL см. в этой статье.

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

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

  1. Создайте новый экземпляр одного сервера База данных Azure для MySQL (например, replica.mysql.database.azure.com). Дополнительные сведения см. в статье о создании сервера Базы данных Azure для MySQL с помощью портала Azure. Этот сервер будет сервером-репликой в процессе репликации входных данных.

    Важно!

    Сервер базы данных Azure для MySQL должен быть создан в ценовой категории общего назначения или с оптимизацией для операций в памяти, так как репликация данных поддерживается только на этих уровнях. GTID поддерживается в версиях 5.7 и 8.0 и только на серверах, поддерживающих хранилище объемом до 16 ТБ (хранилище данных общего назначения версии 2).

  2. Создайте одинаковые учетные записи пользователей и соответствующие привилегии.

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

  3. Добавьте IP-адрес исходного сервера в правила брандмауэра для реплики.

    Измените правила брандмауэра на портале Azure или с помощью Azure CLI.

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

    Enable GTID on Azure Database for MySQL server

Настройка исходного сервера MySQL

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

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

  2. Убедитесь, что исходный сервер разрешает как входящий, так и исходящий трафик через порт 3306 и что у исходного сервера общедоступный IP-адрес (и при этом DNS является публично доступным) либо полное доменное имя (FQDN).

    Проверьте подключение к исходному серверу — попытайтесь подключиться из такого средства, как командная строка MySQL, размещенного на другом компьютере, или из Azure Cloud Shell, доступного на портале Azure.

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

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

    2. Выполните указанный ниже запрос.

      mysql> SELECT @@global.redirect_server_host;

      Ниже приведен пример выходных данных:

      +-----------------------------------------------------------+
| @@global.redirect_server_host                             |
+-----------------------------------------------------------+
| e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
 +-----------------------------------------------------------+

    3. Выйдите из командной строки MySQL.

    4. Чтобы получить IP-адрес, выполните следующую команду в служебной программе ping:

      ping <output of step 2b>

      Например:

      C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.

    5. Настройте правила брандмауэра исходного сервера, чтобы включить IP-адрес, выведенный на предыдущем шаге, на порту 3306.

      Примечание.

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

  3. Включите ведение двоичного журнала.

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

    SHOW VARIABLES LIKE 'log_bin';

    Если переменная log_bin возвращается со значением ON (Вкл.), ведение двоичного журнала на сервере включено.

    Если для log_bin возвращается значение OFF (Выкл.) и исходный сервер запущен локально или на виртуальных машинах, где можно получить доступ к файлу конфигурации (my.cnf), выполните следующие действия:

    1. На исходном сервере найдите файл конфигурации MySQL (my.cnf). Пример: /etc/my.cnf

    2. Откройте файл конфигурации на редактирование и найдите в нем раздел mysqld.

    3. В раздел MySQL добавьте следующую строку:

      log-bin=mysql-bin.log

    4. Перезапустите исходный сервер MySQL, чтобы изменения вступили в силу.

    5. После перезапуска сервера убедитесь, что двоичное ведение журнала включено, выполнив тот же запрос, что и раньше:

      SHOW VARIABLES LIKE 'log_bin';

  4. Настройте параметры исходного сервера.

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

    SET GLOBAL lower_case_table_names = 1;

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

    show variables like 'gtid_mode';

    Важно!

    Для всех серверов по умолчанию для gtid_mode установлено значение OFF (Выкл.). Включать GTID на исходном сервере MySQL специально для настройки Репликации входных данных не требуется. Если GTID уже включен на исходном сервере, можно также использовать реплика на основе GTID для настройки репликации данных с одним сервером База данных Azure для MySQL. Чтобы настроить репликацию данных для всех серверов независимо от конфигурации gtid_mode на исходном сервере, используйте файловую репликацию.

  5. Создайте новую роль репликации и настройте разрешения.

    Создайте учетную запись пользователя на исходном сервере и назначьте ей привилегии репликации. Это можно сделать с помощью команд SQL или такого средства, как MySQL Workbench. Определите, планируется ли репликация с использованием SSL, так как это будет необходимо указать при создании пользователя. Узнать, как добавить учетные записи пользователей на исходном сервере, можно в документации по MySQL.

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

    Команда SQL

    Репликация с использованием SSL

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

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

    Репликация без SSL

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

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

    MySQL Workbench

    Чтобы создать роль репликации в MySQL Workbench, откройте панель Users and Privileges (Пользователи и привилегии) с панели Management (Управление) и выберите Add Account (Добавить учетную запись).

    Users and Privileges

    Введите имя пользователя в поле Login Name (Имя входа).

    Sync user

    Откройте панель Administrative Roles (Роли администрирования), а затем выберите Replication Slave (Ведомая роль репликации) из списка Global Privileges (Глобальные привилегии). Выберите Apply (Применить), чтобы создать роль репликации.

    Replication Slave

  6. Настройте для исходного сервера режим только для чтения.

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

    FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

  7. Узнайте имя файла двоичного журнала и смещение.

    Выполните команду show master status, чтобы определить текущее имя файла двоичного журнала и его смещение.

     show master status;

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

    Master Status Results

Создание резервной копии и восстановление исходного сервера

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

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

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

    show global variables like 'gtid_executed';

  3. Настройте для исходного сервера режим для чтения и записи.

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

  4. Восстановите файл дампа на новом сервере.

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

  5. Необязательно: найдите GTID восстановленного сервера в Базе данных Azure для MySQL, чтобы убедиться, что он совпадает с этим значением на исходном сервере. Чтобы найти очищенное значение GTID (gtid_purged) на сервере реплики Базы данных Azure для MySQL, можно использовать указанную ниже команду. Чтобы репликация на основе GTID работала, значение gtid_purged должно быть таким же, как и gtid_executed на главном сервере, которое вы нашли на шаге 2.

    show global variables like 'gtid_purged';

  1. Настройте исходный сервер.

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

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

    CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

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

    call mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_ssl_ca>');

    • master_host: имя узла исходного сервера

    • master_user: имя пользователя для исходного сервера.

    • master_password: пароль для исходного сервера.

    • master_port: номер порта, на котором исходный сервер прослушивает подключения (порт по умолчанию, на котором прослушивается MySQL, — 3306).

    • master_log_file: имя файла двоичного журнала из выполняемой команды show master status.

    • master_log_pos: позиция в двоичном журнале из выполняемой команды show master status.

    • master_ssl_ca: контекст сертификата центра сертификации. Если протокол SSL не используется, передайте пустую строку.

      Этот параметр рекомендуется передавать в виде переменной. Дополнительные сведения представлены в примерах ниже.

    Примечание.

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

    Примеры

    Репликация с использованием SSL

    Переменная @cert создается путем выполнения следующих команд MySQL:

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

    Репликация с использованием SSL настраивается между исходным сервером, размещенным в домене companya.com, и сервером-репликой, размещенным в Базе данных Azure для MySQL. Эта хранимая процедура выполняется на реплике.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

    Репликация без SSL

    Репликация без SSL настраивается между исходным сервером, размещенным в домене companya.com, и сервером-репликой, размещенным в Базе данных Azure для MySQL. Эта хранимая процедура выполняется на реплике.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

  2. Настройте фильтрацию.

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

    Чтобы узнать больше об этом параметре, ознакомьтесь с документацией по MySQL.

    Для изменения этого параметра используйте портал Azure или Azure CLI.

  3. Запустите репликацию.

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

    CALL mysql.az_replication_start;

  4. Проверьте состояние репликации.

    Вызовите команду show slave status на сервере-реплике, чтобы просмотреть состояние репликации.

    show slave status;

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

Другие полезные хранимые процедуры для операций Репликации входных данных

Остановить репликацию

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

CALL mysql.az_replication_stop;

Удаление связи репликации

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

CALL mysql.az_replication_remove_master;

Пропуск ошибки репликации

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

CALL mysql.az_replication_skip_counter;

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

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

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

Важно!

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

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

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Show binary log results

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