Существует ряд техник использования репликации MySQL с идентификаторами глобальных транзакций (GTID) для создания новой реплики, которая затем может использоваться для масштабирования, а при необходимости — для повышения статуса до источника для аварийного переключения. В этом разделе описаны следующие техники:

Идентификаторы глобальных транзакций были добавлены в MySQL Replication для упрощения управления потоком данных репликации и, в частности, операций аварийного переключения. Каждый идентификатор однозначно идентифицирует набор событий двоичного журнала, которые вместе составляют транзакцию. GTID играют ключевую роль в применении изменений в базе данных: сервер автоматически пропускает любые транзакции, имеющие идентификатор, который сервер распознаёт как уже обработанный. Это поведение имеет важное значение для автоматического позиционирования репликации и корректного аварийного переключения.

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

Простая репликация. Самый простой способ воспроизвести все идентификаторы и транзакции на новом сервере — сделать новый сервер репликой источника, у которого есть весь исполняемый журнал, и включить идентификаторы глобальных транзакций на обоих серверах. Подробную информацию см. в разделе 16.1.3.4 «Настройка репликации с использованием GTID».

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

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

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

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

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

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

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

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

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';

BEGIN;
COMMIT;

SET GTID_NEXT='AUTOMATIC';

После того как все идентификаторы транзакций были восстановлены таким образом с помощью пустых транзакций, необходимо очистить и удалить двоичные журналы реплики, как показано здесь, где N — это ненулевой суффикс текущего имени файла двоичного журнала:

FLUSH LOGS;
PURGE BINARY LOGS TO 'source-bin.00000N';

Вам следует сделать это, чтобы предотвратить затопление потока репликации этим сервером ложными транзакциями в случае его последующего повышения до источника. (Утверждение FLUSH LOGS принуждает к созданию нового файла двоичного журнала; PURGE BINARY LOGS очищает пустые транзакции, но сохраняет их идентификаторы.)

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

Исключение транзакций с gtid_purged. Переменная глобального источника gtid_purged содержит множество всех транзакций, которые были удалены из двоичного журнала источника. Как и в методе, рассмотренном ранее (см. Вставку пустых транзакций), вы можете записать значение gtid_executed на сервере, с которого был сделан снимок (вместо копирования двоичных журналов на новый сервер). В отличие от предыдущего метода, нет необходимости в подтверждении пустых транзакций (или в выполнении PURGE BINARY LOGS); вместо этого вы можете установить gtid_purged на реплике напрямую, основываясь на значении gtid_executed на сервере, с которого был сделан резервный или моментальный снимок.

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

Восстановление реплик в режиме GTID. При восстановлении реплики в настройке репликации на основе GTID, столкнувшейся с ошибкой, вставка пустой транзакции может не решить проблему, поскольку событие не имеет GTID.

Используйте mysqlbinlog для поиска следующей транзакции, которая, вероятно, является первой транзакцией в следующем файле журнала после события. Скопируйте все до COMMIT для этой транзакции, убедившись, что вы включили SET @@SESSION.GTID_NEXT. Даже если вы не используете репликацию на основе строк, вы всё равно можете выполнить события двоичного журнала строк в клиенте командной строки.

Остановите реплику и выполните скопированную вами транзакцию. Выход mysqlbinlog устанавливает разделитель на /*!*/;, поэтому установите его обратно:

mysql> DELIMITER ;

Автоматически перезапустите репликацию с правильной позиции:

mysql> SET GTID_NEXT=automatic;
mysql> RESET SLAVE;
mysql> START SLAVE;