Реализация резервирования сервера базы данных малой кровью на примере Oracle Standard Edition.Публикуется с разрешения автора. Источник: Клуб программистов "Весельчак У". Содержание
Лирическое вступление.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; 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; 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. Нужно определять размеры с запасом и разрешать дальнейший рост файлов. Если у вас есть что сказать по поводу написанного или что-то осталось непонятным, пишите на наш форум в раздел баз данных: http://forum.shelek.ru/index.php/board,40.0.html. Чернышов Роман (RXL) 24.03.2006.
|