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

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

  • Статья

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

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

Примечание.

В этой статье упоминается термин "раб", термин, который корпорация Майкрософт больше не использует. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.

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

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

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

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

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

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

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

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

    Примечание.

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

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

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

    SHOW VARIABLES LIKE 'log_bin';

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

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

    Создайте учетную запись пользователя на настроенном исходном сервере с правами репликации. Это можно сделать с помощью команд 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'@'%';

Дампа и восстановление исходного сервера.

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

SET GLOBAL read_only = OFF;
UNLOCK TABLES;

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

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

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

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

SET GLOBAL read_only = OFF;
UNLOCK TABLES;
  1. Восстановите файл дампа на новом сервере. Восстановите файл дампа на сервер, созданный на База данных Azure для MySQL гибком сервере. Дополнительные сведения см. в статье "Дампа" и "Восстановление" для восстановления файла дампа в База данных Azure для MySQL экземпляр гибкого сервера. Если файл дампа имеет большой размер, отправьте его на виртуальную машину в Azure в том же регионе, где располагается сервер-реплика. Восстановите его на экземпляр гибкого сервера База данных Azure для MySQL из виртуальной машины.

Примечание.

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

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

  1. Фильтрация

    Предположим, что репликация исходящего данных настраивается между База данных Azure для MySQL гибким сервером и внешним Сервером MySQL в других облачных поставщиках или локальной среде. В этом случае необходимо использовать фильтр репликации для фильтрации пользовательских таблиц Azure на сервере реплики. Это можно сделать, задав Replicate_Wild_Ignore_Table = "mysql.__%" для фильтрации внутренних таблиц mysql База данных Azure для MySQL гибкого сервера. Дополнительные сведения об изменении этого параметра сервера см. в руководстве по MySQL 5.7:: 13.4.2.2 CHANGE REPLICATION FILTER Statement .

  2. Задайте сервер реплики, подключив его и открыв оболочку MySQL на сервере-реплике. В командной строке выполните следующую операцию, которая настраивает несколько параметров репликации MySQL одновременно:

    CHANGE THE REPLICATION SOURCE TO
SOURCE_HOST='<master_host>',
SOURCE_USER='<master_user>',
SOURCE_PASSWORD='<master_password>',
SOURCE_LOG_FILE='<master_log_file>',
SOURCE_LOG_POS=<master_log_pos>
    • master_host: имя узла исходного сервера (например, "source.mysql.database.Azure.com")
    • master_user: имя пользователя для исходного сервера (например, syncuser'@'%)
    • master_password: пароль для исходного сервера.
    • master_log_file: имя файла двоичного журнала при выполнении отображения главного состояния
    • master_log_pos: позиция двоичного журнала от запуска отображения главного состояния

    Примечание.

    Чтобы использовать SSL для подключения, добавьте атрибут SOURCE_SSL=1 в команду. Дополнительные сведения об использовании SSL в контексте репликации см. в разделе . https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html

  3. Активируйте сервер-реплику с помощью следующей команды.

    START REPLICA;

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

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

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

     show slave status;

    Если состояние Slave_IO_Running и Slave_SQL_Running yes и значение Seconds_Behind_Master 0равно, репликация работает хорошо. Seconds_Behind_Master указывает время запаздывания реплики. Реплика обрабатывает обновления, если значение не 0является.

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

    Если вы использовали mydumper/myloader для дампа базы данных, вы можете получить master_log_file и master_log_pos из файла /backup/metadata.

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