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

Репликация данных в Базе данных Azure для MySQL (гибкий сервер)

  • Статья

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

Примечание.

Настройка репликации данных для серверов с поддержкой высокой доступности поддерживается только с помощью репликации на основе GTID.

Когда следует использовать Репликацию входных данных

Ниже приведены основные сценарии с применением Репликации входных данных:

  • Гибридная синхронизация данных. С помощью Репликации входных данных можно обеспечить синхронизацию данных между локальными серверами и Базой данных Azure для MySQL — гибкий сервер. Эта синхронизация помогает создавать гибридные приложения. Этот метод удобен, если у вас есть локальный сервер базы данных, но вы хотите переместить данные в регион, который расположен ближе к пользователям.
  • Многооблачная синхронизация. Для сложных облачных решений Репликацию входных данных можно использовать, чтобы синхронизировать данные между Базой данных Azure для MySQL — гибкий сервер и различными облачными поставщиками, включая виртуальные машины и службы баз данных, размещенные в этих облаках.
  • Миграция: клиенты могут перенести в минимальное время с помощью таких средств с открытым кодом, как MyDumper/MyLoader с репликацией данных. При использовании Репликации входных данных возможна выборочная прямая миграция рабочей нагрузки из исходной базы данных в целевую.

Используйте Azure Database Migration Service(DMS) для сценариев миграции.

Рекомендации и ограничения

Нереплицируемые данные

Системная база данных MySQL на исходном сервере не реплицируется. Кроме того, изменения учетных записей и разрешений на исходном сервере не реплицируются. Если вы создаете на исходном сервере учетную запись, которой требуется доступ к серверу-реплике, вручную создайте ту же учетную запись на сервере-реплике. Сведения о таблицах в системной базе данных см. в руководстве mySQL.

Репликация данных поддерживается на серверах с поддержкой высокой доступности (HA)

Поддержка репликации данных для сервера с поддержкой высокой доступности (HA) доступна только через репликацию на основе GTID.

Хранимая процедура репликации с помощью GTID доступна на всех серверах с поддержкой высокого уровня доступности по имени mysql.az_replication_change_master_with_gtid.

Фильтр

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

Требования

  • На исходном сервере должна быть установлена версия MySQL не ниже 5.7.

  • Мы рекомендуем использовать исходный сервер и сервер-реплику одной версии. Например, оба должны быть MySQL версии 5.7 или mySQL версии 8.0.

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

  • Исходный сервер должен использовать ядро InnoDB MySQL.

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

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

  • Если на исходном сервере включен SSL, необходимо включить SSL-сертификат ЦС, предоставленный для домена, в хранимую процедуру mysql.az_replication_change_master. См. следующие примеры и параметр master_ssl_ca.

  • Убедитесь, что компьютер, на котором размещен исходный сервер, разрешает входящий и исходящий трафик на порту 3306.

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

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

Созданный невидимый первичный ключ

Для MySQL версии 8.0 и выше созданные невидимые первичные ключи (GIPK) по умолчанию включены для всех экземпляров гибкого сервера База данных Azure для MySQL. Серверы MySQL 8.0+ добавляют невидимый столбец my_row_id в таблицы и первичный ключ в этом столбце, где таблица InnoDB создается без явного первичного ключа. Эта функция, если включена, может повлиять на некоторые варианты использования репликации данных, как описано ниже:

  • Репликация данных завершается ошибкой репликации: ERROR 1068 (42000): несколько первичных ключей, определенных", если исходный сервер создает первичный ключ в таблице без первичного ключа. Для устранения рисков выполните следующую команду SQL, пропустите ошибку репликации и перезапустите репликацию данных.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Репликация данных завершается ошибкой репликации: "ERROR 1075 (42000): неправильное определение таблицы; может быть только один автоматический столбец, и он должен быть определен как ключ", если исходный сервер добавляет столбец auto_increment в качестве уникального ключа. Для устранения рисков выполните следующую команду SQL, задайте для параметра "sql_generate_invisible_primary_key" значение OFF, пропустите ошибку репликации и перезапустите репликацию данных.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Репликация данных завершается ошибкой, если исходный сервер запускает любой другой SQL, который не поддерживается, если параметр sql_generate_invisible_primary_key включен. Например, создайте таблицу секционирования. В таком сценарии для устранения рисков необходимо задать значение "sql_generate_invisible_primary_key" как OFF и перезапустить репликацию данных.

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