Организация Архитектуры Master-Standby в Oracle: Пошаговая инструкция настройки Oracle Data Guard
Ожидает приглашения
Являясь постоянным хабрачитателем, давно задумывался над тем, что тема Oracle на Хабре по меньшей мере недостаточно раскрыта. А поскольку тема эта мягко говоря, необьятна :), в качестве «затравки» решил взять достаточно животрепещащую тему — настройку и организацию бесперебойной работы СУБД с помощью архитектуры master-standby.
Или как она называется Oracle Data Guard. Соответственно, недолго раздумывая, статью решил оформить в виде пошаговой инструкции с комментариями и по возможности указанием разных «скользких мест».
Связка master-standby технологически организует решение, когда сохранность данных и функционирования сервиса в целом достигается решением из двух физических серверов, один из которых является основным, а второй резервный, готовый продолжить обслуживание.
Случаи, когда подобное решение оправдано:
Минусы данного решения:
Итак, начнем…
Итак, пусть у нас имеются два сервера. К примеру, внутренние IP-адреса 192.168.8.21 (уже работающий сервер с основной базой данных) и 192.168.8.22 (standby-сервер, который мы будем сейчас настраивать). Пусть к примеру ORACLE_SID основной базы будет master
Ставим на standby-сервер Oracle Database той же версии (например, если вы на основном пропатчили серевер с 10.2.0.1 на 10.2.0.4, то на стендбае тоже нужно это сделать) и архитектуры (если у вас основная база x86_64 то стендбай тоже желательно делать x86_64) что и на основной, как говориться во избежание.
Создаем на стендбай сервере необходимые для подъема и работы стендбай-инстанса директории (на стендбай-сервере):
$ mkdir -p /opt/oracle/oradata/STANDBY/datafile
$ mkdir -p /opt/oracle/oradata/STANDBY/onlinelog
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/onlinelog
$ mkdir -p /opt/oracle/oradata/STANDBY/controlfile
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/controlfile
$ mkdir -p /opt/oracle/admin/SANTDBY/{adump,bdump,cdump,udump}
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/autobackup
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/archivelog
$ vi $ORACLE_HOME/network/admin/tnsnames.ora
добавляем следующие строчки на обоих машинах:
MASTER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.8.21)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=master)))
STANDBY=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.8.22)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standby)))
на обоих серверах рестартуем listener:
$ lsnrctl stop
$ lsnrctl start
и пробуем tnsping:
$ tnsping master
$ tnsping standby
Смотрим сколько онлайн-логов и добавляем делаем столько же такого же размера стендбай-логов такого же размера:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> SELECT * FROM v$log;
SQL> SELECT * FROM v$standby_log;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 SIZE 50M;
Включаем force logging (это очень важно, чтобы в архивные логи попадала такая информация которая обычно не включается, но необходима для применения данных на стендбай):
SQL> ALTER DATABASE FORCE LOGGING;
Заставляем сервер переключить логи.
SQL> ALTER SYSTEM switch logfile;
Смотрим, начали ли писаться ли архивлоги:
$ ls -l $ORACLE_BASE/flash_recovery_area/MASTER/archivelog/
Получаем файл параметров, содержащий текущие настройки инстанса:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> create pfile='/opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora' from spfile;
где /opt/oracle/product/10.2/db_1 — ваш $ORACLE_HOME
Правим полученный файл:
$ vi /opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora
В нем прописываем следующие строки:
Пояснение насчет того, что означает каждый параметр:
строки db_name=master и db_unique_name=master — прописываем явно, так как это будет важно при подъеме стендбая. так как у мастера и стендбая одинаковые db_name но разные db_unique_name
LOG_ARCHIVE_CONFIG='DG_CONFIG=(master,standby)' — включаем Oracle Data Guard.
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=master' первое местоположение архивных логов. указываем, что архивлоги необходимо класть как обычно, то только явно указываем что это инстанс master (так будет нужно)
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' — вот тут и начинается «уличная магия»: Мы добавляем второе местоположение- отправлять архивлоги на сервер standby! При этом указанны параметры местоположения, асинхронный режим ASYNC чтобы он основная база не висла а LGWR то, что данный параметр относиться к процессам LGWR.
Тут есть где поиграться с параметрами, например указав VERIFY для проверки, или например параметр REOPEN=сек указывающий через сколько времени он возобновит попытку приконнектиться, если стендбай недоступен.
LOG_ARCHIVE_DEST_STATE_1=ENABLE и LOG_ARCHIVE_DEST_STATE_2=ENABLE — включаем запись в оба местоположения.
Тут внимательный читатель может задать вопрос, а можно ли например указать еще LOG_ARCHIVE_DEST_3='SERVICE=standby2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby2' и LOG_ARCHIVE_DEST_STATE_3=ENABLE и отправлять архивлоги еще на один стандбай? И ответ будет да! Именно так можно к одному основному сразу несколько стендбай серверов!
LOG_ARCHIVE_MAX_PROCESSES=5 — увеличиваем количество процессов LGWR. влияет на производительность даже 10-15 должно хватить, слишком много тоже плохо, все равно это через сеть идет.
remote_login_passwordfile='EXCLUSIVE' Важная штука Мастер со стендбаем к друг другу под SYSом ходят, поэтому сисовые пароли д.б. одинаковые
FAL_SERVER=standby,FAL_CLIENT=master Еще один параметр Data Guard, мы указываем, основнай база (инстанс master) будет устанавливать соединение к стендбай-инстансу (standby) чтобы залить туда архивлоги
STANDBY_FILE_MANAGEMENT=AUTO — указываем на авто
А вот дальше начинается снова «уличная магия» Oracle:
DB_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/datafile','/opt/oracle/oradata/MASTER/datafile' параметр делает самое интерестное — конвертацию имен файлов базы данных (данные табличных пространств). т.е. говорит, что все пути фалов /opt/oracle/oradata/MASTER/datafile/* на стендбае превратятся в /opt/oracle/oradata/STANDBY/datafile/*
LOG_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/onlinelog','/opt/oracle/oradata/MASTER/onlinelog','/opt/oracle/flash_recovery_area/STANDBY/onlinelog','/opt/oracle/flash_recovery_area/MASTER/onlinelog' параметр указывает как будут конвертиться olnine логи.
Остальные же параметры трогать не желательно, как бы вам этого не хотелось. Я знаю в такие моменты существует очень сильный соблазн «о… я счас правлю файл параметров, я могу заодно проверить что будет если я изменю вот этот параметр, и еще вот тот, а потом еще тут кое-что пропишу....». Так вот с таким соблазном лучше бороться, и вот почему. Если после изменений база будет работать некорректно, вы не всегда сразу сможете определить из-за чего конкретно это может происходить: из-за настроек для мастер-стендбай или из-за тех параметров которых вам вдруг захотелось попробовать изменить.
$ ORACLE_SID=master sqlplus / as sysdba
Гасим базу
SQL> shutdown immediate;
заставляем базу стартануть (в режиме nomount, т.е. не монтируя базу) с нашим, только что исправленным файле параметров, если вы допустили грубую ошибку в файле параметров в увидите ругань:
SQL> startup nomount pfile='/opt/oracle/product/10.2/db_1/dbs/pfileBILLING.ora';
Создаем spfile из нашего файла параметров.
SQL> create spfile from pfile='/opt/oracle/product/10.2/db_1/dbs/pfileBILLING.ora';
гасим инстанс и уже с нашим новым созданным spfile''ом стартуем:
SQL> shutdown immediate;
SQL> startup;
Если база завелась — идем смотреть alert log. В логах ругань должна быть только про то, что он пытаясь записать в LOG_ARCHIVE_DEST_2 он не может подсоединиться к инстансу standby и все такое. это нормально, так как сейчас пока нету стендбая.
Однако, поскольку у нас указывался/менялся параметр LOG_ARCHIVE_DEST_1, необходимо проверить что наши архивлоги по прежднему нормально продолжают писаться. Для этого делаем пару-тройку раз комманду:
SQL> alter system switch logfile;
сразу же после выполнения этой комманды, в директории с архивлогами должно соответственно возникнуть пара-тройка новых архивлогов. И соответственно таким образом проверить, что архивлоги нормально пишуться.
$ cp /opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
и правим файл параметров для стендбая
$ vi /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
и указываем следующие параметры:
Комментарии насчет параметров:
Самая основная фишка в том что у мастер-сервера и стендбай-сервера одинаковые имена базы данных db_name=master, но разные имена инстансов базы данных db_unique_name — у мастер-сервера он db_unique_name=master, т.е. совпадает с db_name а у стендбая он db_unique_name=standby
Интерестна семантика параметров LOG_ARCHIVE_DEST_1 (фактически задает куда складывать полученные архивлоги), а LOG_ARCHIVE_DEST_2 задает ему откуда их запросить, если их не хватает, что бывает например когда стендбай-сервер временно выключали.
Параметры FAL_SERVER=master и FAL_CLIENT=standby указывают что если архивлогов не хватает, наш инстанс standby должен соединиться с master и их оттуда запросить.
Параметры DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT точно также как и конфиге основного сервера, задают как конвертировать пути к файлам. Обратите внимание на порядок указания путей. у мастера и стендбай-сервера они разные. Да и вообще, с путями аккуратно.
параметры
*.audit_file_dest='/opt/oracle/admin/STANDBY/adump', *.background_dump_dest='/opt/oracle/admin/STANDBY/bdump',
*.core_dump_dest='/opt/oracle/admin/STANDBY/cdump',
*.user_dump_dest='/opt/oracle/admin/STANDBY/udump'
указывают куда писать всякие трейсы и прочую отладочно-дебажную инфу.
важный параметр control_files='/opt/oracle/oradata/STANDBY/controlfile/STANDBY.ctl','/opt/oracle/flash_recovery_area/STANDBY/controlfile/STANDBY.ctl' указывает места где у нас будет располагаться control-файл.
Гасим наш мастер-инстанс:
$ ORACLE_HOME=master sqlplus / as sysdba
SQL> shutdown immediate;
Производим холодное копирование нашей базы данных:
Собственно, зачастую это и является самым длительным этапом создания архитектуры master-standby. Однако есть способ избежать столь длительного downtime, сделав такую операцию на горячую. Этот способ сложнее и требует определенной сноровки, и о нем я наверное лучше расскажу в следующей своей статье.
Итак, база скопировалась и остался только один недостающий элемент-контрол-файл для стендбай-инстанса. И этот контрол-файл для стендбая создается не где- нибудь, а на основном инстансе.
$ORACLE_SID=master sqlplus / as sysdba
Стартуем инстанс и монтируем базу:
SQL> startup mount;
Создаем контрол-файл для стендбая:
SQL> alter database create standby controlfile as '/opt/oracle/oradata/STANDBY.ctl';
Открываем базу для работы с пользователями:
SQL> alter database open;
Все, с основной базой можно спокойно продолжать работать.
Еще раз смотрим alter_log — если все нормально, то там ругань будет только про то что архивлоги невозможно отправить на стендбай.
Копируем полученый контрол-файл на стендбай:
Копируем созданный файл параметров для стендбая:
$ scp /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora oracle@192.168.8.22:/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
Копируем созданный файл с паролями (это очень важный момент, мастер и стендбай ходят к друг другу по sysом):
$ scp /opt/oracle/product/10.2.0.1/db_1/dbs/orapwmaster oracle@192.168.8.22:/opt/oracle/product/10.2.0.1/db_1/dbs/orapwstandby
Идем на стендбай. Примечание: желательно в коммандной строке указывать ORACLE_SID=standby sqlplus / as sysdba это позволит избежать путаницы, если на данном сервере уже имеются инстансы.
$ ORACLE_SID=standby sqlplus / as sysdba
Стартуем с нашим файлов параметров:
SQL> startup nomount pfile='/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora';
Если старт произведен успешно, создаем spfile из нашего файла параметров:
SQL> create spfile from pfile='/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora';
Рестартуем базу с нашим параметрами в созданном spfile:
SQL> shutdown immediate;
SQL> startup mount;
Итак, стендбай инстанс создался. Смотрим в alert.log. Особой ругани там быть не должно.
А Теперь самое главное: Включаем стендбай-инстанс в режим восстановления:
SQL> alter database recover managed standby database disconnect from session;
Именно так и происходит: основной сервер все изменения записывает в архивлоги, архивлоги посылаются на стендбай-сервер, которые находясь в режиме восстановления применяют к файлам базы данных эти изменения.
Вот тут как раз и нужно все проверить, что никаких ошибок нет.
Делаем на основной базе пару-тройку раз
$ ORACLE_SID=master sqlplus / as sysdba
SQL> alter system switch logfile;
На локальной машине эти фалы с архивлогами должны появиться сразу же после выполнения этой комманды.
Если все идет нормально буквально в течении минуты архивлоги с такими же
сиквенсами должны появиться на стендбай-базе. Примечание: проверить есть ли в данный момент соединение мастер-сервера со стендбай сервером можно с помощью комманды netstat.
Сейчас стендбай-база будет заниматься тем, что вытягивать архивлоги содержащие изменения, произошедшие с момента создания начального образа.
Обычно, догнать она по логам должна быстро.
За этим процессом отправки архивлогов и их применения рекомендуется последить следующим образом:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> select sequence#, applied from v$archived_log order by sequence#;
Если стендбай инстанс применил все архивлоги, которые набежали на основной базе, то можно всех поздравить! Можно спать спокойно!
Когда такая схема настроена вы действительно можете спать спокойно! Даже при полном внезапной физическом уничтожении сервера максимум данных которые можно потерять это содержимое одного архивлога который не успел еще оптравиться на стендбай. В случае же нормального выключения сервера вы не потеряете ничего… ничего кроме… того, что к самой базе данных напрямую не относиться. Т.е. если в Вашей работе активно используются такие вещи как внешние таблицы, файлы и пр. подобные вещи, вы должны сами позаботиться о том, чтобы они были скопированны на стендбай-сервер если они для вас представляют реальную ценность. Хорошо зарекомендовавшее себя решение данного вопроса: прописав ssh-ключи на обоих серверах и использовать внешние jobы для копирования необходимых файлов по scp.
Примечание: конвертацию имен файлов (параметры DB_FILE_NAME_CONVERT,LOG_FILE_NAME_CONVERT) можно не делать. Тогда на мастере и на стендбае пути обязаны быть одинаковыми, что соответственно неудобно так как накладывает слишком жесткое ограничение.
Итак, стендбай мы создали. Как с ним работать? Очень просто.
Погасить стендбай-инстанс:
$ ORACLE_SID=standby sqlplus / as sysdba
Старт стендбай-инстанса (стартуя инстанс мы не только стартуаем базу данных но и заставляем ее перейти в режим восстановления):
$ ORACLE_SID=standby sqlplus / as sysdba
Одна из прикольных «фишек» мастер-стендбай архитектуры — возможность перевести стендбай в readonly-режим, получив мгновенный слепок основной базы. Иногда это может использоваться например, чтобы выполнить на стендбае (который обычно имеет низкий loadavg в отличии от основного) какой-нибудь очень тяжелый запрос чтобы не грузить основной сервер.
Итак, перевести в режим readonly:
$ ORACLE_SID=standby sqlplus / as sysdba
Снова вернуть в режим быстрого восстановления:
$ ORACLE_SID=stdby sqlplus / as sysdba
SQL> alter database recover managed standby database disconnect from session;
А вот порядок действий «в случае чего»:
$ ORACLE_SID=stdby sqlplus / as sysdba
Выводим из режима восстановления:
SQL> alter database recover managed standby database cancel;
Говорим базе что теперь она основная:
SQL> alter database activate standby database;
Гасим инстанс:
SQL> shutdown immediate;
Рестартуем ее уже как основную базу.
SQL> startup;
Или как она называется Oracle Data Guard. Соответственно, недолго раздумывая, статью решил оформить в виде пошаговой инструкции с комментариями и по возможности указанием разных «скользких мест».
Что это такое и Зачем это все нужно
Связка master-standby технологически организует решение, когда сохранность данных и функционирования сервиса в целом достигается решением из двух физических серверов, один из которых является основным, а второй резервный, готовый продолжить обслуживание.
Случаи, когда подобное решение оправдано:
- СУБД является bussiness-critical участком корпоративной инфраструктуры (другими словами стоимость простоя СУБД сопоставима со стоимостью железа, а стоимость информации и того выше).
- Размер базы данных занимает многие сотни гигабайт а то и терабайт, что соответственно делает полный разворот базы на новом сервере из полного бекапа делом многих часов.
- Важное требование IT-инфраструктуры — обеспечение функционирования даже в случае полного физического выхода из строя основного сервера. т.е. такие неприятныя мелочи как внезапно сгоревший raid-контроллер не должны парализовывать работу.
- Является одним из самых эффективных средств против паранои, нарушения сна и неврозов:)
- Just for fun
Минусы данного решения:
- Основной минус один: необходимость еще одной железки — standby сервера:) Хотя, для «тренировочных нужд» всю нижеуказанную процедуру можно провернуть и на одном физическом сервере.
Итак, начнем…
1. Подготовительные моменты
Итак, пусть у нас имеются два сервера. К примеру, внутренние IP-адреса 192.168.8.21 (уже работающий сервер с основной базой данных) и 192.168.8.22 (standby-сервер, который мы будем сейчас настраивать). Пусть к примеру ORACLE_SID основной базы будет master
Ставим на standby-сервер Oracle Database той же версии (например, если вы на основном пропатчили серевер с 10.2.0.1 на 10.2.0.4, то на стендбае тоже нужно это сделать) и архитектуры (если у вас основная база x86_64 то стендбай тоже желательно делать x86_64) что и на основной, как говориться во избежание.
Создаем на стендбай сервере необходимые для подъема и работы стендбай-инстанса директории (на стендбай-сервере):
$ mkdir -p /opt/oracle/oradata/STANDBY/datafile
$ mkdir -p /opt/oracle/oradata/STANDBY/onlinelog
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/onlinelog
$ mkdir -p /opt/oracle/oradata/STANDBY/controlfile
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/controlfile
$ mkdir -p /opt/oracle/admin/SANTDBY/{adump,bdump,cdump,udump}
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/autobackup
$ mkdir -p /opt/oracle/flash_recovery_area/STANDBY/archivelog
2. Настройка listener'а
$ vi $ORACLE_HOME/network/admin/tnsnames.ora
добавляем следующие строчки на обоих машинах:
MASTER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.8.21)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=master)))
STANDBY=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.8.22)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standby)))
на обоих серверах рестартуем listener:
$ lsnrctl stop
$ lsnrctl start
и пробуем tnsping:
$ tnsping master
$ tnsping standby
3. Настраиваем стендбай-логи и режим force logged
Смотрим сколько онлайн-логов и добавляем делаем столько же такого же размера стендбай-логов такого же размера:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> SELECT * FROM v$log;
SQL> SELECT * FROM v$standby_log;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 SIZE 50M;
Включаем force logging (это очень важно, чтобы в архивные логи попадала такая информация которая обычно не включается, но необходима для применения данных на стендбай):
SQL> ALTER DATABASE FORCE LOGGING;
Заставляем сервер переключить логи.
SQL> ALTER SYSTEM switch logfile;
Смотрим, начали ли писаться ли архивлоги:
$ ls -l $ORACLE_BASE/flash_recovery_area/MASTER/archivelog/
4. Правим файл параметров
Получаем файл параметров, содержащий текущие настройки инстанса:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> create pfile='/opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora' from spfile;
где /opt/oracle/product/10.2/db_1 — ваш $ORACLE_HOME
Правим полученный файл:
$ vi /opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora
В нем прописываем следующие строки:
db_name=master
db_unique_name=master
LOG_ARCHIVE_CONFIG='DG_CONFIG=(master,standby)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=master'
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=20
remote_login_passwordfile='EXCLUSIVE'
FAL_SERVER=standby
FAL_CLIENT=master
STANDBY_FILE_MANAGEMENT=AUTO
DB_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/datafile','/opt/oracle/oradata/MASTER/datafile'
LOG_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/onlinelog','/opt/oracle/oradata/MASTER/onlinelog','/opt/oracle/flash_recovery_area/STANDBY/onlinelog','/opt/oracle/flash_recovery_area/MASTER/onlinelog'
Пояснение насчет того, что означает каждый параметр:
строки db_name=master и db_unique_name=master — прописываем явно, так как это будет важно при подъеме стендбая. так как у мастера и стендбая одинаковые db_name но разные db_unique_name
LOG_ARCHIVE_CONFIG='DG_CONFIG=(master,standby)' — включаем Oracle Data Guard.
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=master' первое местоположение архивных логов. указываем, что архивлоги необходимо класть как обычно, то только явно указываем что это инстанс master (так будет нужно)
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' — вот тут и начинается «уличная магия»: Мы добавляем второе местоположение- отправлять архивлоги на сервер standby! При этом указанны параметры местоположения, асинхронный режим ASYNC чтобы он основная база не висла а LGWR то, что данный параметр относиться к процессам LGWR.
Тут есть где поиграться с параметрами, например указав VERIFY для проверки, или например параметр REOPEN=сек указывающий через сколько времени он возобновит попытку приконнектиться, если стендбай недоступен.
LOG_ARCHIVE_DEST_STATE_1=ENABLE и LOG_ARCHIVE_DEST_STATE_2=ENABLE — включаем запись в оба местоположения.
Тут внимательный читатель может задать вопрос, а можно ли например указать еще LOG_ARCHIVE_DEST_3='SERVICE=standby2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby2' и LOG_ARCHIVE_DEST_STATE_3=ENABLE и отправлять архивлоги еще на один стандбай? И ответ будет да! Именно так можно к одному основному сразу несколько стендбай серверов!
LOG_ARCHIVE_MAX_PROCESSES=5 — увеличиваем количество процессов LGWR. влияет на производительность даже 10-15 должно хватить, слишком много тоже плохо, все равно это через сеть идет.
remote_login_passwordfile='EXCLUSIVE' Важная штука Мастер со стендбаем к друг другу под SYSом ходят, поэтому сисовые пароли д.б. одинаковые
FAL_SERVER=standby,FAL_CLIENT=master Еще один параметр Data Guard, мы указываем, основнай база (инстанс master) будет устанавливать соединение к стендбай-инстансу (standby) чтобы залить туда архивлоги
STANDBY_FILE_MANAGEMENT=AUTO — указываем на авто
А вот дальше начинается снова «уличная магия» Oracle:
DB_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/datafile','/opt/oracle/oradata/MASTER/datafile' параметр делает самое интерестное — конвертацию имен файлов базы данных (данные табличных пространств). т.е. говорит, что все пути фалов /opt/oracle/oradata/MASTER/datafile/* на стендбае превратятся в /opt/oracle/oradata/STANDBY/datafile/*
LOG_FILE_NAME_CONVERT='/opt/oracle/oradata/STANDBY/onlinelog','/opt/oracle/oradata/MASTER/onlinelog','/opt/oracle/flash_recovery_area/STANDBY/onlinelog','/opt/oracle/flash_recovery_area/MASTER/onlinelog' параметр указывает как будут конвертиться olnine логи.
Остальные же параметры трогать не желательно, как бы вам этого не хотелось. Я знаю в такие моменты существует очень сильный соблазн «о… я счас правлю файл параметров, я могу заодно проверить что будет если я изменю вот этот параметр, и еще вот тот, а потом еще тут кое-что пропишу....». Так вот с таким соблазном лучше бороться, и вот почему. Если после изменений база будет работать некорректно, вы не всегда сразу сможете определить из-за чего конкретно это может происходить: из-за настроек для мастер-стендбай или из-за тех параметров которых вам вдруг захотелось попробовать изменить.
5. Рестартуем нашу базу с новыми параметрами Data Guard
$ ORACLE_SID=master sqlplus / as sysdba
Гасим базу
SQL> shutdown immediate;
заставляем базу стартануть (в режиме nomount, т.е. не монтируя базу) с нашим, только что исправленным файле параметров, если вы допустили грубую ошибку в файле параметров в увидите ругань:
SQL> startup nomount pfile='/opt/oracle/product/10.2/db_1/dbs/pfileBILLING.ora';
Создаем spfile из нашего файла параметров.
SQL> create spfile from pfile='/opt/oracle/product/10.2/db_1/dbs/pfileBILLING.ora';
гасим инстанс и уже с нашим новым созданным spfile''ом стартуем:
SQL> shutdown immediate;
SQL> startup;
Если база завелась — идем смотреть alert log. В логах ругань должна быть только про то, что он пытаясь записать в LOG_ARCHIVE_DEST_2 он не может подсоединиться к инстансу standby и все такое. это нормально, так как сейчас пока нету стендбая.
Однако, поскольку у нас указывался/менялся параметр LOG_ARCHIVE_DEST_1, необходимо проверить что наши архивлоги по прежднему нормально продолжают писаться. Для этого делаем пару-тройку раз комманду:
SQL> alter system switch logfile;
сразу же после выполнения этой комманды, в директории с архивлогами должно соответственно возникнуть пара-тройка новых архивлогов. И соответственно таким образом проверить, что архивлоги нормально пишуться.
6. Делаем файл параметров для стендбай-сервера
$ cp /opt/oracle/product/10.2/db_1/dbs/pfileMASTER.ora /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
и правим файл параметров для стендбая
$ vi /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
и указываем следующие параметры:
*.audit_file_dest='/opt/oracle/admin/STANDBY/adump'
*.background_dump_dest='/opt/oracle/admin/STANDBY/bdump'
*.core_dump_dest='/opt/oracle/admin/STANDBY/cdump'
*.user_dump_dest='/opt/oracle/admin/STANDBY/udump'
control_files='/opt/oracle/oradata/STANDBY/controlfile/STANDBY.ctl','/opt/oracle/flash_recovery_area/STANDBY/controlfile/STANDBY.ctl'
db_name=master
db_unique_name=standby
LOG_ARCHIVE_CONFIG='DG_CONFIG=(master,standby)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=standby'
LOG_ARCHIVE_DEST_2='SERVICE=master LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=master'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MAX_PROCESSES=5
FAL_SERVER=master
FAL_CLIENT=standby
remote_login_passwordfile='EXCLUSIVE'
DB_FILE_NAME_CONVERT='/opt/oracle/oradata/MASTER/datafile','/opt/oracle/oradata/STANDBY/datafile'
LOG_FILE_NAME_CONVERT='/opt/oracle/oradata/MASTER/onlinelog','/opt/oracle/oradata/STANDBY/onlinelog','/opt/oracle/flash_recovery_area/MASTER
/onlinelog','/opt/oracle/flash_recovery_area/STANDBY/onlinelog'
STANDBY_FILE_MANAGEMENT=AUTOКомментарии насчет параметров:
Самая основная фишка в том что у мастер-сервера и стендбай-сервера одинаковые имена базы данных db_name=master, но разные имена инстансов базы данных db_unique_name — у мастер-сервера он db_unique_name=master, т.е. совпадает с db_name а у стендбая он db_unique_name=standby
Интерестна семантика параметров LOG_ARCHIVE_DEST_1 (фактически задает куда складывать полученные архивлоги), а LOG_ARCHIVE_DEST_2 задает ему откуда их запросить, если их не хватает, что бывает например когда стендбай-сервер временно выключали.
Параметры FAL_SERVER=master и FAL_CLIENT=standby указывают что если архивлогов не хватает, наш инстанс standby должен соединиться с master и их оттуда запросить.
Параметры DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT точно также как и конфиге основного сервера, задают как конвертировать пути к файлам. Обратите внимание на порядок указания путей. у мастера и стендбай-сервера они разные. Да и вообще, с путями аккуратно.
параметры
*.audit_file_dest='/opt/oracle/admin/STANDBY/adump', *.background_dump_dest='/opt/oracle/admin/STANDBY/bdump',
*.core_dump_dest='/opt/oracle/admin/STANDBY/cdump',
*.user_dump_dest='/opt/oracle/admin/STANDBY/udump'
указывают куда писать всякие трейсы и прочую отладочно-дебажную инфу.
важный параметр control_files='/opt/oracle/oradata/STANDBY/controlfile/STANDBY.ctl','/opt/oracle/flash_recovery_area/STANDBY/controlfile/STANDBY.ctl' указывает места где у нас будет располагаться control-файл.
7. Гасим инстанс и делаем холодную копию на стендбай (создаем начальный образ базы)
Гасим наш мастер-инстанс:
$ ORACLE_HOME=master sqlplus / as sysdba
SQL> shutdown immediate;
Производим холодное копирование нашей базы данных:
$ scp /opt/oracle/oradata/MASTER/datafile/* oracle@192.168.8.22:/opt/oracle/oradata/STDBY/datafile
$ scp /opt/oracle/oradata/MASTER/onlinelog/* oracle@192.168.8.22:/opt/oracle/oradata/STDBY/onlinelog
$ scp /opt/oracle/flash_recovery_area/MASTER/onlinelog/ * oracle@192.168.8.22:/opt/oracle/flash_recovery_area/STDBY/onlinelog
Собственно, зачастую это и является самым длительным этапом создания архитектуры master-standby. Однако есть способ избежать столь длительного downtime, сделав такую операцию на горячую. Этот способ сложнее и требует определенной сноровки, и о нем я наверное лучше расскажу в следующей своей статье.
8. Создаем контрол-файл для стендбая
Итак, база скопировалась и остался только один недостающий элемент-контрол-файл для стендбай-инстанса. И этот контрол-файл для стендбая создается не где- нибудь, а на основном инстансе.
$ORACLE_SID=master sqlplus / as sysdba
Стартуем инстанс и монтируем базу:
SQL> startup mount;
Создаем контрол-файл для стендбая:
SQL> alter database create standby controlfile as '/opt/oracle/oradata/STANDBY.ctl';
Открываем базу для работы с пользователями:
SQL> alter database open;
Все, с основной базой можно спокойно продолжать работать.
Еще раз смотрим alter_log — если все нормально, то там ругань будет только про то что архивлоги невозможно отправить на стендбай.
9. Подготовка к старту стендбая
Копируем полученый контрол-файл на стендбай:
$ scp /opt/oracle/oradata/STANDBY.ctl oracle@192.168.8.22:/opt/oracle/oradata/STDBY/controlfile/STANDBY.ctl
$ scp /opt/oracle/oradata/STANDBY.ctl oracle@192.168.8.22:/opt/oracle/flash_recovery_area/STDBY/controlfile/STANDBY.ctl
Копируем созданный файл параметров для стендбая:
$ scp /opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora oracle@192.168.8.22:/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora
Копируем созданный файл с паролями (это очень важный момент, мастер и стендбай ходят к друг другу по sysом):
$ scp /opt/oracle/product/10.2.0.1/db_1/dbs/orapwmaster oracle@192.168.8.22:/opt/oracle/product/10.2.0.1/db_1/dbs/orapwstandby
10. Поднимаем стендбай
Идем на стендбай. Примечание: желательно в коммандной строке указывать ORACLE_SID=standby sqlplus / as sysdba это позволит избежать путаницы, если на данном сервере уже имеются инстансы.
$ ORACLE_SID=standby sqlplus / as sysdba
Стартуем с нашим файлов параметров:
SQL> startup nomount pfile='/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora';
Если старт произведен успешно, создаем spfile из нашего файла параметров:
SQL> create spfile from pfile='/opt/oracle/product/10.2/db_1/dbs/pfileSTANDBY.ora';
Рестартуем базу с нашим параметрами в созданном spfile:
SQL> shutdown immediate;
SQL> startup mount;
Итак, стендбай инстанс создался. Смотрим в alert.log. Особой ругани там быть не должно.
А Теперь самое главное: Включаем стендбай-инстанс в режим восстановления:
SQL> alter database recover managed standby database disconnect from session;
Именно так и происходит: основной сервер все изменения записывает в архивлоги, архивлоги посылаются на стендбай-сервер, которые находясь в режиме восстановления применяют к файлам базы данных эти изменения.
Вот тут как раз и нужно все проверить, что никаких ошибок нет.
11. Проверяем что все идет по плану
Делаем на основной базе пару-тройку раз
$ ORACLE_SID=master sqlplus / as sysdba
SQL> alter system switch logfile;
На локальной машине эти фалы с архивлогами должны появиться сразу же после выполнения этой комманды.
Если все идет нормально буквально в течении минуты архивлоги с такими же
сиквенсами должны появиться на стендбай-базе. Примечание: проверить есть ли в данный момент соединение мастер-сервера со стендбай сервером можно с помощью комманды netstat.
Сейчас стендбай-база будет заниматься тем, что вытягивать архивлоги содержащие изменения, произошедшие с момента создания начального образа.
Обычно, догнать она по логам должна быстро.
За этим процессом отправки архивлогов и их применения рекомендуется последить следующим образом:
$ ORACLE_SID=master sqlplus / as sysdba
SQL> select sequence#, applied from v$archived_log order by sequence#;
Если стендбай инстанс применил все архивлоги, которые набежали на основной базе, то можно всех поздравить! Можно спать спокойно!
12. Неочевидные моменты в архитектуре master-standby
Когда такая схема настроена вы действительно можете спать спокойно! Даже при полном внезапной физическом уничтожении сервера максимум данных которые можно потерять это содержимое одного архивлога который не успел еще оптравиться на стендбай. В случае же нормального выключения сервера вы не потеряете ничего… ничего кроме… того, что к самой базе данных напрямую не относиться. Т.е. если в Вашей работе активно используются такие вещи как внешние таблицы, файлы и пр. подобные вещи, вы должны сами позаботиться о том, чтобы они были скопированны на стендбай-сервер если они для вас представляют реальную ценность. Хорошо зарекомендовавшее себя решение данного вопроса: прописав ssh-ключи на обоих серверах и использовать внешние jobы для копирования необходимых файлов по scp.
Примечание: конвертацию имен файлов (параметры DB_FILE_NAME_CONVERT,LOG_FILE_NAME_CONVERT) можно не делать. Тогда на мастере и на стендбае пути обязаны быть одинаковыми, что соответственно неудобно так как накладывает слишком жесткое ограничение.
13. Работа со стендбаем
Итак, стендбай мы создали. Как с ним работать? Очень просто.
Погасить стендбай-инстанс:
$ ORACLE_SID=standby sqlplus / as sysdba
SQL> alter database recover managed standby database cancel;
SQL> shutdown immediate;
Старт стендбай-инстанса (стартуя инстанс мы не только стартуаем базу данных но и заставляем ее перейти в режим восстановления):
$ ORACLE_SID=standby sqlplus / as sysdba
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database recover managed standby database disconnect from session;
Одна из прикольных «фишек» мастер-стендбай архитектуры — возможность перевести стендбай в readonly-режим, получив мгновенный слепок основной базы. Иногда это может использоваться например, чтобы выполнить на стендбае (который обычно имеет низкий loadavg в отличии от основного) какой-нибудь очень тяжелый запрос чтобы не грузить основной сервер.
Итак, перевести в режим readonly:
$ ORACLE_SID=standby sqlplus / as sysdba
SQL> alter database recover managed standby database cancel;
SQL> alter database open read only;
Снова вернуть в режим быстрого восстановления:
$ ORACLE_SID=stdby sqlplus / as sysdba
SQL> alter database recover managed standby database disconnect from session;
А вот порядок действий «в случае чего»:
$ ORACLE_SID=stdby sqlplus / as sysdba
Выводим из режима восстановления:
SQL> alter database recover managed standby database cancel;
Говорим базе что теперь она основная:
SQL> alter database activate standby database;
Гасим инстанс:
SQL> shutdown immediate;
Рестартуем ее уже как основную базу.
SQL> startup;