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

  • Статья

Важно!

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

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

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

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

Примечание.

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

Примечание.

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

Создание сервера MariaDB для использования в качестве реплики

  1. Создайте новый сервер Базы данных Azure для MariaDB (например, replica.mariadb.database.azure.com). Этот сервер будет сервером-репликой в процессе репликации входных данных.

    Дополнительные сведения о создании сервера см. в статье Создание сервера Базы данных Azure для MariaDB с помощью портала Azure.

    Важно!

    Вы должны создать сервер Базы данных Azure для MariaDB в ценовой категории "Общего назначения" или "Оптимизировано для памяти".

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

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

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

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

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

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

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

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

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

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

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

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

      SELECT @@global.redirect_server_host;

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

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

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

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

      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, чтобы log_bin=ON включил ведение двоичного журнала. Перезапустите сервер, чтобы изменения вступили в силу.

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

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

    SET GLOBAL lower_case_table_names = 1;

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

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

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

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

    Дополнительные сведения об указании имен учетных записей см. в документации по MariaDB.

    Команда 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, на панели Management (Управление) выберите Users and Privileges (Пользователи и привилегии). Затем выберите Add Account (Добавить учетную запись).

    Users and Privileges

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

    Sync user

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

    Replication Slave

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

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

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

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

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

    show master status;

    Результаты должны иметь следующий вид:

    Master Status Results

    Запишите имя двоичного файла, так как оно будет использоваться на дальнейших этапах.

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

    Выполните функцию BINLOG_GTID_POS, чтобы получить расположение GTID для соответствующего имени и смещения файла binlog.

    select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);

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

  1. Создайте резервную копию всех баз данных из исходного сервера.

    Используйте mysqldump, чтобы создать резервную копию всех баз данных из исходного сервера. Нет необходимости создавать резервную копию библиотеки MySQL и тестовой библиотеки.

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

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

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

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

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

    Восстановите файл дампа на сервере, созданном в базе данных Azure для MariaDB. Чтобы узнать, как восстановить файл дампа на сервере MariaDB, см. статью о дампе и восстановлении.

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

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

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

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

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

    or

    CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', 3306, '<master_gtid_pos>', '<master_ssl_ca>');
    • master_host: имя узла исходного сервера
    • master_user: имя пользователя для исходного сервера.
    • master_password: пароль для исходного сервера.
    • master_log_file: имя файла двоичного журнала из выполняемой команды show master status.
    • master_log_pos: позиция в двоичном журнале из выполняемой команды show master status.
    • master_gtid_pos: расположение GTID из выполняющегося select BINLOG_GTID_POS('<binlog file name>', <binlog offset>);
    • master_ssl_ca: контекст сертификата центра сертификации. Если вы не используете SSL, передайте пустую строку.*

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

    Примеры

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

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

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

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

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

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

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

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

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

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

    CALL mysql.az_replication_start;

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

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

    show slave status;

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

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

    Из-за собственного ограничения реплика tion в MariaDB необходимо задать sync_master_info и sync_relay_log_info переменные для реплика tion без сценария GTID.

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

Другие хранимые процедуры

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

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

CALL mysql.az_replication_stop;

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

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

CALL mysql.az_replication_remove_master;

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

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

CALL mysql.az_replication_skip_counter;

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

См. дополнительные сведения о репликации входных данных в базе данных Azure для MariaDB.