metaclass: (Default)
[personal profile] metaclass
Сегодня я узнал, что делать LVM snapshots (и прочие аналогичные действия на уровне "момент в жизни файловой системы") - валидный способ бэкапа PostgreSQL баз.

Вопрос - а как это согласуется с порядком записи/вызовов сисколлов/ordering файловой системы?
Т.е. можем ли мы быть уверены, то снапшот блочного девайса - гарантированно валиден с точки зрения FS и с точки зрения сидящей выше уровнем БД и кэшей уровня БД и уровня FS?

Потому как, например в случае Firebird - вроде это должно быть валидно, т.к. по словам разработчиков он использует careful writes - режим записи который не нарушает корректности БД, но точной уверенности у меня в этом нет, особенно с учетом написанного тут: https://danluu.com/file-consistency/
Кроме того, повреждения FB в случае аварийного пропадания питания у меня наблюдаются не так уж редко (раз в 3-6 месяцев на ~100 инстансов БД, эксплуатируемых в адских условиях). На каком уровне творится фигня - fb, файловая система или диск - неизвестно, но целостность файла БД нарушается.

Date: 2017-02-02 08:15 pm (UTC)
From: [personal profile] berezovsky
Сохранностью снапшота ведает Божий Промысел, а повреждения управляются Божьей Волей.

Date: 2017-02-03 03:00 pm (UTC)
kranov: (Default)
From: [personal profile] kranov
в общем случае lvm snapshot ничем не отличается от диска после внезапной перезагрузки, но кажись lvm понимает про некоторые файловые системы, по крайней мере бит clean умеет ставить для монтирования снепшота.

Я lvm-м долгое время бекапил/клонировал kvm виртуалки (на ходу)(сотни, винда, линукс, оракл, Cache), никогда проблем не было, изредка fsck, причем в этом случае lvm не видит фс и ничего не знает что там внутри целый мир со своими кешами и уж точно винде не может просигналить.

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

Date: 2017-04-11 07:52 am (UTC)
cross_join: (Default)
From: [personal profile] cross_join
Зачем "сигналить" винде, когда можно просигналить VM? ;)
Иначе -- черный ящик и магия на уровне "а у меня пока работает".

Date: 2017-04-11 01:08 pm (UTC)
kranov: (Default)
From: [personal profile] kranov
> когда можно просигналить VM? ;)
vm это такая абсолютно тупая штука, процесс у которого есть доступ n-гигов памяти и блочному устройству, vm про них ничего не знает, внутри этой памяти какие-то байты, где начинается буфер драйвера диска, где дисковый кеш, это vm неизвестно, какая фс внутри устройства, какое состояние у этой фс.

Передавать сигнал дальше винде или линуксу бегущему внутри vm тоже смысла нет, эта винда/линукс думают они живут в физической машине, для которой есть определенный набор сигналов который может придти из bios/acpi типа power-off, но нету сигнала давай готовься, тебя бекапить ща будут.

Date: 2017-04-11 01:13 pm (UTC)
cross_join: (Default)
From: [personal profile] cross_join
ВМ - это весьма умная штука, которая умеет быстро входить "в отключку" и выходить из неё. Соответственно, никакой проблемы скинуть целостный срез состояния на диск нет.
В отличие от попыток копирования файла БД руками. СУБД, которые работают со внутренней организацией, а не с ФС, эти файлы блокируют даже на чтение.

Date: 2017-04-11 02:28 pm (UTC)
kranov: (Default)
From: [personal profile] kranov
>ВМ - это весьма умная штука, которая умеет быстро входить "в отключку" и выходить из неё.
об этом и речь:
a. Этого недостаточно, это равнозначно внезапному ребуту, будут просраны буферы виртуалного контроллера диска, и дисковый кеш. постгре это скорее всего переживет потому что wal, а фаерберд возможно и нет.
b. это не нужно, потому что lvm снепшот с хоста сделает то же самое, моментальный - атомарный снепшот, причем не важно что там внутри лежало, и была-ли виртуализация вообще, или этот том содержал странную неизвестную ф.с. с файлами субд.

Date: 2017-04-11 02:58 pm (UTC)
cross_join: (Default)
From: [personal profile] cross_join
Смещение темы дететед :)
В цитируемой фразе говорится про ВМ, в ответах - про СУБД.
Срез LVM недостаточен, СУБД транзакции живут несколькими уровнями абстракции выше, ближайший верхний этаж - физическая запись байтиков в журнал (отсутствующий у Firebird, там создаются свои срезы).
Любая попытка делать срез или копировать руками при последующем восстановлении из этого хлама равносильна перезагрузке, т.е. "как повезет".
Edited Date: 2017-04-11 03:00 pm (UTC)

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 25th, 2017 12:44 am
Powered by Dreamwidth Studios