Лирическое вступление.
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 сервере:
1. остановить primary instance
ALTER DATABASE CLOSE;
или
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
2. создать standby controlfile
ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'filepath';
3. Скопировать все файлы, относящиеся к данному instance (табличные пространства, redo, pfile и/или spfile, orapw), на место, где будет расположен будущий standby instance.
4. Заменить все controlfile в standby instance на созданный standby controlfile (т.е. скопировать его в N мест и переименовать, как указано в параметре control_files).
5. Если не был скопирован spfile, создать его из pfile, не стартуя instance:
$ ORACLE_SID=....
$ sqlplus "/ as sysdba"
CREATE SPFILE FROM PFILE = 'filepath';
6. Запустить standby instance в режиме MOUNT:
STARTUP MOUNT;
7. Запустить primary instance в режиме READ-WRITE:
STARTUP;
или, если база уже была подмонтирована,
ALTER DATABASE OPEN;
8. Настроить механизм периодического копирования archivelogs primary instance в директорию standby instance, определенную параметром log_archive_dest_1. После завершения копирования подключиться к standby instance и выполнить следующие команды:
ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE UNTIL CANCEL;
ALTER DATABASE RECOVER CANCEL;
Для получения самых свежих изменений, перед копированием archivelogs следует принудительно переключить redolog на primary instance:
ALTER SYSTEM SWITCH LOGFILE;
Для того, чтобы переключение redo-логов и сброс archive-логов происходило максимально быстро, был выбран минимальный размер файла для redo-логов и достаточное их количество (я сделал 10 штук). Это и переключение приводит к созданию огромного количества archive-логов. При еженедельном бекапе мне приходится удалять многие тысячи этих файлов.
Сам процесс у нас полностью автоматизирован с использованием cron и shell-скриптов. Копирование логов и управление standby базой осуществляется через ssh. Рекомендую для авторизации использовать RSA ключи.
Самих скриптов не выкладываю. В них, собственно, ничего сложного нет: нужно лишь предусмотреть сохранение номера последнего скопированного archive-лога и блокировку для запрета копирования и применения archivelogs на время проведения работ с остановленным primary или standby instance и выполнения горячего бекапа.
Скрипт у нас запускается каждые пять минут. Это означает, что, в случае падения primary сервера, возможна потеря данных не более чем за последние пять минут работы - остальные archive-логи уже скопированы.
Переключение standby instance в режим read only.
В сравнении с Data Guard у описанной схемы есть еще один недостаток - нельзя выполнять запросы к standby серверу для снижения нагрузки на primary - ведь база закрыта. Да, пользователям это будет недоступно, но администратор может временно перевести standby instance в режим read only:
1. подключиться к standby instance и выполнить следующую команду:
ALTER DATABASE OPEN;
В этом режиме подкачка изменений из archivelogs невозможна!
2. чтобы вернуться в закрытый режим, нужно выполнить следующую команду:
ALTER DATABASE CLOSE;
Отключать на это время механизм переноса archive-логов не обязательно, т.к. необработанные archive-логи будут подкачаны системой позже.
Перевод standby instance в режим primary instance.
Если же все-таки наступит этот черный день, и primary сервер станет неработоспособным, то вам нужно будет выполнить следующие манипуляции над standby:
1. подключиться к standby instance и выполнить следующую команду:
ALTER DATABASE ACTIVATE STANDBY DATABASE;
После этого возврат в режим standby невозможен - теперь это активная база!
2. открыть instance в режиме read-write:
ALTER DATABASE OPEN;
Чтобы пользователи смогли обнаружить новый сервер, следует адресовать его по доменному имени, но не по IP: после смены IP в соответствующей записи на DNS-сервере и полного отключения primary сервера (по питанию или из локальной сети) клиентское ПО будет обращаться уже к новому серверу. Рекомендую не прописывать IP сервера в hosts на клиентских машинах.
Перед внедрением системы мы провели испытание с переключением и DNS. Эксперимент показал, что на все про все, включая перезагрузку клиентского ПО, которое не умеет восстанавливать разорванное подкючение к базе, нужно не больше 5 минут.
О недостатках.
Два недостатка я уже описал выше - возможная потеря последних изменений (в нашем случае - максимум за последние пять минут) и невозможность работы пользователей со standby instance в режиме READ ONLY.
Я нашел еще один изъян: нельзя изменять размеры табличных пространств standby instance. Нужно определять размеры с запасом и разрешать дальнейший рост файлов.
Information
- Posted on 01.02.2010 00:46
- Просмотры: 4455