Share via

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

  • Статья

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

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

Примечание.

Настройка реплика обработки данных для серверов с поддержкой высокой доступности поддерживается только через реплика на основе GTID.

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

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

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

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

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

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

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

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

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

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

Фильтр

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

Requirements

  • На исходном сервере должна быть установлена версия 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 создается без явного первичного ключа. Эта функция может повлиять на некоторые варианты использования реплика данных, как описано ниже:

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

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

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

    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 и перезапустить данные в реплика.

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