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

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

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

Простая репликация. Самый простой способ воспроизвести все идентификаторы и транзакции на новом сервере — сделать новый сервер репликой источника, который имеет всю историю выполнения, и включить глобальные идентификаторы транзакций на обоих серверах. Подробнее см. Раздел 19.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 REPLICA;
mysql> START REPLICA;