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

  • Статья

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

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

Примечание.

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

Чтобы создать реплика в гибком экземпляре сервера База данных Azure для MySQL, функция реплика tion data-in синхронизирует данные из исходного сервера MySQL в локальной среде, на виртуальных машинах или в облачных службах баз данных. Данные в реплика можно настроить с помощью реплика реплика tion OR GTID на основе реплика файла в двоичном журнале (binlog). Дополнительные сведения о реплика бинлога см. в разделе "Репликация 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'@'%';

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

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

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

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

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

[!ПРИМЕЧАНИЕ]

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

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

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

Примечание.

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

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

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

  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.

Чтобы связать два сервера и запустить реплика tion, войдите на целевой сервер реплика в службе База данных 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, '');

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

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

    CALL mysql.az_replication_start;

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

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

    show slave status;

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

Seconds_Behind_Master Если значение равно "0", реплика tion работает хорошо. 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]

Show binary log results

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

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