предисловие
Мы знаем, как выполняется оператор select. Если это оператор обновления, шаги выполнения и операторы запроса фактически одинаковы.Перед выполнением оператора необходимо подключиться к базе данных, что является работой коннектора. Если кеш набора результатов этого SQL существует в кеше запросов, его можно напрямую извлечь и вернуть клиенту.Как упоминалось ранее, при обновлении таблицы кеш запросов, связанный с этой таблицей, будет недействительным, поэтому кеш запросов не рекомендуется.В версии MySQL 8.0 Удалил кеш запросов. Далее анализатор, оптимизатор и исполнитель выполняют свою работу, запрашивают набор результатов и возвращают его клиенту.
Но разница между update и select заключается в том, что update также включает в себя два важных файла журнала, а именно журнал повторов и binlog.
redo log
Думая наоборот, что было бы не так, если бы этих двух журналов не существовало?
Операция обновления фактически делится на два шага: сначала запрашиваются соответствующие записи строк, а затем выполняется операция обновления в соответствии с условиями. Если журнала повторов нет, MySQL будет обновлять файл на диске для каждой операции обновления. Чтобы обновить файл на диске, вам нужно сначала найти соответствующую запись строки на диске, а затем обновить ее. Каждый оператор обновления должен работать с файлом на диске. , O стоимость, стоимость поиска высока. Чтобы решить эту проблему, разработчик движка InnoDB придумал способ сначала записать запись в журнал повторов и обновить память, в это время обновление завершается, и работа с памятью происходит намного быстрее, чем работа диск. В то же время InnoDB обновит записи в журнале повторов до файла на диске, когда это необходимо. Это обновление обычно выполняется, когда система простаивает.
Каждая операция обновления должна быть записана в журнал повторов Что делать, если журнал повторов заполнен, а места недостаточно?
Файл журнала повторов InnoDB имеет фиксированный размер.Например, вы можете настроить группу из 4 файлов, размер каждого файла составляет 1 ГБ, тогда в журнал повторов можно записать операции 4 ГБ, и InnoDB начнет запись с первого файла до тех пор, пока четвертый файл.Когда каждый файл заполнен, он возвращается к началу первого файла для записи в цикле, как показано на рисунке ниже.
[Картинка из интернета]
write pos — позиция текущей записи, перемещение назад при записи и возврат к началу файла 0 после записи в конец файла 3. Контрольная точка - это текущая позиция, которую нужно стереть, и она также перемещается назад и по кругу.Перед стиранием записи запись должна быть обновлена до файла данных.
Между записью pos и контрольной точкой находится пустая часть журнала повторов, которую можно использовать для записи новых операций. Если запись pos догоняет контрольную точку, это означает, что журнал повторов заполнен.В это время нельзя выполнить новое обновление.Необходимо остановить и стереть некоторые записи и продвинуть контрольную точку.
С помощью журнала повторов InnoDB может гарантировать, что даже в случае аварийного перезапуска базы данных ранее отправленные записи не будут потеряны.Эта возможность называется отказоустойчивой.
binlog
Только что упомянутый журнал повторов — это лог-файл уровня механизма выполнения.Все мы знаем, что MySQL в целом делится на уровень сервера и уровень движка, а binlog — это лог-файл уровня сервера, то есть все выполнение двигатели имеют бинлог
Так почему же у InnoDB есть файл журнала, а у MySQL есть файл журнала?
Поскольку в предыдущей версии MySQL не было механизма InnoDB, механизм MyISAM использовался до MySQL 5.5, но MyISAM не имеет возможности защиты от сбоев, а binlog можно использовать только для архивирования. Позже InnoDB был представлен как плагин для движка MySQL. Поскольку возможность защиты от сбоев не может быть достигнута только с помощью binlog, InnoDB использует для этого другую систему журналов — журнал повторов.
процесс операции обновления
update T set c=c+1 where ID=2;
1. Исполнитель сначала запрашивает через движок строку данных с идентификатором = 2. Идентификатор является первичным ключом. Он напрямую проходит по дереву индекса первичного ключа и напрямую вставляет строку данных. Если страница данных, где строка данных resides находится в памяти, он напрямую возвращает результат выполнению, в противном случае ему необходимо прочитать с диска в память, а затем вернуться.
2. Исполнитель получает данные строки, предоставленные движком, добавляет 1 к этому значению, получает новую строку данных, а затем вызывает интерфейс движка для записи этой строки данных.
3. Движок обновляет эту строку данных в память и одновременно записывает ее в журнал повторов.В это время журнал повторов находится в состоянии perpare.В это время исполнитель уведомляется о том, что обновление выполнено завершена, и транзакция может быть отправлена в любое время.
4. Исполнитель генерирует бинлог этой операции и записывает бинлог на диск
5. Исполнитель вызывает интерфейс транзакции фиксации механизма, механизм изменяет только что записанный журнал повторов в состояние фиксации, и обновление завершается.
На следующем рисунке показан поток выполнения оператора обновления.Темный цвет представляет выполнение в исполнителе MySQL, а светлый цвет представляет внутреннее выполнение InnoDB.
[Картинка из интернета]
двухэтапная фиксация
Запись в журнал повторов делится на два этапа: подготовка и фиксация, то есть «двухэтапная фиксация».
Причина двухэтапной фиксации состоит в том, чтобы поддерживать согласованность файлов журнала повторов и binlog. Давайте снова проиллюстрируем от противного, что могло бы пойти не так, если бы не было двухфазных коммитов:
- Сначала запишите журнал повторов, а затем бинлог. Предположим, что журнал повторов записывается, но бинлог не был записан, и процесс MySQL перезапускается ненормально. После записи журнала повторов, даже в случае сбоя системы, данные быть восстановлены Все восстановленные данные верны. Однако бинлог не завершен, и операция этого оператора не записана в бинлоге в это время. Поэтому, когда журнал будет резервироваться позже, в бинлоге нет этой записи операции. Если бинлог используется для восстановления временная библиотека, оператор записывает. Если данные потеряны, временная библиотека потеряет работу этого оператора, и восстановленные данные будут отличаться от значения исходной библиотеки.
- Сначала запишите двоичный журнал, затем запишите журнал повторов.Если система выходит из строя после записи бинлога, поскольку журнал повторов не был записан, транзакция недействительна после сбоя, поэтому данные в файле данных на диске не имеют операция этого оператора, но бинлог был записан в бинлог, поэтому при использовании этого бинлога для восстановления данных в будущем будет дополнительная операция транзакции, которая не согласуется с данными в исходной базе данных.
Если нет «двухэтапной фиксации», операции, записанные журналом повторов и binlog, будут несогласованными, а состояние базы данных может не соответствовать данным базы данных, восстановленным ее журналом.
Таким образом, процесс, который может гарантировать согласованность записей операций журнала повторов и двоичного журнала, состоит в том, чтобы сначала обновить операцию в памяти, затем записать в журнал повторов, пометить его как состояние подготовки в это время, а затем записать в binlog, затем отправьте транзакцию и запишите в журнал повторов статус «Отметить как фиксацию».
журнал повторов и бинлог
- Журнал повторов уникален для механизма InnoDB; бинарный журнал реализован на уровне сервера MySQL.
- Журнал повторов — это физический журнал, в котором записывается, «какие изменения были сделаны на странице данных», а бинлог — это логический журнал, в котором записывается исходная логика оператора. Например
update T set c=c+1 where ID=2;Этот SQL, записанный в журнале повторов:xx页号，xx偏移量的数据修改为xxx；В бинлоге записано:id = 2 这一行的 c 字段 +1 - Журнал повторов пишется циклически, и фиксированное место будет израсходовано, бинлог можно записать дополнительно, при заполнении файла он переключится на следующий файл для записи, а не перезапишет предыдущую запись.
- Время записи содержимого разное: журнал повторов записывает операторы DML и DDL после инициации транзакции, а binlog записывает операторы DML и DDL после завершения фиксации.
- Функции различаются, журнал повторов используется для восстановления данных после нештатного простоя или сбоя носителя, бинлог используется для восстановления данных, и устанавливается репликация master-slave.
undo log
Журнал отмен и журнал повторов также являются файлами журналов уровня механизма. Журнал отмен обеспечивает откат и управление версиями нескольких строк (MVCC). При изменении базы данных записывается не только журнал повторов, но и журнал отмен. причина приводит к сбою выполнения транзакции и откату, вы можете использовать журнал отмены для отката.
Хотя и журнал отмены, и журнал повтора уникальны для InnoDB, журнал отмены записывает логические журналы, а журнал повтора записывает физические журналы. При изменении записи будут созданы не только записи повторного выполнения, но и записи отмены (вставка, обновление, удаление).Журнал отмены используется для хранения значения до изменения данных, напримерupdate T set c=c+1 where ID=2;В этом SQL в журнал отмены записывается значение c перед + 1. Если обновление является ненормальным и его необходимо отменить, вы можете использовать журнал отмены для отката, чтобы обеспечить согласованность транзакций.
Многоверсионный контроль параллелизма (MVCC) также использует журнал отмен. Когда прочитанная строка заблокирована другими транзакциями, она может получить предыдущие данные строки из журнала отмен, тем самым предоставляя информацию о версии строки. последовательное чтение.
Запись отмены записывается в системное табличное пространство (ibdata1) по умолчанию, но, начиная с MySQL 5.6, можно использовать отдельное табличное пространство отмены. Не беспокойтесь, что отмена сделает файл ibdata1 больше.
Журнал отмен записывается сегментами, и каждая операция отмены при записи занимает сегмент журнала отмен.
Сегмент отката называется сегментом отката.В каждом сегменте отката 1024 сегмента журнала отката.В предыдущих версиях поддерживался только один сегмент отката, то есть можно было записать только 1024 сегмента журнала отката.После MySQL 5.5 он может поддерживать 128 сегментов отката, то есть поддерживается 128*1024 операций отмены, также можно использовать переменныеinnodb_undo_logsКоличество настраиваемых сегментов отката, по умолчанию 128.
Суммировать
Журнал повторов используется для обеспечения безопасности при сбоях, бинлог используется для обеспечения возможности восстановления состояния базы данных в любой момент, а журнал отмен используется для обеспечения отката состояния данных, когда необходимо откатить транзакцию. и MVCC записывает информацию о данных каждой версии.