Spec-Zone .ru
спецификации, руководства, описания, API
|
Смешивание транзакционных и нетранзакционных операторов в пределах той же самой транзакции. Вообще, следует избежать транзакций, которые обновляют и транзакционные и нетранзакционные таблицы в среде репликации. Следует также избегать использования любого оператора что доступы оба транзакционные (или временный) и нетранзакционные таблицы и записи любому из них.
С MySQL 5.5.2 сервер использует эти правила для двоичного журналирования:
Если начальные операторы в транзакции являются нетранзакционными, они сразу пишутся двоичному журналу. Остающиеся операторы в транзакции кэшируются и не пишутся двоичному журналу, пока транзакция не фиксируется. (Если транзакция откатывается, кэшируемые операторы пишутся двоичному журналу, только если они производят нетранзакционные изменения, которые не могут откатываться. Иначе, они отбрасываются.)
Для основанного на операторе журналирования на журналирование нетранзакционных
операторов влияют binlog_direct_non_transactional_updates
системная переменная. Когда
эта переменная OFF
(значение по умолчанию), журналирование было как только
описано. Когда эта переменная ON
, журналирование сразу происходит для
нетранзакционных операторов, происходящих где угодно в транзакции (не только начальные нетранзакционные
операторы). Другие операторы сохраняются в кэше транзакции и регистрируются, когда транзакция фиксирует.
binlog_direct_non_transactional_updates
не имеет никакого эффекта для
формата строки или двоичного журналирования смешанного формата.
Транзакционные, нетранзакционные, и смешанные операторы. Чтобы применить те правила, сервер считает оператор нетранзакционным, если он изменяет только нетранзакционные таблицы, и транзакционный, если он изменяет только транзакционные таблицы. В MySQL 5.7, оператор, что ссылки и нетранзакционные и транзакционные таблицы и обновления любая из включенных таблиц, считается "смешанным" оператором. (В предыдущем ряду выпуска MySQL оператор, который изменил и нетранзакционные и транзакционные таблицы, считали смешанным.) Смешанные операторы, как транзакционные операторы, кэшируются и регистрируются, когда транзакция фиксирует.
Смешанный оператор, который обновляет транзакционную таблицу, считают опасным, если оператор также выполняет любое из следующих действий:
Обновления или чтения транзакционная таблица
Читает нетранзакционную таблицу, и уровень изоляции транзакции является меньше чем REPEATABLE_READ
Смешанный оператор после обновления транзакционной таблицы в пределах транзакции считают опасным, если это выполняет любое из следующих действий:
Обновления любая таблица и чтения из любой временной таблицы
Обновляет нетранзакционную таблицу, и binlog_direct_non_trans_update ВЫКЛЮЧЕН
Для получения дополнительной информации см. Раздел 16.1.2.3, "Определение Безопасных и Опасных Операторов в Двоичном Журналировании".
Смешанный оператор не связан со смешанным двоичным форматом журналирования.
В ситуациях, где обновления соединения транзакций к транзакционным и нетранзакционным таблицам, порядок
операторов в двоичном журнале корректен, и все необходимые операторы, пишутся двоичному журналу даже в случае a
ROLLBACK
.
Однако, когда второе соединение обновляет нетранзакционную таблицу прежде, чем первая транзакция соединения
будет полна, операторы могут быть зарегистрированы не в порядке, потому что второе обновление соединения сразу
пишется после того, как это выполняется, независимо от состояния транзакции, выполняемой первым соединением.
Используя различные механизмы хранения на ведущем устройстве и ведомом устройстве. Возможно тиражировать
транзакционные таблицы в ведущее устройство, использующее нетранзакционные таблицы на ведомом устройстве.
Например, можно тиражироваться InnoDB
основная таблица как a MyISAM
ведомая таблица. Однако, если Вы делаете это, есть проблемы, если ведомое устройство останавливается в середине
a BEGIN
...
COMMIT
блокируйте, потому что ведомое устройство перезапускает в начале BEGIN
блок.
В MySQL 5.7 также безопасно тиражировать транзакции от 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.7 эта истина даже для операторов, влияющих на
таблицы, которые используют нетранзакционный механизм хранения (такой как MyISAM
).