Построение отказоустойчивой системы с помощью Oracle Physical Standby

Сергей Косько

Построение отказоустойчивой системы с помощью Oracle Physical Standby

Развернув информационную систему на базе СУБД Oracle и организовав надёжную стратегию резервного копирования-восстановления, можно приступать к производственной эксплуатации системы. В случае аварии возможно будет восстановить данные на требуемый момент времени. Но что делать, если допустимое время простоя не должно превышать нескольких минут? Тогда не обойтись без различных способов дублирования данных в режиме реального времени.

Один из вариантов такой репликации можно реализовать с помощью специальной базы данных Oracle Standby. Её можно применять совместно с обычным резервным копированием. Режим Standby DB обеспечивает опция Data Guard базы данных Oracle. Конфигурация Data Guard состоит из одной производственной и одной или более резервных баз данных standby, которые находятся в особом режиме, предусматривающем непрерывный приём и применение потока изменений от производственной базы. Изменения передаются по универсальной сети между разнесёнными географически серверами средствами Oracle Net [1]. Упрощённую схему взаимодействия смотрите на рисунке.

Структура Oracle Data Guard

В зависимости от конкретных требований по времени восстановления и допустимой потери данных при аварии (recovery time objective, recovery point objective [2]). Возможны различные сценарии реализации:

• Physical standby DB – резервная база данных является точной физической копией основной, находится в монтированном состоянии и при этом переносится поток redo-информации.
• Logical standby DB – резервная база данных не является точной копией основной, открыта в режиме чтения–записи и при этом переносится поток SQL-команд.

Конфигурация Oracle Data Guard может находиться в трёх режимах защиты: максимальной производительности (maximum performance), максимальной доступности (maximum availability) или максимальной защиты (maximum protection) [3]. Изменения передаются копированием журналов базы данных, текущих или архивных. Их запись осуществляется двумя процессами LGWR или ARCn. Процесс LGWR ведёт запись активных журналов, дополнительные настройки вынуждают его передавать изменения на резервный сервер с помощью так называемых standby redo log-файлов. Процесс ARCn переносит обычные архивные журналы, дополнительные настройки вынуждают его передавать их ещё и на удалённый сервер. Если выбраны режимы максимальных доступности или защиты, поток изменений передаётся с помощью данных, записываемых процессом LGWR. В режиме максимальной производительности возможна передача изменений как LGWR, так и ARCn.

В случае необходимости такая база может быть в короткий срок активирована в качестве производственной.

Поскольку БД Logical Standby не является точной копией основной базы и не поддерживает некоторые типы данных, SQL-команды, имеет требования по обеспечению уникальности строк в таблицах [4], рассмотрим реализацию именно Physical Standby DB. Мне кажется, что использовать БД Logical Standby лучше не как резервную копию, а в качестве базы для отчётов. Выберем для работы основной и резервной баз следующие настройки: производственная база работает в режиме maximum availability, переданные изменения применяются резервной базой в режиме Real-Time Apply Redo. Для такого режима работы инициатором передачи информации об изменениях выступает как раз процесс LGWR. Разница между режимами защиты заключается в том, что в режиме maximum protection транзакция фиксируется только тогда, когда запись произведена и в локальные журналы, и удалённо, в случае невозможности удалённой записи база данных останавливается, а в режиме maximum performance для продолжения работы достаточно только локальной записи, и основная БД продолжает свою работу, даже если связь с резервной базой отсутствует.

Режим maximum availability представляет компромиссный вариант, переключаясь между двумя режимами автоматически. Если связь работает без ошибок, передача происходит синхронно, если произошел сбой, автоматически осуществляется переход в менее строгий режим. После устранения сбоев режим максимальной защиты восстанавливается [5].

Что необходимо для создания тестовой среды:

• Два сервера одинаковой архитектуры, они могут отличаться по количеству процессоров, памяти, дисков, релизом операционной системы и т. п. Пусть сервер primary DB будет называться Poltava, а сервер standby – Fastiv.
• Режим базы данных должен быть ARCHIVELOG.
• Необходимо использовать программное обеспечение Oracle Server версии Enterprize Edition. В тестах будем использовать версию Oracle10.2 EE for Solaris.

