16.1.2.6 Adding Replicas to a Replication Topology — MySQL 5.7

16.1.2.6 Добавление реплик в топологию репликации

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

Для дублирования существующей реплики:

Остановите существующую реплику и запишите информацию о состоянии реплики, особенно позиции файла бинарного журнала источника и файла журнала релейного лога. Вы можете просмотреть состояние реплики в таблицах репликации Performance Schema (Раздел 25.12.11, «Таблицы репликации Performance Schema»), или выполнив команду SHOW SLAVE STATUS следующим образом:
```
mysql> STOP SLAVE;
mysql> SHOW SLAVE STATUS\G
```
Остановите существующую реплику:
```
$> mysqladmin shutdown
```
Скопируйте каталог данных из существующей реплики в новую реплику, включая файлы журналов и файлы релейного лога. Вы можете сделать это, создав архив с помощью tar или WinZip, или выполнив прямую копию с помощью инструмента, такого как cp или rsync.
Важно
- Перед копированием убедитесь, что все файлы, относящиеся к существующей реплике, фактически хранятся в каталоге данных. Например, системное пространство таблиц InnoDB, пространство таблиц отмены и журнал переопределения могут храниться в альтернативном расположении. InnoDB файлы пространства таблиц и пространства таблиц на основе файлов на запись могут быть созданы в других каталогах. Файлы бинарных журналов и журналов релейных логов реплики могут находиться в своих собственных каталогах за пределами каталога данных. Проверьте системные переменные, установленные для существующей реплики, и найдите все альтернативные пути, которые были указаны. Если вы найдете какие-либо, скопируйте и эти каталоги.
- Во время копирования, если файлы использовались для репозиториев метаданных репликации (Раздел 16.2.4, «Репозитории релейных логов и метаданных репликации»), что является значением по умолчанию в MySQL 5.7, убедитесь, что вы также копируете эти файлы из существующей реплики в новую реплику. Если для репозиториев используются таблицы, то таблицы находятся в каталоге данных.
- После копирования удалите файл 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 slave 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. Более подробная информация об этих переменных приведена в Разделе 16.1.6, «Параметры и переменные репликации и бинарного протоколирования».

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