19.1.2.8 Adding Replicas to a Replication Environment — MySQL 9.2

19.1.2.8 Добавление реплик в среду репликации

Вы можете добавить еще одну реплику в существующую конфигурацию репликации, не останавливая сервер-источник. Для этого можно настроить новую реплику, скопировав каталог данных существующей реплики, и присвоить новой реплике другой идентификатор сервера (указывается пользователем) и UUID сервера (генерируется при запуске).

Примечание

Если сервер-источник репликации или существующая реплика, которую вы копируете для создания новой реплики, имеют запланированные события, убедитесь, что эти события отключены на новой реплике перед ее запуском. Если событие выполняется на новой реплике, которое уже было выполнено на источнике, дублируемая операция приводит к ошибке. Планировщик событий управляется системной переменной 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 «Клонирование для репликации».

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

Остановите существующую реплику и запишите информацию о статусе реплики, в частности, позиции файла бинарного журнала и файла журнала пересылки. Вы можете просмотреть статус реплики либо в таблицах репликации Performance Schema (см. раздел 29.12.11 «Таблицы репликации Performance Schema»), либо выполнив оператор SHOW REPLICA STATUS следующим образом:
```
mysql> STOP REPLICA;
mysql> SHOW REPLICA STATUS\G
```
Остановите существующую реплику:
```
$> mysqladmin shutdown
```
Скопируйте каталог данных с существующей реплики на новую реплику, включая файлы журналов и файлы журнала пересылки. Это можно сделать, создав архив с помощью tar или WinZip, или выполнив прямую копию с помощью инструмента, такого как cp или rsync.
Важно
- Перед копированием убедитесь, что все файлы, относящиеся к существующей реплике, фактически хранятся в каталоге данных. Например, табличное пространство InnoDB, пространство таблиц отмены и журнал повторных записей могут храниться в альтернативном расположении. InnoDB файлы табличного пространства и пространства таблиц на основе файлов на таблицу могут быть созданы в других каталогах. Файлы бинарных журналов и журналов пересылки для реплики могут храниться в собственных каталогах вне каталога данных. Проверьте системные переменные, заданные для существующей реплики, и найдите все указанные альтернативные пути. Если вы найдете какие-либо, скопируйте и эти каталоги.
- Во время копирования, если файлы используются для репозиториев метаданных репликации (см. раздел 19.2.4 «Журнал пересылки и репозитории метаданных репликации»), убедитесь, что вы также копируете эти файлы с существующей реплики на новую реплику. Если для репозиториев используются таблицы (это значение по умолчанию, таблицы находятся в каталоге данных).
- После копирования удалите файл auto.cnf из копии каталога данных на новой реплике, чтобы новая реплика стартовала с другим сгенерированным UUID сервера. UUID сервера должен быть уникальным.
Распространенная проблема, возникающая при добавлении новых реплик, заключается в том, что новая реплика завершает работу с рядом сообщений об ошибках и предупреждениях, подобных этим:
```
071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
replication may break when this MySQL server acts as a replica and has his hostname
changed!! Please use '--relay-log=new_replica_hostname-relay-bin' to avoid this problem.
071118 16:44:10 [ERROR] Failed to open the relay log './old_replica_hostname-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure
```
Эта ситуация может возникнуть, если системная переменная relay_log не задана, так как файлы журнала пересылки содержат имя хоста в качестве части их имен файлов. Это также верно для файла индекса журнала пересылки, если системная переменная relay_log_index не используется. Дополнительную информацию об этих переменных см. в разделе 19.1.6 «Параметры и переменные репликации и бинарного ведения журнала».

Чтобы избежать этой проблемы, используйте то же значение для relay_log на новой реплике, что и на существующей реплике. Если этот параметр не был явно задан на существующей реплике, используйте existing_replica_hostname-relay-bin. Если это невозможно, скопируйте файл индекса журнала пересылки существующей реплики на новую реплику и установите системную переменную relay_log_index на новой реплике в соответствии с тем, что использовалось на существующей реплике. Если этот параметр не был явно задан на существующей реплике, используйте existing_replica_hostname-relay-bin.index. В качестве альтернативы, если вы уже пытались запустить новую реплику после выполнения оставшихся шагов в этом разделе и столкнулись с ошибками, подобными описанным ранее, выполните следующие шаги:
1. Если вы еще не сделали этого, выполните оператор STOP REPLICA на новой реплике.
  
  Если вы уже снова запустили существующую реплику, выполните также STOP REPLICA на существующей реплике.
2. Скопируйте содержимое файла индекса журнала пересылки существующей реплики в файл индекса журнала пересылки новой реплики, убедившись, что вы перезаписываете любое уже имеющееся содержимое в файле.
3. Продолжите выполнение оставшихся шагов в этом разделе.
После завершения копирования перезапустите существующую реплику.
На новой реплике измените конфигурацию и присвойте новой реплике уникальный идентификатор сервера (используя системную переменную server_id), который не используется источником или какой-либо из существующих реплик.
Запустите новый сервер реплики, убедившись, что репликация еще не началась, задав параметр --skip-replica-start. Используйте таблицы репликации Performance Schema или выполните оператор SHOW REPLICA STATUS, чтобы подтвердить, что у новой реплики установлены правильные параметры по сравнению с существующей репликой. Также отобразите идентификатор сервера и UUID сервера и проверьте, что эти значения корректны и уникальны для новой реплики.
Запустите потоки репликации, выполнив оператор START REPLICA. Теперь новая реплика использует информацию из своего репозитория метаданных подключения для запуска процесса репликации.