Реализация резервирования сервера базы данных малой кровью на примере Oracle Standard Edition.
Содержание
Лирическое вступление.
Создание и обновление.
Переключение standby instance в режим read only.
Перевод standby instance в режим primary instance.
О недостатках.
Лирическое вступление.
10 лет назад на одной из моих прошлых работ один пользователь запустил "крутой дефрагментатор", скачанный из Интернета, на машине с самым большим жестким диском в конторе - 2.5ГБ. На этом диске хранились документы, созданные за последние 3 года - почти все документы небольшой организации. Полная порча корневой директории и обеих копий таблицы FAT говорили, что документам конец, но половину документов удалось восстановить благодаря недавно сделанной дефрагментации: мы посредством прямого редактора
диска искали блоки, похожие на директории, находили размер и начальный кластер файла и затем считывали данные прямо с физического диска. Если бы в организации выполнялись элементарные процедуры по резервированию и сохранению данных, то эти "танцы с бубном" были бы не нужны и вторая половина документов сохранилась бы.
Хороший пример, подтверждающий пользу резервного копирования?! Ведь пропажа документов или базы данных может привести к серьезному сбою в работе организации и даже к вопросу о ее ликвидации!
Хорошо, с резервным копированием более-менее ясно. Что еще? Еще резервирование серверов!
Что тут может быть сложно, скажете вы? - Делаем бекап данных, а при падении сервера поднимаем новый и восстанавливаем данные из бекапа! Да, возможно это выход, но пока мы будем поднимать сервер, настраивать его и заливать данные (а их может быть многие гигабайты), работа организации будет остановлена. Особенно это критично для баз данных. Скажем, пропадение базы клиентов весьма затруднит работу почти всем службам организации на те часы, которые вы потратите на восстановление и запуск системы. Если клиентов
тысячи или того больше - это очень критично. А если при этом под рукой не нашлось подходящего "железа"? - Тогда начинаем бегать высунув язык: срочно искать наличность (за безнал быстро не купишь - разве что под гарантийное письмо) и бежать в магазин за железом, а заодно и за вазелином (за такой просчет точно не наградят). Не лучше ли заранее подготовиться к возможным катаклизмам? Кроме того, в резервной копии, естественно, не будет последних изменений, сделанных после выполнения последнего бекапа.
Ведь не делать же бекап каждые пять минут...
Oracle для постоянного поддержания живой копии базы имеет возможность объединять сервера баз в группу. Один сервер является главным - с ним и работают пользователи, а на остальные идет онлайн копирование изменений основной базы. В случае выхода из строя основного сервера один из резервных перейдет в режим главного и работа организации может быть продолжена. Такая возможность Oracle называется "Data Guard".
Для реализации этого режима необходим Oracle Enterprise Edition. В документации хорошо описано, как это сделать. Сложность может оказаться не в технической реализации, а в финансах: Enterprise существенно дороже Standard. Если вы можете позволить себе приобрести Enterprise или пользуетесь пиратским софтом, то можете не забивать себе голову той ерундой, которую я собрался вам рассказать, а делайте все по документации.
Описал я Data Guard очень грубо - своими словами. Я не специалист по Oracle. Год назад я не знал еще, что буду с ним работать. Скажу больше: я его в глаза не видел. Я подчеркиваю это, чтобы показать, что чтобы сделать описанное ниже, не обязательно быть крутым специалистом - достаточно иметь время и читать документацию. Правда, толковый советчик тоже не помешал бы (и он у меня был).
Далее я расскажу, как сделать подобие Data Guard, имея в распоряжении только Oracle Standard Edition.
Это не наше изобретение. В Интернете был найден любопытный документ, в котором на нескольких картинках и десятке строк текста (документ PowerPoint) было показано, как это сделать. Наша же заслуга только в том, что мы смогли это реализовать и это стабильно работает уже полгода.
Создание и обновление.
Для начала нам необходимо создать два одинаковых сервера. Желательно, чтобы операционные системы, расположения файлов Oracle, табличных пространств и логов совпадали - это сделает перенос "холодной" копии базы легким делом.
На основном (primary) сервере создаем необходимые instances и заливаем данные. На резервном (standby) настраиваем Oracle, создаем те же instances (нужны лишь имена - табличные пространства и логи можно не создавать).
После запуска и проверки работоспособности primary сервера необходимо сделать "холодную" копию каждого резервируемого instance на standby сервере: