Принципы реализации атомарности, согласованности и долговечности транзакций

MySQL
Принципы реализации атомарности, согласованности и долговечности транзакций

предисловие

Все мы знаем, что транзакции имеют четыре характеристики:

  • атомарность

    Атомарность означает, что вся транзакция базы данных является неделимой единицей работы. Вся транзакция считается успешной только в том случае, если все операции с базой данных в транзакции выполнены успешно. Если какой-либо оператор SQL в транзакции не удается выполнить, оператор SQL, который был успешно выполнен, также должен быть отменен, а состояние базы данных должно вернуться к состоянию до выполнения транзакции.

  • последовательность

    Согласованность — это когда транзакция переводит базу данных из одного состояния в следующее согласованное состояние. Ограничения целостности базы данных не нарушаются до начала транзакции и после ее завершения.

  • изоляция

    Эффекты транзакции не видны другим транзакциям до тех пор, пока транзакция не будет зафиксирована — это достигается с помощью блокировок.

  • Долговечность

    Как только транзакция совершена, ее результаты являются постоянными. Даже в случае сбоя, например простоя, база данных может восстановить данные.

Для реализации изоляции вы можете обратиться к этой моей статье:Краткий анализ блокировок и транзакций InnoDB

В этой статье основное внимание уделяется тому, как реализованы остальные три функции:Завершено повтором и отменой базы данных. Если в этой статье не указаны специальные инструкции, по умолчанию используется механизм хранения InnoDB mysql.

выполнить

Базовые знания

  1. redo logИзменения физического состояния регистрируются для каждой страницы (Page)
  2. undo logВ отличие от журнала повторов, который записывает физические журналы, это логический журнал. Можно считать, что при удалении записи в журнал отмен будет записана соответствующая запись вставки, и наоборот, при обновлении записи будет записана соответствующая противоположная запись обновления.
  3. LSNВызывается логическим порядковым номером лога (log sequence number), в механизме хранения innodb lsn занимает 8 байт. Значение LSN будет постепенно увеличиваться по мере записи журнала. Операции обновления внутри транзакции генерируют новый номер LSN. LSN существует не только в журнале повторов, но и на странице данных.
  4. checkpointКонтрольные точки, которые указывают, когда грязные страницы записываются на диск.

Общий процесс

Будь то журнал или данные, теперь они модифицируются в буфере, а затем синхронизируются с диском.

  1. После запуска транзакции, если измененные данные не находятся в буфере журнала, они будут считаны с диска в буфер журнала.

  2. Запишите исходные данные в журнал отмены перед изменением данных в памяти.

  3. Измените страницу данных в памяти, запишите LSN в страницу данных памяти, назовем ее data_in_buffer_lsn

  4. При изменении страницы данных (почти одновременно) запишите журнал повторов в журнал повторов в буфере и запишите соответствующий номер LSN, который временно называется redo_log_in_buffer_lsn;

  5. Очистка журнала и очистка данных

    Правила очистки журнала:

    • Когда выдается действие фиксации

    • Чистить каждую секунду

    • Когда используемая память в буфере журнала больше половины

    • когда есть контрольно-пропускной пункт

    Правила сброса данных:

    • когда есть контрольно-пропускной пункт

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

    Причина, по которой метод журнала с упреждающей записью может обеспечить целостность, заключается в том, что в журнале и на страницах данных есть номера LSN, а порядок записей данных в журнале и на страницах данных можно сравнить по номеру LSN.Файл журнала — это настоящее ядро.

Пример

Источник:Подробный анализ журналов транзакций MySQL (журнал повторов и журнал отмен)

На приведенном выше рисунке горизонтальные линии сверху вниз представляют: ось времени, номер LSN, записанный на странице данных в буфере (data_in_buffer_lsn), номер LSN, записанный на странице данных на диске (data_page_on_disk_lsn), и номер LSN, записанный в журнале повторов в буфере ( redo_log_in_buffer_lsn ), номер LSN, записанный в файле журнала повторов на диске (redo_log_on_disk_lsn), и номер LSN, записанный контрольной точкой (checkpoint_lsn).

Если предположить, что в начале (12:0:00) все страницы логов и страницы данных были сброшены, а также записаны LSN контрольных точек, то в это время их LSN полностью совпадают.

Предположим, что в это время запускается транзакция и немедленно выполняется операция обновления.После завершения выполнения страница данных в буфере и журнал повторов записали обновленное значение LSN, предполагая, что оно равно 110. В это время, если вы выполните команду show engine innodb status для просмотра значения каждого номера LSN, то есть статуса позиции в ① на рисунке, результатом будет:

log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at

