MySQL: руководство профессионала

Как только транзакция 1 закончила физическую запись, или транзакция 2 или 3 (но не обе) запишут незаписанную часть данных, находящуюся в оперативной памяти, файл регистрации будет готов к сбросу на диск. Потому как обе транзакции произошли после с последней записи на диск последовательного файла регистрации, информация для обемх записана на диск в то же самое время.

В то время как транзакции 2 и 3 записывают, транзакции 4, 5 и 6 записываются в журнал в оперативной памяти. Когда запись для 2 и 3 завершается, входы для 4, 5 и 6 записаны.

Результат вышеупомянутого процесса: имеются только три физические записи на диск, даже при том, что имеется шесть транзакций в последовательности:

Транзакция 1,

Транзакции 2 и 3,

Транзакции 4, 5 и 6.

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

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

2.4.5.3. Восстановление аварийного отказа Falcon

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

В течение восстановления аварийного отказа Falcon исследует последовательный файл регистрации и идентифицирует первый вход, который не был передан к базе данных. Процесс восстановления записывает все незаписанные данные, изменяет индекс и данные blob, освобождая любые необходимые слоты записи (из удаленных записей) и завершая любые структурные изменения.

2.4.5.4. Кэши памяти Falcon

Falcon был разработан, чтобы выполняться лучше всего на системах с щедрыми объемами памяти. Кэши памяти, используемые Falcon подобны в некоторых отношениях другим СУБД и MySQL. Однако, структура кэш имеет ряд усовершенствований по сравнению с традиционной cтратегией кэширующей памяти. Механизмы, используемые Falcon относительно кэширования памяти включают:

Log Cache информация файла регистрации сохраняется в памяти и сбрасывается на диск, когда транзакции совершаются. Falcon хранит восемь окон для чтения и записи в журнал, и каждое окно 1 MB.

System and Index Cache данные, необходимые Falcon (определения таблицы и полей, состояние транзакции и т.д.) также поддерживаются в памяти для справочника. Кроме того, локальные индексные акселераторы представляют индексные сегменты, созданные выполняющейся транзакцией, также сохранены в памяти системы. Когда транзакция изменяет индексированные поля, это формирует индексный раздел акселератора в памяти системы, представляя изменения. При завершении транзакции все индексные измене ния для транзакции записаны в сортируемом порядке в последовательный вход и позже объединены с постоянным индексом.

Page Cache страницы базы данных читаются с диска для специфической базы данных. Размер кэша страницы управляется параметром falcon_page_cache_size, значение по умолчанию которого 4 MB установлено в файле my.cnf. Хотя изменения записи и индекса идут в последовательный файл регистрации прежде, чем запишутся в страницы базы данных, данные blob записаны непосредственно в кэш страницы. Это не дает регистрировать большие элементы данных, которые редко вызваны или изменены транзакцией, которая создает их.