Одна из серий MySQL обновляет жизненный цикл SQL.

задняя часть база данных MySQL сервер

Я слышал, что MySQL может восстановиться до состояния любой секунды за полмесяца.

Чтобы начать с оператора обновления, если значение строки ID=2 равно +1, оператор SQL может быть записан следующим образом:

mysql> update T set c=c+1 where ID=2;

Выполнение оператора обновления также будет проходить черезпроверить предложениепроцесс:

  • соединятьбаза данных
  • Очистить задействованную таблицутайник
  • АнализаторБлагодаря лексическому и грамматическому анализу это оператор обновления, и определяется, что задействованы таблицы и поля.
  • оптимизаторрешить использовать"ID"этот индекс
  • АктуаторНайдите эту строку данных и обновите ее.
    В отличие от процесса запроса, обновление включает в себя два модуля журнала:журнал повторова такжебин лог (архив лога)

Временная запись: журнал повторов

У владельца магазина в отеле есть бухгалтерская книга и небольшая доска для ведения кредитных записей. Есть два варианта:

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

Когда бизнес процветает, а покупатели идут бесконечным потоком, эффективность первого плана действительно низка, и владелец магазина должен следовать второму плану, чтобы вести учет.
Точно так же, если MySQL должен записывать на диск для каждой операции обновления, находить соответствующую запись на диске, а затем обновлять ее, стоимость ввода-вывода и стоимость поиска этого процесса слишком высоки.
Чтобы решить эту проблему, MySQL использует что-то вроде黑板-账本режим для повышения эффективности. Этот режимWAL技术, весь процессWrite-Ahead Logging,ключевой момент:Сначала запишите журнал, затем запишите на диск, то есть сначала напишите на доске, а затем в бухгалтерской книге.

Конкретные шаги заключаются в следующем:
Когда запись необходимо обновить, innoDB сначала записывает запись в журнал повторов и обновляет память, что является завершением операции обновления. Механизм innoDB обновит запись операции на диске в соответствующее время Это действие обычно выполняется, когда система относительно простаивает.
Размер журнала повторов фиксирован и состоит из 4 файлов, каждый размером 1G. Логически 4 файла можно понимать как кольцо, писать с начала, писать до конца и снова начинать новый раунд, как показано на следующем рисунке


позиция записи — текущая позиция записи, контрольная точка — текущая позиция точки стирания, когда запись обновляется, контрольная точка перемещается назад вместе с записью файла. Незаписанные места после стирания могут записывать новые операции. Когда позиция записи совпадет с контрольной точкой, вам нужно остановить действие записи, записать содержимое журнала повторов на диск, а затем очистить контрольную точку и вернуться назад.
С помощью журнала повторов innoDB может знать каждую операцию и гарантировать, что при аварийном перезапуске базы данных предыдущие записи могут быть восстановлены в соответствии с журналом повторов."crash-safe".

Журнал архива: бин лог

Разница между журналом повторов и журналом bin:

  1. Журнал повторов принадлежит движку innoDB, бинарный журнал предоставляется сервером, и все движки могут его использовать.
  2. журнал повторов относится к физическому журналу, записи"在某个数据页做了什么修改", в журнале bin записывается логический журнал оператора"将ID=2的这一行c的值+1" [1]
  3. Файл журнала повторного выполнения используется циклически, при исчерпании места бинарный журнал записывается дополнительно и не перезаписывает предыдущую запись.

Другими словами, у сервера нет журнала повторов с другими движками, поэтому нет возможности защиты от сбоев.

Обновить конкретный процесс

Основываясь на знании двух файлов журнала, еще один подробный взгляд на процесс обновления

  1. Исполнитель сначала находит строку с ID=2 через движок с помощью поиска по дереву.Если страница данных, на которой находится запись, находится в памяти, он возвращается непосредственно исполнителю, в противном случае он сначала читает память с диска, а затем возвращается
  2. После того, как исполнитель получает данные, он добавляет единицу к значению c, а затем записывает измененные данные через интерфейс записи движка.
  3. Двигатель j обновляет новые данные в памяти, а затем записывает изменение в журнал повторов, в это время статус записи в журнале повторов устанавливается на подготовку, а исполнитель информируется о том, что обновление завершено. , и транзакцию можно отправить в любое время.
  4. Исполнитель формирует bin-лог этой операции и записывает bin-лог на диск
  5. Исполнитель вызывает интерфейс транзакции фиксации механизма, механизм устанавливает только что записанный журнал повторов в состояние фиксации, и обновление завершается.

На картинке ниже"Битва с MySQL"Блок-схема предоставлена:

Светлые цвета представляют выполнение в innoDB, темные цвета выполняются на сервере.

двухэтапная фиксация

