erthink
Инкрементальный бекап/рекавери.
Благодаря режиму "LIFO RECLAIM" размер такого бекапа должен быть, в некоторых сценария, минимален.
Для реализации такого механизма предложу свою идею:
- Создать битмап индек в виде файла в той же дирректории что и база данных. (один бит - один блок/страница бд)
- Устанавливать биты в "1" если блок связывается с транзакцией и считается потенциально "грязным"
- Устанавливать биты в "0" после "реального коммита" или перед началом инкрементального бекапа -> "пройдя по списку" свободных блоков.
алгоритм инкрементального бекапа :
- поставить "0" в таком битмапе по всем страницам что принадлежат списку свободных блоков.
- скопировать в стрим весь индек. , потом последовательно все блоки для которых в индексе установлен "1".
Восстановление:
- перезаписать все блоки для которых в индексе установлены "1" . (в файле инкрементального бекапа все блоки уже в нужной последовательности)
- запустить проверку корректности. (этот алгоритм уже присутствует)
ЗЫ: полный (не инкрементальтный) бекап это бинарная копия файла базы данных.
В следующей версии (ветка devel) подобное планируется реализовать, но несколько иначе:
- заголовок страницы внутри БД будет добавлен номер породившей её транзакции (это также требуется для контроля целостности посредством Merkle Tree).
- при инкрементальном бакапе последовательно сравниваются номера транзакций в актуальной и БД и резервной копии.
- обновленные страницы помещаются в очередной слой incremental backup.
Леонид, предложу к Вашему алгоритму пару дополнений :-) :
- в момент помещения страницы в список свободных блоков, устанавливать номер транзакции в "0" , дабы страница игнорировалась при бекапе.
- возможно ли на уровне листов б-три индекса устанавливать максимальный номер транзакции в поддереве для ускорения операции инкрементального бекапа ? (в таком случае не нужно сканировать поддерево чем и ускориться операция бекапа)
Это достаточно очевидные вещи, которые я опустил как детали. Но теперь, на всякий случай, отмечу два момента:
- пометка нулем нужна если вы идете линейно по файлу, а не обходите дерево.
- отметка о максимальном номере, напротив, полезна только при обходе дерева.
- отметка о максимальном номере транзакции в под-дереве будет занимать место в каждой branch-page.
- следом в branch-страницы напрашивается еще масса "вкусных" значений, например кол-во ключей в поддереве для быстрой оценки range-выборок.
Спасибо, вы меня успокоили ))) жду следующий "релиз", а пока буду rust биндинг пилить.