Подготовка рабочей конфигурации

Итак, у нас имеется работающая производственная (primary) база данных Oracle, расположенная на сервере Poltava, и нам необходимо создать резервную базу standby на сервере Fastiv. Необходимо подготовить конфигурационные файлы и сделать дополнительные настройки.

Пусть имя базы будет «TST», присвоим для производственной primary-базы значение ORACLE_SID=ORCL, для standby – DB ORACLE_SID=ORCL1. Файлы primary DB находятся в каталоге /tstb/ORCL, файлы standby DB – в каталоге /tstb/ORCL1.

Для работы БД standby присваивать различные значения переменной ORACLE_SID для окружения основной и резервной баз данных необходимости нет, но это позволяет сделать так, чтобы файлы двух баз не накладывались друг на друга. Это позволяет перемещать базы между серверами, временно или в тестовых целях совмещать их на одном и том же сервере, имеющем два сетевых адресса (poltava и fastiv).

Необходимо выполнить следующие действия:

Включим режим force logging на производственной системе для принудительной записи в журналы БД информации, даже для так называемых операций Nologging:

SQL>ALTER DATABASE FORCE LOGGING;

Создадим файлы standby redo log. Они нужны только для работы БД standby, но мы создадим их и на primary, и на standby, в случае переключения ролей между базами не будет необходимости в их создании.

Файлы standby redo необходимо создать не меньшего размера, чем online redo log, и в количестве n+1 от количества redo group (cм. листинг 1).

Листинг 1. Добавление файлов Standby Redo

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/tstb/ORCL/redo01.stb' SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 '/tstb/ORCL/redo02.stb'  SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/tstb/ORCL/redo03.stb'  SIZE 100M REUSE;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 '/tstb/ORCL/redo04.stb'  SIZE 100M REUSE;

exit

EOF

Установим параметры в файлах параметров init.ora/spfile.ora для primary и standby (см. листинг 2).

Листинг 2. Список параметров файла init.ora/spfile.ora

*.audit_file_dest='/ora/admin/ORCL/adump'

*.background_dump_dest='/ora/admin/ORCL/bdump'

*.control_files='/tstb/ORCL/control01.ctl', '/tstb/ORCL/control02.ctl', '/tstb/ORCL/control03.ctl'

*.core_dump_dest='/ora/admin/ORCL/cdump'

*.db_name='TST'

*.log_archive_format='log_%t_%s_%r.dbf'

*.remote_login_passwordfile='EXCLUSIVE'

*.STANDBY_FILE_MANAGEMENT=AUTO

*.DB_UNIQUE_NAME=poltava

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(poltava,fastiv)'

*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=poltava'

*.LOG_ARCHIVE_DEST_2='SERVICE=fastiv LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=fastiv'

*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

*.LOG_ARCHIVE_DEST_STATE_2=ENABLE

*.FAL_SERVER=poltava                 

*.FAL_CLIENT=fastiv

*.STANDBY_ARCHIVE_DEST=/tstb/log1/

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

*.audit_file_dest='/ora/admin/ORCL1/adump'

*.background_dump_dest='/ora/admin/ORCL1/bdump'

*.control_files='/tstb/ORCL1/control01.ctl', '/tstb/ORCL1/control02.ctl', '/tstb/ORCL1/control03.ctl'

*.core_dump_dest='/ora/admin/ORCL1/cdump'

*.db_name='TST'

*.log_archive_format='log_%t_%s_%r.dbf'

*.user_dump_dest='/ora/admin/ORCL1/udump'

*.STANDBY_FILE_MANAGEMENT=AUTO

*.DB_UNIQUE_NAME=fastiv

*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(poltava,fastiv)'

*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=fastiv'

*.LOG_ARCHIVE_DEST_2='SERVICE=poltava LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=poltava'

*.LOG_ARCHIVE_DEST_STATE_1=ENABLE

*.LOG_ARCHIVE_DEST_STATE_2=ENABLE

*.FAL_SERVER=poltava

*.FAL_CLIENT=fastiv

*.STANDBY_ARCHIVE_DEST=/tstb/log/

*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

*.DB_FILE_NAME_CONVERT=('/tstb/ORCL','/tstb/ORCL1')