После выполнения еще одного оператора удаления номер LSN увеличивается до 150. Дождитесь 12:00:01, активируйте правило очистки журнала повторов (одним из которых является частота очистки журнала по умолчанию, управляемая innodb_flush_log_at_timeout, равная 1 секунде), затем LSN в файле журнала повторов на диске будет обновлен до и журнал повторов LSN входящего буфера такой же, поэтому он равен 150. В это время покажите состояние двигателя innodb, которое является позицией ② на рисунке, результатом будет:

log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at

После другого выполняется оператор UPDATE, и LSN в кеше вырастет до 300, то есть позиции на рисунке.

Предположим, что возникает контрольная точка, т. е. позиция на РИС. ④, как упоминалось ранее, инициирует страницы журнала контрольной точки и страницы данных щеточной пластины, но для завершения потребуется некоторое время, поэтому, когда страница данных щеточной пластины не завершена , проверьте LSN LSN точка или последняя контрольная точка, но на этот раз LSN на страницах данных диска и страницах логов увеличился, а именно:

log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at

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

Когда страница данных и страница журнала очищаются, то есть когда они достигают позиции ⑤, все номера LSN равны 300.

Со временем он достигает 12:00:02, что является позицией ⑥ на рисунке, и правило очистки журнала срабатывает снова, но в это время LSN журнала в буфере и LSN журнала на диске то же самое, поэтому сброс лога не выполняется.disk, то есть при показе состояния show engine innodb все lsn равны.

Затем выполняется оператор вставки, предполагая, что номер LSN в буфере вырос до 800, что является позицией ⑦ на рисунке. В настоящее время размер и положение различных LSN такие же, как и в случае ①.

Затем выполняется действие фиксации, то есть позиция ⑧. По умолчанию действие фиксации вызывает сброс журнала, но не сброс данных, поэтому результат show engine innodb status будет следующим:

log sequence number = log flushed up to > pages flushed up to = last checkpoint at

Наконец, со временем контрольная точка снова появляется в позиции ⑨ на рисунке. Но на этот раз контрольная точка не инициирует очистку журнала, поскольку LSN журнала был синхронизирован до того, как возникнет контрольная точка. Предполагая, что скорость сброса данных на этот раз чрезвычайно высока, она настолько высока, что изменение статуса не может быть зафиксировано в одно мгновение.В это время результатом show engine innodb status будет то, что различные номера LSN равны.

восстанавливаться

Стратегия восстановления mysql:

  1. При восстановлении сначала повторить все транзакции согласно redo, включая незафиксированные транзакции
  2. Затем откатите незафиксированные транзакции в соответствии с отменой.

Благодаря этой стратегии гарантируется атомарность, согласованность и надежность транзакций.

Кроме того, введен механизм чекпойнта, при восстановлении нужно восстанавливаться только из положения чекпойнта.

впечатление

  1. Много контента в Интернете может быть неточным, даже в этой статье, которую я написал, могут быть неточности, лучший способ решить эту проблему -Читать исходный код
  2. Различные технологии могут быть реализованы по-разному, но основные принципы часто одни и те же, и эти основные принципы обычно основаны наБазовые знаниянад
  3. Изучая знания, можно познать разную глубину, прочитав »Технология MySQL изнутри: механизм хранения InnoDB«Вы можете иметь общее понимание использования MySQL, но понимание не углубляется. С надписью этих двух статей понимание MySQL более глубоко. Если вам нужно идти дальше, вам действительно нужно смотреть на исходный код. Эта вещь чувствует себя дорогим. Больше времени. Таким образом, вам нужно знать, какой уровень вам нужно знать.Используйте ограниченное время, чтобы делать более рентабельные вещи, выбор важен.

материал

  1. Углубленное изучение транзакций MySQL: принцип реализации возможностей ACID
  2. Подробный анализ журналов транзакций MySQL (журнал повторов и журнал отмен)
  3. blog.CSDN.net/Второй брат Су_ис Тор…
  4. blog.CSDN.net/QQ_41151659…

наконец

Если вам нравятся мои статьи, вы можете подписаться на мой официальный аккаунт (программист Малатанг)

Обзор прошлых статей:

  1. Принципы реализации атомарности, согласованности и долговечности транзакций
  2. Как тренировать память
  3. Подробное объяснение процесса запроса CDN
  4. Мысли о карьерном росте программистов
  5. Вспомните историю разгрома службы блогов
  6. Общие советы по кэшированию
  7. Как эффективно подключиться к стороннему платежу
  8. Gin framework краткая версия
  9. Мысли о код-ревью
  10. Краткий анализ блокировок и транзакций InnoDB
  11. Рекомендация редактора уценки - опечатка
Категории