gitlab, СУБД, LVM snapshots
Feb. 2nd, 2017 10:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Сегодня я узнал, что делать 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, файловая система или диск - неизвестно, но целостность файла БД нарушается.