*.LOG_FILE_NAME_CONVERT=('/tstb/ORCL','/tstb/ORCL1')

Настроим Oracle Net для сетевых адресов Poltava и Fastiv.

Пример настроек файлов listener.ora и tnsnames.ora приведены в листинге 3.

Листинг 3. Настройки Oracle Net

# listener.ora Network Configuration File:

# /ora/oracle10/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = 0.0.0.0)(PORT = 1525))

    )

  )

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = TST)

      (ORACLE_HOME = /ora/oracle10)

      (SID_NAME = ORCL)

    )

    (SID_DESC =

      (GLOBAL_DBNAME = TST)

      (ORACLE_HOME = /ora/oracle10)

      (SID_NAME = ORCL1)

    )

  )

# tnsnames.ora Network Configuration File:

# /ora/oracle10/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

Poltava =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = poltava)(PORT = 1525))

    )

    (CONNECT_DATA =

    (SID = ORCL)

    )

  )

Fastiv =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = fastiv)(PORT = 1525))

    )

    (CONNECT_DATA =

    (SID = ORCL1)

    )

  )

Создание резервной БД standby

Создадим резервные копии базы данных и файла паролей и перенесем скопированные файлы на резервный сервер Fastiv.

Поскольку значения ORACLE_SID для основной и резервной баз отличаются, файлы паролей тоже будут иметь разные имена, например, orapwORCL и orapwORCL1.

Создадим standby control file и скопируем его на сервер standby в местоположение, указанное в файле параметров базы данных standby:

SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl';

Переключим основную базу данных в режим maximum availability следующей командой:

SQL>STARTUP MOUNT;

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Базы данных готовы к работе. Теперь обе базы данных можно запускать.

Операции с БД во время работы

Во время работы необходимо выполнять определённые действия – пуск, остановка, открытие для чтения, регистрация пропущенных логов, активация резервной базы (failover), обмен статусом (switchover). Рассмотрим эти операции:

Скрипт stbstart отвечает за старт БД standby в режиме real-time apply. Остановку БД standby обеспечивает скрипт stbshut (см. листинг 4).

Листинг 4. Пуск и остановка БД Physical Standby

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

startup nomount;

alter database mount standby database ;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT FROM SESSION;

exit

EOF

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SHUTDOWN IMMEDIATE;

exit

EOF

Проверим механизм передачи изменений переключением журналов. На primary:

SQL>ALTER SYSTEM SWITCH LOGFILE;

на standby:

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

Скрипт stbreadonly отвечает за запуск БД standby в режиме read-only (см. листинг 5). Доставка Redo в этом случае продолжается, однако изменения будут отложены до выхода из этого режима.

Листинг 5. Запуск БД standby в режиме read-only

#!/bin/sh

#

sqlplus "/ as sysdba" << EOF

spool readonly.log

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

alter database open read only;

exit

EOF

Switchover – скрипт для смены ролей между базами данных. Необходимо, чтобы БД primary была открыта, а standby была в режиме mount или recover (см. листинг 6). Как можно видеть в скрипте, для переключения ролей необходимо иметь доступ к каждой из баз данных, участвующих в операции.

Листинг 6. Обмена ролями между базами Poltava и Fastiv

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

spool switchover.log

REM connect primary

connect sys/manager@poltava as sysdba

column SWITCHOVER_STATUS format A20 heading 'Switchover status|primary'

SELECT SWITCHOVER_STATUS FROM V\$DATABASE;

column DATABASE_ROLE format A20 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

column DATABASE_ROLE format A20 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

REM connect standby db on redo apply mode

connect sys/manager@fastiv as sysdba

column SWITCHOVER_STATUS format A20 heading 'Switchover status|standby'

SELECT SWITCHOVER_STATUS FROM V\$DATABASE;

column DATABASE_ROLE format A20 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

ALTER DATABASE OPEN;

REM if in read only, do not open - restart

REM SHUTDOWN IMMEDIATE;

REM STARTUP;

column DATABASE_ROLE format A20 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

exit

EOF

Failover – cкрипт, активирующий резервную базу в случае аварии на базе primary. Поскольку резервной базы больше нет, перед активацией резервной базы её следует перевести в режим maximum performance (см. листинг 7).

SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

Регистрация пропущенных логов наглядно показана в листинге 8.

Листинг 7. Активация резервной базы данных в случае аварии

#!/bin/sh

#

sqlplus "/ as sysdba" <<EOF

spool failover.log

column DATABASE_ROLE format A15 heading 'Role before|switchover'

select DATABASE_ROLE from  V\$DATABASE;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

ALTER DATABASE OPEN;

column DATABASE_ROLE format A15 heading 'Role after|switchover'

select DATABASE_ROLE from  V\$DATABASE;

exit

EOF

Листинг 8. Определение и разрешение вручную пропусков передачи журналов

Автоматизация мониторинга работы

Поскольку БД primary находится в режиме maximum availability, то в случае остановки резервного сервера основная БД продолжит свою работу. Между состоянием primary и standby образуется разрыв. Для обнаружения и устранения поломки потребуется время, в течение которого основная база данных не резервируется. В этот момент, в случае повторной аварии уже на основной базе данных, возможна потеря данных. Чтобы своевременно обнаруживать и устранять подобные ситуации, необходимо автоматизировать процесс наблюдения за работой обеих БД.

Листинг 9. Скрипт, выполняющий поиск ошибок в файле alert.log

#!/bin/sh

#

if [ -f /tmp/memsg_no ]

    then exit ;

fi

HOST=`/bin/hostname`

MYMAIL="sergkosko@ua.fm"

FILESLIST=`ls -R /ora/admin/*/bdump/*.log`

for i in ${FILESLIST}

    do

filename1=`basename ${i}`

dir1=`dirname ${i}|sed 's/\/ora\/admin\///g

s/\/bdump//g'`

    MSG=`/usr/local/bin/fetchlog -F 1:100:1000:s ${i} /var/adm/${filename1}.${dir1}`

    if [ $? -gt 0 ]

    then

    MSG1=`echo  "${MSG}" | egrep -i "ora-"`

    if [ -n  "$MSG1" ]

    then

echo "\n${HOST}:${filename1}:${MSG1}\n"| /bin/mail ${MYMAIL}

fi

fi

done

Это можно сделать, например, с помощью пакета fetchlog [6]. На базе этого программного обеспечения создан скрипт fetchalert (см. листинг 9), который можно запускать с помощью демона crond:

testcase$EDITOR=vi;export EDITOR

testcase$crontab -e

testcase$0,15,30,45 * * * * /usr/local/bin/fetchalert >/dev/null 2>&1

Выводы

Предложенная схема проста и не требует специального аппаратного обеспечения для своей реализации, однако имеет и недостатки:

• Один из серверов находится в пассивном состоянии и не обслуживает запросы пользователей.
• Если поток транзакций на БД primary будет слишком большой, это создаст дополнительную нагрузку из-за репликации в общей сети, к которой подключены сервера.
• В данной конфигурации не предусмотрено специальных программно-аппаратных средств, контролирующих состояние системы-партнёра, наподобие тех, что применяются при построении, например, кластерных систем. В этом случае при возникновении сбоя, скажем, разрыва сетевого соединения, серверы не смогут однозначно определить источник проблем. В этом случае необходимо вмешательство системного администратора для принятия решения о переключении на резервный сервер. Время, необходимое человеку для принятия такого решения, следует учитывать при оценке общего времени восстановления работоспособности системы после сбоя наряду с длительностью самой процедуры переключения.

Но эти факторы могут и не оказать серьёзного влияния на работу системы, поскольку современные сетевые технологии позволяют передавать большие объёмы данных на значительные расстояния, а в качестве резервного может использоваться сервер меньшей мощности.

Удачи!

1. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/concepts.htm#g1049956 – механизм работы Oracle Data Guard.
2. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14210/hadesign.htm#i1006243 – понятие RTO и RPO.
3. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#i1179318 – режимы защиты Oracle Data Guard.
4. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm#i76646 – ограничение Logical Standby DB.
5. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14239/scenarios.htm#i1008082 – различные сценарии реализации Oracle Data Guard.
6. http://sourceforge.net/projects/fetchlog – проект fetchlog.

Комментарии могут оставлять только зарегистрированные пользователи