LINUX.ORG.RU
ФорумAdmin

Файловая система с журналом транзакций


0

0

Привет, народ!

Хотелось бы выяснить, возможен ли сабж. Проблема в том, что по слову «журнал» поисковики находят в основном кучу мусора, думаю, понятно почему.

Хотелка следующая: имеем некоторую файловую систему на RAID (впрочем, неважно на чем именно). Имеем дополнительно отдельный диск или зеркало. Хочется разместить на этом отдельном диске/зеркале журнал транзакций, обладающий следующими способностями:

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

2) пока RAID работает исправно, для чтения данных этот журнал нам вообще без надобности - все читается непосредственно с RAID.

3) логически вытекает из пункта 2: если вдруг этот журнал даст дуба, на доступность данных это никак не влияет — всё читается, и, возможно, пишется, непосредственно с/на RAID, только теперь уже без журнала.

4) если же дуба даёт RAID, мы восстанавливаем на новом железе из последнего бэкапа содержимое файловой системы (к примеру, двухмесячной давности), и, поскольку у нас есть не поврежденный журнал транзакций, «проигрываем» на ней все изменения, внесенные от момента этого бэкапа вплоть до момента сбоя, не потеряв при этом (теоретически) ни одного байта внесенных изменений.

5) при успешном создании полного бэкапа файловой системы всё, что было в журнале транзакций до этого момента бэкапа — рубится (автоматически или вручную).

Такая схема позволила бы сократить необходимую частоту бэкапов и при этом обеспечить вероятность невосстановимого сбоя на приемлемом уровне. А то делать полный бэкап каждые день/два накладно, а больше — стремно. Инкрементные бэкапы не предлагать — не верю я в них :-)

В России две проблемы ...
Да, и к дорогам ты отношения не имеешь.

sdio ★★★★★
()

Согласен с предыдущим оратором.

У Вас получился пятиколесный велосипед на треугольных колесах. Не едет, но и не падает.

ЗЫ Я вот три года участвую в проектирвании и внедрении СРК, но такого изврата еще никто не заказывал. Даже когда есть всякие репликации и прочие технические прибабахи...

Bebop ★★
()
Ответ на: комментарий от Bebop

Изврат, говорите? Тогда главные извращенцы находятся, видимо, здесь: http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

Читать на тему «archived redo log files»

Я просто хочу того же самого, только для файловой системы, а не для базы данных.

Иногда удивляюсь, как некоторые, с позволения сказать, личности бываю уверены, что уж они-то точно знают, как должен быть устроен мир.

shamus24
() автор топика

копай в сторону репликации блочных устройств, инкрементальных бэкапов и снапшотов. Этими средствами можно добиться похожего эффекта.

Есть всякие nullfs итп с «вечным» логом, но пока нужного функционала там нет.

true_admin ★★★★★
()

Зависит от требуемого соотношения актуальности бэкапа и скорости работы основного хранилища.

Практически полностью актуальный бэкап, но невысокая скорость — DRBD.
Максимальная скорость, но возможно отставание бэкапа от актуальных данных на часы или даже сутки — периодические инкрементальные бэкапы через rsync и иже с ним (rdiff-backup, rsnapshot, etc).

Инкрементные бэкапы не предлагать — не верю я в них :-)


===========>||
Ну ты понял :)

nnz ★★★★
()
Ответ на: комментарий от shamus24

>Изврат, говорите? Тогда главные извращенцы находятся, видимо, здесь: http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

Читать на тему «archived redo log files»

Бугага... Но с извращенцами вы почти угадали. Извращенцы не оракл, который дал средство, а те горе-админы, что копят логи неделями и считают что мол если что, то по быстренькому накатим пару недель изменений.

Из любой нормальной организации за такое выгоняют за профнепригодность.

Вот вам задачка - у вас база 500 Гиг. В день изменений на 10-15 Гиг. Теперь расскажите за какое время по вашему Вы сможете накатить изменения за две недели? И сколько дисковой емкости вы будете использовать... ну давайте назовем... неадекватно?

Иногда удивляюсь, как некоторые, с позволения сказать, личности бываю уверены, что уж они-то точно знают, как должен быть устроен мир.

Расскажите нам о вашем жизненном опыте - нам оченно интересно.

Bebop ★★
()
Ответ на: комментарий от Bebop

> Вот вам задачка

Спасибо, у меня своих цифр хватает.

