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

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

  • Статья

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

  2. Требования к сети

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

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

    • Проверьте, предоставляем ли мы подключение типа "сеть — сеть" к локальным исходным серверам с помощью ExpressRoute или VPN. Дополнительные сведения см. в статье Документация по виртуальной сети, где особое внимание стоит уделить кратким руководствам с пошаговыми инструкциями.

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

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

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

  3. Следуйте соответствующим инструкциям, если вы хотите использовать позицию журнала bin-log или репликацию на основе GTID.

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

    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 между исходным сервером и сервером-репликой. Этот параметр по умолчанию равен 1 в База данных Azure для MySQL гибком сервере.

    SET GLOBAL lower_case_table_names = 1;

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

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

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

    Репликация с использованием 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'@'%';

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

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

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

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

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

    show master status;

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

    Результаты состояния основного сервера

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

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

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

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

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

    Примечание.

    Перед возвратом сервера на режим чтения и записи можно получить сведения GTID с помощью глобальной переменной GTID_EXECUTED. Это будет использоваться на более позднем этапе для задания GTID на сервере-реплике.

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

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

Примечание.

Если вы хотите избежать настройки базы данных только для чтения при выполнении дампа и восстановления, можно использовать mydumper/myloader.

Установка GTID на сервере реплики

  1. Пропустить шаг при использовании репликации на основе позиций в журнале bin

  2. Сведения GTID из файла дампа, взятого из источника, необходимы для сброса журнала GTID целевого сервера (реплики).

  3. Используйте эти сведения GTID из источника для выполнения сброса GTID на сервере-реплике с помощью следующей команды CLI:

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>

Дополнительные сведения см. в разделе "Сброс GTID".

Примечание.

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

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

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

    Чтобы связать два сервера и запустить репликацию, войдите на целевой сервер-реплику в службе База данных Azure для MySQL и задайте внешний экземпляр в качестве исходного сервера. Это делается с помощью mysql.az_replication_change_master или mysql.az_replication_change_master_with_gtid хранимой процедуры на сервере База данных 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>');

    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" значение "ВКЛ", чтобы разрешить исходному серверу и серверу реплики взаимодействовать друг с другом. Этот параметр можно изменить в параметрах Безопасность подключения. Дополнительные сведения см. в разделе Управление правилами брандмауэра с помощью портала.
    • Если вы использовали mydumper/myloader для создания дампа базы данных, можно получить master_log_file и master_log_pos из файла /backup/metadata.

    Примеры

    Репликация с использованием 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);

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);

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

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

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

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

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

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

    CALL mysql.az_replication_start;

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

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

    show slave status;

    Чтобы узнать правильное состояние репликации, обратитесь к метрикам репликации — состояние реплики ввода-вывода и состояние SQL реплики SQL на странице мониторинга.

    Если значение 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;

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

Вывод результатов двоичного журнала

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

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