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

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных 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. Создание новой роли реплика и настройка разрешения

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

    В следующих командах новая роль реплика tion может получить доступ к источнику с любого компьютера, а не только к тому, который размещает сам источник. Для этого следует указать "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 в других облачных поставщиках или локальной среде. В этом случае необходимо использовать фильтр реплика tion для фильтрации пользовательских таблиц Azure на сервере реплика. Это можно сделать, задав Replicate_Wild_Ignore_Table = "mysql.__%", чтобы отфильтровать внутренние таблицы База данных Azure для MySQL гибкого сервера mysql. Дополнительные сведения об изменении этого параметра сервера см. в руководстве по MySQL 5.7:: 13.4.2.2 CHANGE REPLICATION FILTER Statement .

  2. Задайте сервер реплика путем подключения к нему и открытия оболочки MySQL на сервере реплика. В командной строке выполните следующую операцию, которая настраивает несколько параметров реплика tion 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 в контексте реплика tion см. в статье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" в источнике, чтобы разрешить источнику и реплика серверам обмениваться данными. Этот параметр можно изменить из параметров безопасности подключения. Дополнительные сведения см. в статье "Управление правилами брандмауэра" с помощью портала.

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

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