![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gitlab, СУБД, LVM snapshots
Сегодня я узнал, что делать LVM snapshots (и прочие аналогичные действия на уровне "момент в жизни файловой системы") - валидный способ бэкапа PostgreSQL баз.
Вопрос - а как это согласуется с порядком записи/вызовов сисколлов/ordering файловой системы?
Т.е. можем ли мы быть уверены, то снапшот блочного девайса - гарантированно валиден с точки зрения FS и с точки зрения сидящей выше уровнем БД и кэшей уровня БД и уровня FS?
Потому как, например в случае Firebird - вроде это должно быть валидно, т.к. по словам разработчиков он использует careful writes - режим записи который не нарушает корректности БД, но точной уверенности у меня в этом нет, особенно с учетом написанного тут: https://danluu.com/file-consistency/
Кроме того, повреждения FB в случае аварийного пропадания питания у меня наблюдаются не так уж редко (раз в 3-6 месяцев на ~100 инстансов БД, эксплуатируемых в адских условиях). На каком уровне творится фигня - fb, файловая система или диск - неизвестно, но целостность файла БД нарушается.
Вопрос - а как это согласуется с порядком записи/вызовов сисколлов/ordering файловой системы?
Т.е. можем ли мы быть уверены, то снапшот блочного девайса - гарантированно валиден с точки зрения FS и с точки зрения сидящей выше уровнем БД и кэшей уровня БД и уровня FS?
Потому как, например в случае Firebird - вроде это должно быть валидно, т.к. по словам разработчиков он использует careful writes - режим записи который не нарушает корректности БД, но точной уверенности у меня в этом нет, особенно с учетом написанного тут: https://danluu.com/file-consistency/
Кроме того, повреждения FB в случае аварийного пропадания питания у меня наблюдаются не так уж редко (раз в 3-6 месяцев на ~100 инстансов БД, эксплуатируемых в адских условиях). На каком уровне творится фигня - fb, файловая система или диск - неизвестно, но целостность файла БД нарушается.
no subject
vm это такая абсолютно тупая штука, процесс у которого есть доступ n-гигов памяти и блочному устройству, vm про них ничего не знает, внутри этой памяти какие-то байты, где начинается буфер драйвера диска, где дисковый кеш, это vm неизвестно, какая фс внутри устройства, какое состояние у этой фс.
Передавать сигнал дальше винде или линуксу бегущему внутри vm тоже смысла нет, эта винда/линукс думают они живут в физической машине, для которой есть определенный набор сигналов который может придти из bios/acpi типа power-off, но нету сигнала давай готовься, тебя бекапить ща будут.
no subject
В отличие от попыток копирования файла БД руками. СУБД, которые работают со внутренней организацией, а не с ФС, эти файлы блокируют даже на чтение.
no subject
об этом и речь:
a. Этого недостаточно, это равнозначно внезапному ребуту, будут просраны буферы виртуалного контроллера диска, и дисковый кеш. постгре это скорее всего переживет потому что wal, а фаерберд возможно и нет.
b. это не нужно, потому что lvm снепшот с хоста сделает то же самое, моментальный - атомарный снепшот, причем не важно что там внутри лежало, и была-ли виртуализация вообще, или этот том содержал странную неизвестную ф.с. с файлами субд.
no subject
В цитируемой фразе говорится про ВМ, в ответах - про СУБД.
Срез LVM недостаточен, СУБД транзакции живут несколькими уровнями абстракции выше, ближайший верхний этаж - физическая запись байтиков в журнал (отсутствующий у Firebird, там создаются свои срезы).
Любая попытка делать срез или копировать руками при последующем восстановлении из этого хлама равносильна перезагрузке, т.е. "как повезет".