Я использую mysql-binlog-коннектор чтобы прослушать любое событие binlog, а затем выполнить репликацию на подчиненной БД. Моя проблема в том, что binlog регистрирует событие сразу после выполнения и перед фиксацией, поэтому, если есть какой-либо откат, событие по-прежнему выбирается из записи binlog и реплицируется на ведомом устройстве. Есть ли способ решить эту проблему?
Из руководство по binlog Такое впечатление, что механизм работает слегка по-другому:
В незафиксированной транзакции все обновления (UPDATE, DELETE или INSERT), которые изменяют транзакционные таблицы, такие как таблицы InnoDB, являются кешируется до COMMIT заявление получено сервером. В этот момент mysqld записывает всю транзакцию в двоичный журнал перед выполнением COMMIT.
Другими словами, до тех пор, пока на самом деле не будет выполнено COMMIT, в двоичный журнал ничего из этой транзакции не будет записано вообще или, в качестве альтернативы, тот факт, что транзакция попала в двоичный журнал, означает, что ROLLBACK не был выполнен!
После выполнения COMMIT: сначала полная транзакция записывается в двоичный журнал, затем выполняется COMMIT и, наконец, только после успешного завершения COMMIT, COMMIT регистрируется в двоичном журнале.
Затем руководство продолжается с парой крайних случаев и их смягчающих мер (sync_binlog=1 & --innodb_support_xa), которые могут облегчить ваши опасения:
Начиная с MySQL 5.7.7, двоичный журнал по умолчанию синхронизируется с диском при каждой записи (
sync_binlog=1). До MySQL 5.7.7 это не (sync_binlog=0). Итак, до MySQL 5.7.7, если операционная система или машина (не только сервер MySQL) выйдет из строя, есть шанс, что последние операторы двоичного журнала будут потеряны. Чтобы предотвратить это, используйтеsync_binlogсистемная переменная для синхронизации двоичного журнала с диском после каждых N групп фиксации. См. Раздел 5.1.4, «Системные переменные сервера». Самым безопасным значением для sync_binlog является 1, но это также и самое медленное. Даже если для параметра sync_binlog установлено значение 1, все еще существует вероятность несоответствия между содержимым таблицы и содержимым двоичного журнала в случае сбоя.Например, если вы используете таблицы InnoDB и сервер MySQL обрабатывает оператор COMMIT, он последовательно записывает множество подготовленных транзакций в двоичный журнал, синхронизирует двоичный журнал и затем фиксирует эту транзакцию в InnoDB. Если сервер выходит из строя между этими двумя операциями, транзакция откатывается InnoDB при перезапуске, но все еще существует в двоичном журнале. Такая проблема решается при условии
--innodb_support_xaустановлен на1