19.1.5.2 Provisioning a Multi-Source Replica for GTID-Based Replication — MySQL 8.4

19.1.5.2 Настройка реплики с несколькими источниками для репликации на основе GTID

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

Если вы используете репликацию на основе GTID, вам необходимо обратить внимание на утверждение SET @@GLOBAL.gtid_purged, которое mysqldump помещает в выходные данные дампа. Это утверждение передает GTID для транзакций, выполненных на источнике, на реплику, и реплике требуется эта информация. Однако для любого случая, более сложного, чем настройка новой пустой реплики из одного источника, вам необходимо проверить, какое влияние оказывает утверждение в используемой версии MySQL на реплике, и обработать утверждение соответственно. Следующие рекомендации обобщают подходящие действия, но для получения более подробной информации см. документацию mysqldump.

SET @@GLOBAL.gtid_purged добавляет набор GTID из файла дампа к существующему набору gtid_purged на реплике. Таким образом, утверждение потенциально может остаться в выходных данных дампа при повторном воспроизведении файлов дампа на реплике, и файлы дампа могут быть повторно воспроизведены в разное время. Однако важно отметить, что значение, включаемое mysqldump для SET @@GLOBAL.gtid_purged утверждения, включает GTID всех транзакций в наборе gtid_executed на источнике, даже тех, которые изменили подавленные части базы данных или другие базы данных на сервере, которые не были включены в частичный дамп. Если на реплике повторно воспроизводится второй или последующий файл дампа, содержащий любые из тех же GTID (например, другой частичный дамп с того же источника или дамп из другого источника, имеющий перекрывающиеся транзакции), любое SET @@GLOBAL.gtid_purged утверждение во втором файле дампа завершается неудачно и поэтому должно быть удалено из выходных данных дампа.

В качестве альтернативы удалению SET @@GLOBAL.gtid_purged утверждения вы можете вызвать mysqldump с --set-gtid-purged=COMMENTED, чтобы включить утверждение, заключенное в SQL-комментарии, чтобы оно не выполнялось при загрузке файла дампа. Если вы настраиваете реплику с помощью двух частичных дампов с одного источника, и набор GTID во втором дампе такой же, как и в первом (т. е. между дампами на источнике не было выполнено новых транзакций), вы можете установить --set-gtid-purged=OFF вместо этого, когда экспортируете второй файл дампа, чтобы опустить утверждение.

В примере настройки далее мы предполагаем, что SET @@GLOBAL.gtid_purged утверждение не может оставаться в выходных данных дампа и должно быть удалено из файлов и обработано вручную. Мы также предполагаем, что на реплике нет желаемых транзакций с GTID до начала настройки.

Чтобы создать файлы дампов для базы данных под названием db1 на source1 и базы данных под названием db2 на source2, запустите mysqldump для source1 следующим образом:
```
mysqldump -u<user> -p<password> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db1 > dumpM1.sql 
```
Затем запустите mysqldump для source2 следующим образом:
```
mysqldump -u<user> -p<password> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db2 > dumpM2.sql 
```
Запишите значение gtid_purged, которое mysqldump добавил в каждый из файлов дампов. Вы можете извлечь значение следующим образом:
```
cat dumpM1.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\''
cat dumpM2.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\''
```
Результат в каждом случае должен быть набором GTID, например:
```
source1:   2174B383-5441-11E8-B90A-C80AA9429562:1-1029
source2:   224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695
```
Удалите строку из каждого файла дампа, содержащую SET @@GLOBAL.gtid_purged утверждение. Например:
```
sed '/GTID_PURGED/d' dumpM1.sql > dumpM1_nopurge.sql
sed '/GTID_PURGED/d' dumpM2.sql > dumpM2_nopurge.sql 
```
Используйте клиент mysql для импорта каждого отредактированного файла дампа в реплику. Например:
```
mysql -u<user> -p<password> < dumpM1_nopurge.sql
mysql -u<user> -p<password> < dumpM2_nopurge.sql 
```
На реплике выполните RESET BINARY LOGS AND GTIDS, чтобы очистить историю выполнения GTID (при условии, как объяснено выше, что все файлы дампов были импортированы и что на реплике нет желаемых транзакций с GTID). Затем выполните SET @@GLOBAL.gtid_purged утверждение, чтобы установить значение gtid_purged в объединение всех наборов GTID из всех файлов дампов, как вы записали в шаге 2. Например:
```
mysql> RESET BINARY LOGS AND GTIDS;
mysql> SET @@GLOBAL.gtid_purged = "2174B383-5441-11E8-B90A-C80AA9429562:1-1029, 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695";
```
Если между наборами GTID в файлах дампов существуют или могут существовать перекрывающиеся транзакции, вы можете использовать хранимые функции, описанные в разделе 19.1.3.8 «Примеры хранимых функций для управления GTID», чтобы проверить это заранее и рассчитать объединение всех наборов GTID.