Как видно из рисунка выше, журнал повторов отправляется в два этапа, чтобы сохранить логическую согласованность двух журналов. Что было бы без двухэтапного коммита?Посмотрим от противного:
Предположим, что строка данных с начальным ID=2, значение c равно 0, и теперь необходимо выполнить операцию c+1.

  1. Сначала запишите журнал повторов, а затем запишите журнал корзины.Если журнал повторов только что был записан, а журнал bin еще не записан, значение c было записано и изменено на 1. В это время происходит сбой службы MySQL и перезапуск. log можно использовать для восстановления базы данных.Восстановленные данные содержат значение c, равное 1. Поскольку это изменение не записывается в журнал бинов, значение c по-прежнему равно 0, когда позже создается резервная копия журнала бинов. Если вам нужно однажды восстановить резервную базу данных из журнала bin, поскольку журнал bin обновляется на один раз меньше, окончательно восстановленное значение c по-прежнему равно 0, что несовместимо со значением в исходной базе данных.
  2. Сначала запишите журнал bin, а затем запишите журнал повторов.После записи журнала bin происходит сбой, а журнал повторов ранее не записывался.После восстановления после сбоя транзакция недействительна, поэтому значение c по-прежнему равно 0, но журнал «значение c + 1" была записана в журнале bin. Следовательно, есть еще одна транзакция для данных, восстановленных журналом bin, так что значение c равно 1, что не соответствует данным в исходной базе данных.
  3. Двухэтапная фиксация Запишите журнал bin и вернитесь, чтобы отправить фиксацию(См. знания в области комментариев.) После обновления журнала повторов происходит сбой, когда журнал корзины не был записан. В это время статус журнала повторов все еще готов, транзакция не отправлена ​​иНет записи в журнале bin, поэтому из-за аварийного механизма запись не будет восстановлена, а значение c по-прежнему равно 0. Поскольку в бин-логе нет записи, при последующем восстановлении данных из бин-лога значение c в этой операции не записывается.Изменить, значит, он по-прежнему равен 0, что согласуется с данными в исходной базе данных, другая ситуация: журнал повторов обновляется, и журнал bin также обновляется. интерфейс фиксации. В настоящее время, несмотря на то, что в журнале повторов указано состояние «Подготовка»,Найти записи из журнала bin, поэтому c=1 все равно будет восстановлено из журнала повторов, и когда новая база данных будет восстановлена ​​непосредственно из журнала bin позже, поскольку значение c + 1 было записано, оно совпадает со значением в исходной базе данных.

Обобщенно следующим образом:

Есть два способа убедиться, что запись завершена:

  1. статус журнала повторов — фиксация
  2. статус журнала повторов — подготовкаа такжеЗапись журнала bin завершена (перед фиксацией)

Суммировать

В этом разделе в основном изучается использование двух файлов журнала. Журнал повторов используется для обеспечения возможности защиты от сбоев, а журнал bin используется для восстановления целостности данных

  • Когда для параметра innodb_flush_log_at_trx_commit установлено значение 1, это означает, что журнал повторов каждой транзакции сохраняется непосредственно на диске. Это гарантирует, что данные не будут потеряны после аварийного перезапуска MySQL.
  • Когда для параметра sync_binlog установлено значение 1, это означает, что binlog каждой транзакции сохраняется на диск. Это гарантирует, что binlog не будет потерян после аварийного перезапуска MySQL.

Знания в области комментариев:

  • binlog не используется для аварийного восстановления, binlog можно отключить, если у вас есть разрешение, вы можете"set sql_log_bin=0"Отключите журнал binlog для этого потока. Поэтому полагаться только на binlog для восстановления ненадежно.

  • Комментарий подушки @高 простым и изысканным образом выражает рабочий статус двухэтапного механизма подачи:
    Существует три процесса ведения журнала:

    1. подготовка стадии
    2. написать бинлог
    3. commit
    • когда разбился до 2
      Перезапустите и восстановите: Обнаружив отсутствие фиксации, выполните откат. Восстановление резервной копии: без бинлога. Резервная копия согласуется с исходной базой данных
    • когда разбился до 3
      Восстановление перезапуска: несмотря на то, что фиксации нет, но подготовка и binlog завершены, поэтому после перезапуска выполняется автоматическая фиксация. Бэкап: есть бинлог, бэкап соответствует оригинальной библиотеке

  • от @goldensun.

    • просить:
    1. Журнал повторов сам по себе тоже файл.Процесс записи файла и есть запись на диск.В чем разница между этим и описанной в статье автономной операцией записи на диск?
    2. В ответ на один SQL я так понимаю, что надо оперировать двумя лог файлами одновременно? То есть запись на диск дважды?
    • Ответ автора:

    1. Запись журнала повторов — это последовательная запись, нет необходимости «находить местоположение», а для обновления данных необходимо найти местоположение, поэтому скорость записи журнала повторов выше.

    2. На самом деле это 3 раза (редолог дважды, бинлог 1 раз). Однако записи будут объединены во время одновременных обновлений.

Эта статья содержит изображения и часть оригинального текста "MySQL Actual Warfare" от Geek Time. Если есть какие-либо нарушения, свяжитесь со мной, и я немедленно удалю ее.
Секция 1:I ACID: изоляция транзакций

  1. Журнал повторов не записывает «состояние после обновления» страницы данных, а записывает «какие изменения были сделаны» на этой странице.
    Существует два режима бинарного журнала, формат оператора для записи оператора sql; формат строки будет записывать содержимое строки, две записи, как до, так и после обновления.↩︎

Категории