Re: Master-slave репликация для SQLite - теоретический вопрос.
Fri, 18 Dec 2009 18:12:33 +0300
Alexey Pechnikov <pechnikov@mobigroup.ru> wrote:
> Hello!
>
> On Friday 18 December 2009 16:15:47 Alexander GQ Gerasiov wrote:
> > > Учитывая, что часть состояния БД хранится в ОЗУ, данные только с
> > > диска никак не способны обеспечить БД в согласованном состоянии.
> > > Сама СУБД имеет более или менее навороченную логику
> > > восстановления, применяемую в таком случае, но эта ситуация
> > > отнюдь не является "корректным состоянием". Опять же, речь идет о
> > > восстановлении работоспособности БД ценой потери части данных.
> > Естественно, а я где-то писал обратное? Нормальная СУБД должна уметь
> > подниматься в такой ситуации. Пусть и с потерей данных. Благодаря
> > использованию механизмов журналирования теряется очень небольшая
> > часть данных, преимущественно последние изменения. И СУБД
> > поднимется в корректное состояние с сохранением целостности данных.
>
> Потеря хоть одной завершенной транзакции - ЧП. А вы предлагаете
> наплевать на десятки, сотни и тысячи, сколько их там было в последние
> секунды.
Речь о бэкапе, а не о горячем резерве, ога?
> > > Для корректного переноса есть технологии live migration в
> > > виртуалках, обеспечивающие перенос как данных на диске, так и
> > > образа оперативной памяти, и только в этом случае потери данных
> > > не будет.
> > Для корректного переноса есть механизмы дампов содержимого БД и тому
> > подобное. Но на практике отдельно дампить каждую sqlite базу никто
> > не будет. (Их у одного файрфокса десяток, ога). Речь идет о том,
> > что со снэпшота вполне можно подняться.
>
> Хм, утверждение про десяток 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: