Fri, 18 Dec 2009 15:42:11 +0300 Alexey Pechnikov <pechni...@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: g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