База - 300 гиг, изменений в месяц - 10-30 гиг. И? Надо делать 300-гиговый бэкап раз в два-три дня, да? И эти люди рассуждают об адекватном использовании дисковой емкости.

Повторюсь ещё раз: в реальности - оно по-разному случается, вне зависимости от ваших представлений о реальности.

shamus24
() автор топика
Ответ на: комментарий от shamus24

>База - 300 гиг, изменений в месяц - 10-30 гиг. И? Надо делать 300-гиговый бэкап раз в два-три дня, да? И эти люди рассуждают об адекватном использовании дисковой емкости.

Вот Вы тугой-то!!! Для таких как Вы придумали дифференциальные бэкапы. Все, точка.

У оракла оно в rman-е искаропки, только успевайте правильный level задавать - и будет он хоть дифференциальный, хоть инкрементальный.

А вопросы Вашего неверия во что-то можете сразу адресовать в тот же оракл, или, к примеру, в веритас, или в любую другую лавку которая десятилятиями пользуется механизмом дифф. РК и как-то даже не знает что в него можно не верить.

ЗЫ Вы мне так и не ответили, за сколько по времени Вы накатите на оракл хотя бы 30 Гиг журнала (в реальности журналов будет больше, даже при Ваших цифрах). Хоть раз-то делали о чем рассуждаете? А еще какой допустимый простой у Вашей мегабазы?

Забавляют меня люди которые городят «стройные» системы костылей и подпорок - используют продвинутые технологии (где не надо), чтобы не приведи случай, одна транзакция не потерялась. Но при этом простой в пол рабочего дня, пока они эту одну транзакцию догоняют, их в общем-то не парит.

Нормальная система резервного копирования должна быть прямой как палка и простой как свинцовая чушка!

Bebop ★★
()
Ответ на: комментарий от Bebop

> Для таких как Вы придумали дифференциальные бэкапы

Для кого тогда Оракл придумал механизм архивных журналов? И не он один. И вообще, дифференциальный бэкап я и без помощи лора в состоянии сделать. Мне интересны варианты и технологии. Не пойму, зачем вы меня пытаетесь убедить в том, что мне это не нужно? Тем более, что всё равно нету.

Вы мне так и не ответили, за сколько по времени Вы накатите на оракл хотя бы 30 Гиг журнала

Мне пришлось делать это один раз на рабочей базе. Только не помню сколько там реально было файлов журнала, думаю, гиг 10 примерно. Заняло меньше часа. Быстрее, чем восстановление самой базы по сети. Кстати, произошло это после фальшивого сбоя аппаратного SCSI-райда, когда контроллер отрапортовал о двух сбойных дисках одновременно, и погасил массив, а после перезапуска выяснилось, что все диски целые и абсолютно нормальные. Я теперь должен на этом основании рекомендовать всем не пользоваться аппаратными SCSI-райдами?

shamus24
() автор топика
Ответ на: комментарий от shamus24

>Для кого тогда Оракл придумал механизм архивных журналов?

Журнал нужен для возможности восстановления на какой-то конкретный момент времени. Я это не пытаюсь оспорить. Все что я хочу сказать это то, что он не является заменой резервной копии!

Покажите мне документ от оракла где бы он рекомендовал использовать его для задачь долговременного резервирования.

Правильный подход это РК + журнал. В случае сбоя восстанавливаются данные из РК и потом докатывается журнал за время с последнего копирования. К примеру, раз в неделю полное копирование, каждый день дифф, и раз в час подбор архивных логов. Это обеспечит гарантированное RPO в 1 час, даже если сервер и его хранилище со всеми рейдами погибли смертью храбрых и восстановлению не подлежат.

Заняло меньше часа. Быстрее, чем восстановление самой базы по сети.

Вы бы сравнили скорости если бы резервная копия была в такой же доступности как и логи, к примеру на диске или на ленте доступной напрямую. Если надо быстро и по сети, то проектируйте нормальный сегмент сети. Нормально спроектированные СРК обеспечивают требуемые скорости легко.

Я теперь должен на этом основании рекомендовать всем не пользоваться аппаратными SCSI-райдами?

А каковы альтернативы? RAID контроллеры как и массивы бывают плохие, а бывают хорошие. А еще бывают неудовлетворительные условия эксплуатации. Но все это не имеет отношения к нашей дискусии.

Bebop ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.