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

Если неисправная транзакция сгенерировала ошибку в потоке обработки, её GTID можно получить непосредственно из поля APPLYING_TRANSACTION в таблице Performance Schema replication_applier_status_by_worker. Чтобы увидеть, что представляет собой транзакция, выполните SHOW RELAYLOG EVENTS на реплике или SHOW BINLOG EVENTS на источнике и найдите в выводе транзакцию, предваряемую этим GTID.

После оценки неисправной транзакции на наличие других необходимых действий (например, соображений безопасности), для пропуска ее выполните на реплике коммит пустой транзакции с тем же GTID, что и у неисправной. Например:

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

Наличие этой пустой транзакции на реплике означает, что при выполнении оператора START SLAVE для перезапуска репликации, реплика использует функцию автоматического пропуска, чтобы пропустить неисправную транзакцию, потому что видит, что транзакция с этим GTID уже применена. Если реплика является репликой с несколькими источниками, вам не нужно указывать имя канала при выполнении коммита пустой транзакции, но вам нужно указать имя канала при выполнении START SLAVE.

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

FLUSH LOGS;
PURGE BINARY LOGS TO 'binlog.000146';

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

Для пропуска некорректных транзакций, когда GTIDs не используются или находятся в процессе внедрения (gtid_mode имеет значение OFF, OFF_PERMISSIVE или ON_PERMISSIVE), можно пропустить определённое количество событий, выполнив оператор SET GLOBAL sql_slave_skip_counter. Также можно пропустить событие или несколько событий, выполнив оператор CHANGE MASTER TO для продвижения позиции двоичного лога источника вперёд.

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

Одна транзакция может содержать изменения в обеих типах таблиц — транзакционных и нетранзакционных.

Если вы используете оператор SET GLOBAL sql_slave_skip_counter для пропуска событий, и полученная позиция находится в середине группы событий, реплика продолжает пропускать события до достижения конца группы. Затем выполнение начинается с следующей группы событий. Оператор CHANGE MASTER TO не имеет этой функции, поэтому необходимо тщательно определить правильное место для возобновления репликации в начале группы событий. Однако использование CHANGE MASTER TO означает, что вам не нужно считать события, которые необходимо пропустить, как это делается с SET GLOBAL sql_slave_skip_counter, а вместо этого можно просто указать место для возобновления.

SET GLOBAL sql_slave_skip_counter = N

CHANGE MASTER TO MASTER_LOG_FILE='source_log_name', MASTER_LOG_POS=source_log_pos;

CHANGE MASTER TO MASTER_AUTO_POSITION=0, MASTER_LOG_FILE='binlog.000145', MASTER_LOG_POS=235;
CHANGE MASTER TO MASTER_AUTO_POSITION=1;