RAC and mirroring control files and redo log

Поясните мне про конфигурацию RAC.
Две ноды, общий сторедж. Мы храним control file и redo logs на общем хранилище - т.к. все они на "одном диске" имеет ли смысл делать зеркалирования - ведь в случае падения (серьезного падения) хранилища - все копии помрут одновременно. Или я не прав - и все таки надо делать зеркалирование. (ссылки на статьи из металинка и точные ссылки на документацию приветствуются).

Дополнительный вопрос - в случае смерти стораджа - мы полностью теряем всю информацию из redo logа? (остальное можно всстановить из бекапа + из архивных логов).

Sergey Lookin

Поясните мне про конфигурацию RAC. Две ноды, общий сторедж. Мы храним control file и redo logs на общем хранилище - т.к. все они на "одном диске" имеет ли смысл делать зеркалирования - ведь в случае падения (серьезного падения) хранилища - все копии помрут одновременно. Или я не прав - и все таки надо делать зеркалирование. (ссылки на статьи из металинка и точные ссылки на документацию приветствуются). Дополнительный вопрос - в случае смерти стораджа - мы полностью теряем всю информацию из redo logа? (остальное можно всстановить из бекапа + из архивных логов).

мирроринг делается от логических сбоев(желательно на разные RAIDы + на разных конроллерах),
а не от разрушения стореджа как такового
для последнего делается катастрофоустойчивый SAN

потеряв весь сторедж - поретяем REDO тоже
ПС
в простейшем случае - когда весь сторедж - это один большой REID
- можно всё делать без мирроринга,
понимая что при этом происходит

denix1

мирроринг делается от логических сбоев(желательно на разные RAIDы + на разных конроллерах)

кхе-кхе... Я бы сказал, от физических повреждений одного из стораджей, а также ошибок системщиков :-).

2 Sergey Lookin: RAC не защищает от сбоев носителя и логических ошибок приложения/оператора/пользователя. Для этого есть standby и/или backup. Redo log'и защищают как в обычной БД. В частности от разрушения хранилища защищаются дублированием хранилищ ;-).

Всего

Ааз

denix1 мирроринг делается от логических сбоев(желательно на разные RAIDы + на разных конроллерах) кхе-кхе... Я бы сказал, от физических повреждений одного из стораджей, а также ошибок системщиков :-).

имелось в виду
"control file и redo logs"..."имеет ли смысл делать зеркалирования"...

denix1

...

Этак мы до определений дойдем и окончательно запутаемся :-). По рецептуре - согласен на все 100%.

Всего

denix1

Ааз denix1 мирроринг делается от логических сбоев(желательно на разные RAIDы + на разных конроллерах) кхе-кхе... Я бы сказал, от физических повреждений одного из стораджей, а также ошибок системщиков :-). имелось в виду "control file и redo logs"..."имеет ли смысл делать зеркалирования"...

Пусть меня поправят, но как я понимаю, наличие redo + control files + archive logs + backup гарантирует возможность полного восстановления БЕЗ потери транзакций.

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

Вообще-то мультиплексировать redo (+control) имеет смысл даже если все вертится на одном шпинделе -- операция записи будет неодновременной и больше вероятность что хоть одна из копий останется целой (логически) в случае краха при записи.

PS. Аппаратное зеркало в этом случае не спасает -- оно благополучно зеркалирует кривой файл -- ситуация знакомая, понадеялись на RAID1, пропало питание, база не открывается -- кривой redo. Пришлось выполнять неполное восстановление, благо база девелоперская.

Вячеслав Любомудров

мультиплексировать

+1

Теримин зеркалирование (mirroring) больше применим к низкоуровневым RAID1

Вячеслав Любомудров

имеет смысл даже если все вертится на одном шпинделе -- операция записи будет неодновременной и больше вероятность что хоть одна из копий останется целой (логически) в случае краха при записи.

Ой ли ? В вариациях NCQ и различных кешей - начиная от уровня HDD до самой ОС в т.ч. ?

Я думаю, по-барабану
ФИЗИЧЕСКИ на диск одновременно будет писаться блок / блоки принадлежащие, как правило, только одному файлу. Даже, если не в порядке поступления -- нас это не волнует. И если в момент записи умрет питание (полблока записалось, половина нет), запорчен будет только один файл.

Теоретически, конечно, можно предположить, что эти два блока разных файлов, которые именно сейчас нужно записать, принадлежат одному цилиндру и имеют один номер сектора , но думаю, это маловероятно -- все нормальные ОС (контроллеры?) выделяют место, минимизируя перемещение блока головок.