[Uneex] Предложение по теме семинара

[Yuri Ryazantsev]

On Wed, 20 Oct 2004 18:00:04 +0400 Constantin Stefanov
<cstef на parallel.ru> wrote:

> Yuri Ryazantsev wrote:
> 
> >>>>Но сумеет
> >>>>ли восстановиться? Ни у кого не было опыта (на любой СУБД -
> >>>MySQL,>PostreSQL, Oracle) - интересно, насколько такое вообще
> >>>корректно?
> >>>
> >>>Для Oracle - да и вообще для "толстых" СУБД - некорректно. В
> >>>"толстых" системах резервного копирования (например, Legato
> >>>или Veritas) есть специальные модули для этого дела.
> >>
> >>Что некорректно -я понимаю. Но возможно ли? Т.е. если я
> >>восстановлю, каковы шансы, что оно все-таки запустится?
> > 
> > Позвольте не согласиться. Вполне корректно, если понимать, что
> > делаешь:
> > 
> > 1. Потушили БД
> > 2. Скопировали файлы
> > 3. Подняли БД
> > 
> > Причем этот алгоритм работает практически на всех БД :-))
> > 
> > А вот если выкинуть 1 и 3 пункты, то много зависит от
> > структуры БД. Но даже в такой ситуации ORACLE поднимали в 8
> > случаях из 10.
> Не, я понимаю, что так, в 3 пункта, корректно. Я имел в виду
> именно только 2 пункт, без остановки, т.е. взять слепок ФС.
> Более того, с тем же PostgreSQL у меня получалось его поднять,
> подусунув ему бэкап, полученный на FreeBSD 4 при помощи dump,
> т.е. даже не моментальный слепок состояния, а несколько
> размазанный по времени (для коррекции этого WAL, как понимаю, и
> предназначен). Но меня интересует, ели можно так сказать,
> статистика - насколько часто происходит так, что данные теряются
> полностью (не какие-нибудь последние изменения, а, например,
> случайный куски или все целиком).

Мне непонятно - зачем извращаться, если есть нормальный pg_dump.
Тем более, что для долго работающей базы он и фрагментацию уберет
:-)

-- 
Yuri Ryazantsev <yuri на unix.ru>          | RIPE: YR1-RIPE
UNIX System Network Administrator       | RIPN: YAR1-RIPN