как долго эти страницы обычно остаются грязными в памяти?
Это переменная.InnoDB имеет фоновый поток, который сбрасывает грязные страницы на диск.Он сбрасывает скромное количество страниц, а затем делает это снова через 1 секунду.
Так что, если вы сделаете много обновлений за короткий промежуток времени, вы бы испортили много страниц.Тогда промывочная нить будет постепенно сбрасывать их на диск.Идея состоит в том, что это помогает растянуть работу со временем, поэтому внезапный всплеск обновлений не перегружает ваш диск.
Но это означает, что «как долго эти страницы остаются грязными в памяти» может варьироватьсянемного.Я думаю, что в типичных случаях это будет сделано за несколько минут.
Различные версии MySQL сбрасываются по-разному.Несколько лет назад основной фоновый поток сбрасывал фиксированное количество страниц каждую 1 секунду.Затем они разработали адаптивную промывку, поэтому она автоматически увеличит частоту промывки, если обнаружит, что вы вносите много изменений.Затем они создали специальную ветку под названием «Очиститель страниц».Я думаю, что даже можно настроить MySQL для запуска нескольких потоков очистки страниц, но это не является необходимым для большинства приложений.
Вас также могут заинтересовать мои ответы на эти вопросы:
Допустим, размер буфера равен 1 ГБ или что-то еще (не знаю, сколько обычно имеют серверы баз данных)
Это действительно меняется и зависит от приложения.Размер пула буферов innodb по умолчанию составляет 128 МБ, но это слишком мало для большинства приложений, если это не тестовый экземпляр.
В моей компании мы стараемся поддерживать буферный пул не менее 10% от размера данных на диске.Некоторым приложениям нужно больше.Самый распространенный размер - 24 ГБ, но самый маленький - 1 ГБ, а самый большой - 200 ГБ.Мы управляем более 4000 производственных экземпляров MySQL.
Сколько из этих 1 ГБ может быть грязными страницами?
Все они, в теории.MySQL имеет переменную config, вызывающую innodb_max_dirty_pages_pct, которая, как вы можете предположить, блокирует любые дальнейшие грязные страницы, если их слишком много.Но это не так.Вы все еще можете изменить больше страниц, даже если буферный пул более грязный (в процентном отношении), чем эта переменная.
Что на самом деле делает переменная, если буферный пул заполнен более чем на процент процентом грязных страниц,скорость сброса грязных страниц увеличивается (IIRC удваивает количество страниц, которые он сбрасывает за цикл), пока число снова не опустится ниже этого процентного порога.
, если питание теряется без резервного питаниятогда все изменения в этих грязных страницах будут потеряны правильно?
Да, но вы не потеряете изменения, потому что они могут быть восстановлены из журнала повторов InnoDB - эти два файла iblogfile_0 и iblogfile_1, возможно, вы видели в вашем каталоге данных.Любая транзакция, которая создала грязную страницу, должна быть зарегистрирована в журнале повторов во время фиксации.
Если у вас происходит сбой питания (или другой тип перезапуска процесса mysqld), первое, что делает InnoDB, это сканирует повтор.журнал, чтобы проверить, что каждое зарегистрированное изменение было сброшено перед сбоем, или, если нет, загрузите исходную страницу и повторно примените изменения из журнала, чтобы снова сделать грязную страницу.Это то, что InnoDB называет восстановлением после сбоев.
Вы можете наблюдать, как это происходит.Хвост журнал ошибок на тестовом экземпляре MySQL Server, а вы kill -9 процесс mysqld.mysqld_safe перезапустит процесс mysqld, который выбросит кучу информации в журнал ошибок при выполнении восстановления после сбоя.
Если нужно было восстановить только небольшое количество грязных страниц, это будет довольно быстро, возможно, всего за несколько секунд.Если буферный пул был большим и имел много грязных страниц, это займет больше времени.MySQL Server не полностью запущен и не может принимать новые клиентские соединения, пока восстановление после сбоя не завершеноЭто вызвало много минут беспокойства администратора базы данных MySQL, наблюдая за процессом восстановления после сбоя.Невозможно предсказать, сколько времени потребуется после сбоя.
Поскольку журнал восстановления необходим для восстановления после сбоя, если журнал повторного заполнения заполняется, MySQL должен очистить некоторые грязные страницы.Это не позволит грязным страницам быть очищенными, а также невосстановимыми из журнала повторов.Если это произойдет, вы фактически увидите записи, приостановленные InnoDB, пока он не выполнит своего рода «аварийную очистку» самых старых грязных страниц.Раньше это было проблемой для MySQL, но с такими усовершенствованиями, как адаптивная очистка и очиститель страниц, он намного лучше справлялся с темпами изменений.Вам понадобится по-настоящему необычное количество записей и журнал повторного выполнения небольшого размера, чтобы жестко остановиться на InnoDB, пока он выполняет синхронизацию.
Вот хороший блог о сбросе: https://www.percona.com/blog/2011/04/04/innodb-flushing-theory-and-solutions/
PS: Для обязательного bash против MyISAM я укажу, что MyISAM не имеет журнала повторов, не имеет восстановления после сбоя и полагается на буфер файла операционной системы хоста во время записи в его файлы данных.Если на вашем хосте произошел сбой питания во время ожидающих записей в файловом буфере, которые еще не записаны на диск, вы потеряете их.MyISAM не имеет реальной поддержки для свойства Durability ACID.
Ваш комментарий:
Страница, вероятно, будет очищена к тому времени, когда журнал повторов будет перезагружен.То есть, если у вас есть 2x 48 МБ файлов журнала повторов (размер по умолчанию), и вы записываете в него достаточно транзакций, чтобы полностью просмотреть его и начать все сначала, все страницы в буферном пуле, загрязненные за это время, должны будутбыть покрасневшим.Страница не может оставаться грязной в BP, если соответствующая транзакция в журнале повторов перезаписана новыми транзакциями.
Насколько я понимаю, для грязной страницы практически невозможно оставаться грязной в пуле буферов.без очистки в течение 12-24 часов.
Возможное исключение, и я просто размышляю об этом, заключается в том, что данная страница обновляется снова и снова перед ее сбросом.Поэтому это остается недавней грязной страницей в течение долгого времени.Опять же, я точно не знаю, преодолевает ли это необходимость очистки страницы при повторном запуске журнала повторов.
Несмотря на это, я думаю, что это крайне маловероятно.
Кроме того, я неуверен, что вы подразумеваете под судебной экспертизой.Нет прямого способа проверить версии страниц из пула буферов.Чтобы получить информацию о последних изменениях из InnoDB, вам нужно изучить сегмент отмены, чтобы найти предыдущие версии страниц, и сопоставить их с записями журнала повторов.Грязная страница и ее предыдущие версии могут быть как в пуле буферов, так и на диске.Там нет команд или API или какой-либо структуры данных, чтобы сделать любую из этой корреляции.Таким образом, вы будете делать ручные дампы как образов дисков, так и образов памяти, а также следите за указателями вручную.
Намного проще отслеживать изменения данных, изучая поток изменений в двоичном журнале.Это не зависит от InnoDB.