16.4.1.30. Репликация и Транзакции

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

С MySQL 5.5.2 сервер использует эти правила для двоичного журналирования:

Если начальные операторы в транзакции являются нетранзакционными, они сразу пишутся двоичному журналу. Остающиеся операторы в транзакции кэшируются и не пишутся двоичному журналу, пока транзакция не фиксируется. (Если транзакция откатывается, кэшируемые операторы пишутся двоичному журналу, только если они производят нетранзакционные изменения, которые не могут откатываться. Иначе, они отбрасываются.)
Для основанного на операторе журналирования на журналирование нетранзакционных операторов влияют binlog_direct_non_transactional_updates системная переменная. Когда эта переменная OFF (значение по умолчанию), журналирование было как только описано. Когда эта переменная ON, журналирование сразу происходит для нетранзакционных операторов, происходящих где угодно в транзакции (не только начальные нетранзакционные операторы). Другие операторы сохраняются в кэше транзакции и регистрируются, когда транзакция фиксирует. binlog_direct_non_transactional_updates не имеет никакого эффекта для формата строки или двоичного журналирования смешанного формата.

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

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

Обновления или чтения транзакционная таблица
Читает нетранзакционную таблицу, и уровень изоляции транзакции является меньше чем REPEATABLE_READ

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

Обновления любая таблица и чтения из любой временной таблицы
Обновляет нетранзакционную таблицу, и binlog_direct_non_trans_update ВЫКЛЮЧЕН

Для получения дополнительной информации см. Раздел 16.1.2.3, "Определение Безопасных и Опасных Операторов в Двоичном Журналировании".

Отметить

Смешанный оператор не связан со смешанным двоичным форматом журналирования.

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

Используя различные механизмы хранения на ведущем устройстве и ведомом устройстве. Возможно тиражировать транзакционные таблицы в ведущее устройство, использующее нетранзакционные таблицы на ведомом устройстве. Например, можно тиражироваться InnoDB основная таблица как a MyISAM ведомая таблица. Однако, если Вы делаете это, есть проблемы, если ведомое устройство останавливается в середине a BEGIN ... COMMIT блокируйте, потому что ведомое устройство перезапускает в начале BEGIN блок.

В MySQL 5.6 также безопасно тиражировать транзакции от MyISAM таблицы на ведущем устройстве к транзакционным таблицам — таким как таблицы, которые используют InnoDB механизм хранения — на ведомом устройстве. В таких случаях (начинающийся с MySQL 5.5.0), AUTOCOMMIT=1 заявление, сделанное на ведущем устройстве, тиражируется, таким образом осуществляя AUTOCOMMIT режим на ведомом устройстве.

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

Изменение двоичного журналирования форматирует в пределах транзакций. Начинаясь с MySQL 5.5.3, binlog_format системная переменная только для чтения, пока транзакция происходит. (Ошибка #47863)

Каждая транзакция (включая autocommit транзакции), записывается в двоичном журнале, как если бы он запускается с a BEGIN оператор, и концы с любым a COMMIT или a ROLLBACK оператор. В MySQL 5.6 эта истина даже для операторов, влияющих на таблицы, которые используют нетранзакционный механизм хранения (такой как MyISAM).