Блог

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

аварийное восстановление

Действия по очистке, которые происходят при повторном запуске MySQL после сбоя. Для таблиц InnoDB изменения от незавершенных транзакций воспроизводятся с использованием данных из журнала повтора. Изменения, которые были зафиксированы до сбоя, но еще не записаны в файлы данных, восстанавливаются из буфера двойной записи. Когда база данных завершает работу в обычном режиме, этот тип действий выполняется во время завершения работы с помощью операции очистки.
Во время нормальной работы зафиксированные данные могут храниться в буфере изменений в течение определенного периода времени, прежде чем быть записанными в файлы данных. Всегда существует компромисс между поддержанием файлов данных в актуальном состоянии, что приводит к увеличению производительности при нормальной работе, и буферизацией данных, что может привести к более длительному завершению работы и аварийному восстановлению. Смотрите также Изменить буфер, фиксацию, сбой, файлы данных, буфер двойной записи, InnoDB, очистка, журнал повтора.
это из mysql refman-5.7-ru.pdf.

Если это реально, я не знаю, какое использование имеет журнал повтора. Потому что, когда происходит сбой, mysql может восстановить себя через буфер двойной записи. Кажется, журнал повтора не имеет смысла. Может быть, я где-то игнорирую, но я не знаю.
Я хочу знать разницу между ними и важно ли для mysql InnoDB журнал повтора?

Журнал повтора, по-видимому, функционирует на более низком, более критическом уровне. Я использую MySQL как инструмент анализа рабочего стола, поэтому я решил, что мне не нужна защита рабочей базы данных. Я вижу заметно улучшенную производительность запросов, когда буферизация двойной записи отключена ( innodb-doublewrite=0 ). Никаких проблем с этим уже более года. Журнал повтора — это другая история; в течение недели после его отключения мне пришлось перестраивать свою базу данных.

В версии 8.0.21 была введена возможность переключения журнала повтора ( ALTER INSTANCE ENABLE|DISABLE REDO_LOG ). «Почему бы не попробовать?» Я подумал. После отключения я увидел улучшение скорости загрузки на 2-5%.

Это имеет значение при загрузке больших файлов, особенно если используется утилита параллельного импорта таблиц (введенная в 8.0.17).

К сожалению, я оставил ЖУРНАЛ ПОВТОРА отключенным, и на моей рабочей станции произошел сбой при записи в таблицы, и в итоге появилось это сообщение об ошибке:

 [ERROR] [MY-013578] [InnoDB] Server was killed when Innodb Redo logging was disabled. Data files could be corrupt. You can try to restart the database with innodb_force_recovery=6
 

Мне пришлось инициализировать новый экземпляр, так как ни одна из таблиц не позволила мне ничего записать после того, как я получил эту ошибку.

Force_recovery=6 является строгим и доступным только для чтения. Мне пришлось перестроить свою базу данных (что я в основном и делаю каждый раз, когда импортирую таблицы), но несколько таблиц констант и истории мне пришлось восстанавливать вручную.

Это задокументировано на странице документации журнала повтора страницы MySQL.Предупреждение о журнале повтора получает затененную жирным шрифтом предупреждающую выноску. Я должен был прислушаться к этому.

Я по-прежнему отключаю журнал повтора, но только изнутри кода .js, который запускает утилиту параллельного импорта:

 sql
SET GLOBAL local_infile = 1;
ALTER INSTANCE DISABLE INNODB REDO_LOG;
 

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

Может быть, это сообщение в блоге ответит на ваш вопрос:

Нажмите здесь