19.1.2.6 Setting Up Replicas — MySQL 9.2

19.1.2.6 Настройка реплик

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

Настроен источник с необходимыми свойствами конфигурации. См. Раздел 19.1.2.1, «Настройка конфигурации источника репликации».
Получена информация о статусе источника или копия файла индекса бинарного лога источника, созданная во время остановки для создания моментальной копии данных. См. Раздел 19.1.2.4, «Получение координат бинарного лога источника репликации».
На источнике снят блокировка чтения:
```
mysql> UNLOCK TABLES;
```
На реплике отредактирована конфигурация MySQL. См. Раздел 19.1.2.2, «Настройка конфигурации реплики».

Следующие шаги зависят от наличия существующих данных для импорта в реплику. Дополнительную информацию см. в Разделе 19.1.2.5, «Выбор метода для моментальных снимков данных». Выберите один из следующих вариантов:

Если у вас нет моментальной копии базы данных для импорта, см. Раздел 19.1.2.6.1, «Настройка репликации с новым источником и репликами».
Если у вас есть моментальная копия базы данных для импорта, см. Раздел 19.1.2.6.2, «Настройка репликации с существующими данными».

19.1.2.6.1 Настройка репликации с новым источником и репликами

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

Для настройки репликации между источником и новой репликой:

Запустите реплику.
Выполните оператор CHANGE REPLICATION SOURCE TO на реплике для настройки конфигурации источника. См. Раздел 19.1.2.7, «Настройка конфигурации источника на реплике».

Выполните эти шаги по настройке реплики для каждой реплики.

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

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

$> mysql -h source < fulldb.dump

19.1.2.6.2 Настройка репликации с существующими данными

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

Подсказка

Для развертывания нескольких экземпляров MySQL вы можете использовать , что позволяет легко администрировать группу экземпляров сервера MySQL. InnoDB Cluster оборачивает MySQL Group Replication в программную среду, что позволяет легко развернуть кластер экземпляров MySQL для достижения высокой доступности. Кроме того, InnoDB Cluster бесшовно интегрируется с , что позволяет вашим приложениям подключаться к кластеру без написания собственного процесса failover. Однако для аналогичных случаев использования, не требующих высокой доступности, вы можете использовать . Инструкции по установке MySQL Shell можно найти .

Примечание

Если сервер источника репликации или существующая реплика, которую вы копируете для создания новой реплики, имеют запланированные события, убедитесь, что они отключены на новой реплике перед ее запуском. Если событие выполняется на новой реплике, которое уже выполнилось на источнике, дублируемая операция вызывает ошибку. Планировщик событий контролируется системной переменной event_scheduler (значение по умолчанию ON), поэтому события, активные на исходном сервере, по умолчанию выполняются при запуске новой реплики. Чтобы остановить выполнение всех событий на новой реплике, установите системную переменную event_scheduler в OFF или DISABLED на новой реплике. В качестве альтернативы вы можете использовать инструкцию ALTER EVENT, чтобы установить отдельные события в DISABLE или DISABLE ON REPLICA, чтобы предотвратить их выполнение на новой реплике. Вы можете перечислить события на сервере, используя инструкцию SHOW или таблицу Информационной схемы EVENTS. Для получения дополнительной информации см. Раздел 19.5.1.16 «Репликация вызываемых функций».

В качестве альтернативы созданию новой реплики таким образом, можно использовать плагин клонирования MySQL Server для передачи всех данных и настроек репликации с существующей реплики на клон. Инструкции по использованию этого метода см. в Разделе 7.6.7.7 «Клонирование для репликации».

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

Если вы использовали плагин клонирования MySQL Server для создания клона из существующей реплики (см. Раздел 7.6.7.7 «Клонирование для репликации»), данные уже перенесены. В противном случае импортируйте данные на реплику, используя один из следующих методов.
1. Если вы использовали mysqldump, запустите сервер реплики, убедившись, что репликация не запускается, запустив сервер с помощью --skip-replica-start. Затем импортируйте файл дампа:
```
$> mysql < fulldb.dump
```
2. Если вы создали моментальный снимок, используя исходные файлы данных, извлеките файлы данных в каталог данных вашей реплики. Например:
```
$> tar xvf dbdump.tar
```
  Возможно, вам потребуется установить права и владельца на файлы, чтобы сервер реплики мог получить к ним доступ и изменять их. Затем запустите сервер реплики, убедившись, что репликация не запускается, используя --skip-replica-start.
Настройте реплику с координатами репликации из источника. Это указывает реплике, какой файл журнала бинарных логов и позицию в файле, с которой нужно начать репликацию. Также настройте реплику с учетными данными для входа и именем хоста источника. Более подробная информация об инструкции CHANGE REPLICATION SOURCE TO приведена в Разделе 19.1.2.7 «Настройка конфигурации источника на реплике».
Запустите потоки репликации, выполнив инструкцию START REPLICA.

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

Реплика использует информацию, записанную в репозитории метаданных подключения и репозитории метаданных прикладного слоя, чтобы отслеживать, сколько журнала бинарных логов источника она обработала. По умолчанию эти репозитории являются таблицами с именами slave_master_info и slave_relay_log_info в базе данных mysql. Не удаляйте и не редактируйте эти таблицы, если вы не знаете точно, что делаете, и полностью не понимаете последствий. Даже в этом случае предпочтительнее использовать инструкцию CHANGE REPLICATION SOURCE TO для изменения параметров репликации. Реплика использует значения, указанные в инструкции, для автоматического обновления репозиториев метаданных репликации. Дополнительная информация приведена в Разделе 19.2.4 «Журнал релеев и репозитории метаданных репликации».

Примечание

Содержимое репозитория метаданных подключения реплики переопределяет некоторые параметры сервера, указанные в командной строке или в my.cnf. Подробности см. в Разделе 19.1.6 «Параметры и переменные репликации и двоичного логирования».

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