![[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
В цитируемой фразе говорится про ВМ, в ответах - про СУБД.
Срез LVM недостаточен, СУБД транзакции живут несколькими уровнями абстракции выше, ближайший верхний этаж - физическая запись байтиков в журнал (отсутствующий у Firebird, там создаются свои срезы).
Любая попытка делать срез или копировать руками при последующем восстановлении из этого хлама равносильна перезагрузке, т.е. "как повезет".