Re: Master-slave репликация для SQLite - теоретический вопрос.
Fri, 18 Dec 2009 15:42:11 +0300
Alexey Pechnikov <pechnikov@mobigroup.ru> wrote:
> Hello!
>
> On Friday 18 December 2009 13:16:26 Alexander GQ Gerasiov wrote:
> > > Простите, джентльмены, но я не очень понимаю о чем спор. Снапшот
> > > lvm вам может гарантировать только целостность с точки зрения
> > > ядра, которая ни разу не является целостностью с точки зрения
> > > приложений. Или я что-то неправильно понимаю...
> > моментальность состояния блочного устройства эквивалентна выключению
> > питания.
Кстати я тут подумал - снэпшот менее травматичен, чем отключение
питания. При снэпшоте буффера ОС/ФС не теряются.
> > Благодаря журналируемым ФС такое блочное устройство можно
> > легко примонтировать, в благодаря нормальным DBS с внутренними
> > журналированием, неонкой и думателем из файла можно поднять DBS в
> > корректное состояние (на какой-то момент в прошлом).
>
> Абсолютно неверно.
>
> Восстановление "битой" ФС, хоть и возможно, но отнюдь не гарантирует
> целостность данных - журналирование защищает только саму ФС, а данные
> могут оказаться разрушенными. Подумайте, зачем нужен каталог
> lost+found.
lost+found - это как раз нарушение целостности фс. К целостности
данных оно отношения не имеет. Насколько целостны будут данные - завит
от ФС и ее настроек. В ряде случаев можно быть увереным, что данные
будут правильными на какой-то момент времени.
>
> Учитывая, что часть состояния БД хранится в ОЗУ, данные только с
> диска никак не способны обеспечить БД в согласованном состоянии. Сама
> СУБД имеет более или менее навороченную логику восстановления,
> применяемую в таком случае, но эта ситуация отнюдь не является
> "корректным состоянием". Опять же, речь идет о восстановлении
> работоспособности БД ценой потери части данных.
Естественно, а я где-то писал обратное? Нормальная СУБД должна уметь
подниматься в такой ситуации. Пусть и с потерей данных. Благодаря
использованию механизмов журналирования теряется очень небольшая часть
данных, преимущественно последние изменения. И СУБД поднимется в
корректное состояние с сохранением целостности данных.
> Для корректного переноса есть технологии live migration в виртуалках,
> обеспечивающие перенос как данных на диске, так и образа оперативной
> памяти, и только в этом случае потери данных не будет.
Для корректного переноса есть механизмы дампов содержимого БД и тому
подобное. Но на практике отдельно дампить каждую sqlite базу никто не
будет. (Их у одного файрфокса десяток, ога). Речь идет о том, что со
снэпшота вполне можно подняться.
--
Best regards,
Alexander GQ Gerasiov
Contacts:
e-mail: gq@cs.msu.su Jabber: gq@jabber.ru
Homepage: http://gq.net.ru ICQ: 7272757
PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Reply to: