Это 30-й день моего участия в августовском испытании обновлений. Узнайте подробности события:Испытание августовского обновления
Оператор обновления SQL
Весь процесс обновления SQL в основном такой же, как и в операторе запроса. Просто добавил две части журнала повторов [журнал повторов] и binlog [журнал архивов] на этапе исполнителя.
redo log
Зависит от движка InnoDB, используется для обеспечения возможности crash_safe. Используется технология WAL [write-Ahead Logging], то есть сначала пишется лог, а потом уже диск
Сходства и различия между журналом повторов и бинлогом заключаются в следующем:
| redo log | binlog |
|---|---|
| Специально для движка InnoDB | Серверный уровень, каждый механизм хранения может использовать |
| Физический журнал — что делает эта страница данных | Логический лог - исходная логика оператора |
| Циклическая запись, фиксированное пространство используется | Добавить запись, данные не будут перезаписаны |
конкретный процесс
двухэтапная фиксация
Причина использования двухэтапной фиксации состоит в том, чтобы обеспечить логическую согласованность двух журналов и избежать несогласованности данных, вызванной аварийным перезапуском MySQL.
Если не двухфазный коммит
- После записи журнала повторов при записи бинлога происходит аварийный перезапуск. На данный момент журнал повторов уже содержит обновленное состояние, а журнал bin по-прежнему имеет исходное значение. Благодаря функции журнала повторного выполнения сбоя_безопасности данные можно восстановить. Но как только вы воспользуетесь binlog для восстановления временной библиотеки, вы обнаружите, что значение отличается от исходной библиотеки.
- После записи бинлога при записи журнала повторов происходит аварийный перезапуск. В настоящее время журнал bin является исходным значением и остается исходным значением после восстановления после сбоя. Однако в binlog есть новое значение, и после восстановления с помощью binlog появится еще одна транзакция, которая отличается от исходного значения базы данных.
Если двухэтапный коммит
После записи журнала повторов бинарный журнал аварийно перезапускается при записи. В это время журнал повторов находится в состоянии подготовки, а бинлог снова дает сбой, поэтому сама транзакция будет отброшена к исходному значению. Библиотека, восстановленная с помощью binlog, также является исходным значением, поэтому логика непротиворечива.
redo_log — для параметра innodb_flush_log_at_trx_commit установлено значение 1 — это означает, что журнал повторов транзакции сохраняется напрямую на диск
binlog — для параметра sync_binlog установлено значение 1 — это означает, что binlog каждой транзакции сохраняется на диск.
Оператор обновления SQL
Весь процесс обновления SQL в основном такой же, как и в операторе запроса. Просто добавил две части журнала повторов [журнал повторов] и binlog [журнал архивов] на этапе исполнителя.
redo log
Зависит от движка InnoDB, используется для обеспечения возможности crash_safe. Используется технология WAL [write-Ahead Logging], то есть сначала пишется лог, а потом уже диск
Сходства и различия между журналом повторов и бинлогом заключаются в следующем:
| redo log | binlog |
|---|---|
| Специально для движка InnoDB | Серверный уровень, каждый механизм хранения может использовать |
| Физический журнал — что делает эта страница данных | Логический лог - исходная логика оператора |
| Циклическая запись, исчерпан фиксированный объем памяти | Добавить запись, данные не будут перезаписаны |
| ### конкретный процесс |
двухэтапная фиксация
Причина использования двухэтапной фиксации состоит в том, чтобы обеспечить логическую согласованность двух журналов и избежать несогласованности данных, вызванной аварийным перезапуском MySQL.
Если не двухфазный коммит
- После записи журнала повторов при записи бинлога происходит аварийный перезапуск. На данный момент журнал повторов уже содержит обновленное состояние, а журнал bin по-прежнему имеет исходное значение. Благодаря функции журнала повторного выполнения сбоя_безопасности данные можно восстановить. Но как только вы воспользуетесь binlog для восстановления временной библиотеки, вы обнаружите, что значение отличается от исходной библиотеки.
- После записи бинлога при записи журнала повторов происходит аварийный перезапуск. В настоящее время журнал bin является исходным значением и остается исходным значением после восстановления после сбоя. Однако в binlog есть новое значение, и после восстановления с помощью binlog появится еще одна транзакция, которая отличается от исходного значения базы данных.
Если двухэтапный коммит
После записи журнала повторов бинарный журнал аварийно перезапускается при записи. В это время журнал повторов находится в состоянии подготовки, а бинлог снова дает сбой, поэтому сама транзакция будет отброшена к исходному значению. Библиотека, восстановленная с помощью binlog, также является исходным значением, поэтому логика непротиворечива.