Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

обзор возможностей

В контексте реализации отказоустойчивых решений основными задачами являются обеспечение быстрого времени восстановления при возникновении нештатной ситуации (аварии) и обеспечение минимальной потери или отсутствия потери данных. Казалось бы СУБД Oracle обеспечивает создание резервов данных (бэкапов) и поддерживает создание архивных журнолов, чего, в случае полного краха сервера, достаточно для восстановления данных и "подката вперёд" истории изменений базы. Однако, во-первых, это может потребовать довольно много времени и, во-вторых, практически всегда означает потерю части данных, не вошедших в архивные журналы

Для уменьшения времени восстановления сервиса и отрезка потерянных данных после краха сервера, а в отдельных случаях - и для исключения потери данных используется стандартное техническое решение - организация standby базы данных (или просто standby). В терминологии Oracle это решение называют "горячим" резервом, но в соответствии с природой этого решения правильнее говорить о "тёплом" резерве, как более адекватном термине, позаимствованном из терминологии PostgreeSQL. Связано это с тем, что в большинстве стучаев организация standby требует для активации ручных действий администратора, и не обеспечивает сохранность всех транзакций. Однако в отдельных частных случаях можно говорить о резерве "горячем", но это совсем отдельные и частные случаи

Методов организации standby существует несколько, но все они имеют одну основу - отдельный экземпляр и standby копия серверной БД, обычно расположенные на отдельном физическом сервере - для обеспечения резервирования "железа" - принимают с основной базы архивные журналы и периодически подкатывают их на standby копию. Таким образом при нештатной ситуации нет необходимости тратить время на разворачивание базы из резерва и накатывание истории изменений из архивных журналов. Такое решение называется "физический standby", ибо производится "подкат" модифицированых блоков из архивных журналов. Существует также "логический standby", при котором архивные журналы анализируются выделенными механизмами Oracle на предмет восстановления истории SQL операций, и именно такие SQL операции проводятся на standby копии БД. Однако логический стэндбай имеет ограничения я является более громоздким решением, и рассматриваться в настоящем обзоре не будет

За организацию standby необходимо платить, потому что такое решение требует трат на отдельную аппаратную платформу и на лицензирование отдельной копии ПО Oracle, используемой на standby сервере, в дополнение к аппаратной платформе и лицензированию сервера основного. Для Standart Edition редакции движка СУБД организация стэндбая выполняется в ручном режиме, когда именно администратор обеспечивает переключение и копирование архивных журналов ( alter system switch logfile; cp ...) на выделенный standby сервер и периодический запуск команд (alter database recover automatic standby database until cancel; alter database recover cancel;) подката этих журналов на standby копии БД. Обычно для этих целей пишутся скрипты, и задача эта не очень сложная

Возможны два варианта "ручного" стэндбая. В одном случае резервная БД запускается в режиме монтирования обычного контрольного файла с периодическим подкатом архивных журналов командой "RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL", а при необходимости перехода на standby база открывается с опцией RESETLOGS (так называемой смены инкарнации). Во втором случае создаётся специальный standby контрольный файл, монтируется в специальном режиме "ALTER DATABASE MOUNT STANDBY DATABASE" с периодическим подкатом журналов, и активацией при необходимости "... ACTIVATE STANDBY DATABASE", при которой база также открывается в режиме создания новой инкарнации

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

Таким образом при допустимости потери небольшой порции последних транзакций организация "ручного" стэндбая является бюджетным и вполне работоспособным решением. Важно, что для SE редакции СУБД Oracle это практически единственное решение по организации standby, и для администраторов той части организаций, которые не готовы оплачивать дорогостоящий Enterprise Edition навык организации ручного стэндбая может быть полезен. Важно, что возможность потери транзакций сильно связан с особенностями организации прикладного решения, использующего СУБД. В частности возможность повторного ввода данных последних операций операционистами банка может сделать такое решение предпочтительным и в задачах автоматизации банковской сферы, и автор имел практический опыт администрирования таких решений

Более расширенная версия движка СУБД - Enterprise Edition - включает в себя механизм организации физических и логических standby под названием Data Guard. Этот механизм позволяет автоматизировать перенос архивных журналов на standby сервер, определяет пропущенные журналы и подкачивает их, что может быть востребовано при размещении standby сервера на удалённой площадке с относительно ненадёжным сетевым каналом, а также автоматический подкат полученных журналов на standby базу. То есть автоматизирует задачи, решаемые администратором при создании "ручного" standby. Но это не всё

Дополнительными возможностями Data Guard являются полуавтоматическая смена ролей, обеспечивающая переключение основной копии БД и standby копии между собой, что востребовано для сервисных задач (впрочем, это вполне несложно делается руками при использовании "ручного" standby). Кроме того возможен режим работы Data Guard, при котором данные в standby базу подкатываются не из архивных, но из оперативных журналов в режиме реального времени, что позволяет минимизировать возможную потерю данных, но делает конструкцию менее надёжной, ибо любой сбой на standby приводит к недоступности и основной базы, что связано с необходимостью синхронного наката данных оперативных журналов на standby в этом режиме. Синхронный standby подразуменвае установку резервного сервера в непосредственной близости к основному, что обусловлено довольно невысокой надёжностью и временем отклика разделяющих площадки каналов

Кроме того существует механизм автоматической активации standby при отказе доступности основной БД, называемый Data Guard Broker. Однако в силу нещадной глючности у пытавшихся использовать его коллег, равно как и в силу специфики задачи, когда решение о переходе на standby должно учитывать возможности сохранения информации (транзакций), возможности восстановления основного сервера и БД при крахе и особенности ситуации - то есть приниматься человеком по обычно мало формализуемым признакам, автор не считает использование брокера правильным выбором, и относит его больше к "бантикам, втюхиваемым заказчику"

Таким образом для SE редакции можно довольно просто настроить standby в ручном режиме, сопоставимым с таким же режимом для СУБД PostgreeSQL. Это будет надёжное и малобюджетное решение. Для пользователей EE редакции появляется возможность использования Data Guard, который в общем случае будет повторять функциональность и характеристики "ручного" standby. Важно, что при использовании в организации редакций SE и EE можно остановиться на ручном standby, который вполне будет работать и для EE редакции СУБД. Это позволит не разводить зоопарк решений. С другой стороны при необходимости использования дополнительного функционала от Data Guard последний довольно просто настраивается, что будет показано в следующих разделах настоящего обзора

Ещё одним тонким моментом является увязка механизмов резервного копирования данных и standby для исключения ситуации, когда архивные журналы уходят в резервную копию и более недоступны по основному месту расположения, но, в то же время они ещё не перенесены на standby сервер, например в силу проблем с каналами связи с удалённой площадкой, на которой размещён standby. Это особенно актуально для "ручного" режима организации standby

организация Standby посредством Data guard

Необходимо сразу оговориться, что DataGuard - опция Enterprise редакции СУБД, и если вы не лицензировали использование Enterprise, то методы построения standby для вас будут совершенно другими - во многом основывающимися на ручной реализации большей части механизмов, обеспечиваемых DataGuard (ав том числе - копирование архивных журналов на snandby, проверка отсутствия пропусков в последовательности журналов, ручной периодический накат журналов на standby базу, создание новых файлов данных вручную на standby при создании их на основной базе). Т.е. организация standby без Enterprise лицензии является достаточно геморойной, но вполне реализуемой задачей

Можно добавить, что в таком ручном варианте реализация Standby для Oracle вполне сопоставима с реализацией Standby для PostgreeSQL (детально описанный в документации по PostgreeSQL), что лишний раз заставляет задуматься о целесообразности использования дорогостоящего Oracle там, где можно использовать более дешевый, но вполне качественный аналог

В случае же, если у вас Enterprise редакция, вы можете использовать встроенный механизм построения Standby с разнообразным дополнительным функционалом (таким, как временная смена ролей для основной базы и базы standby). Итак, при использовании Data Guard последовательность организации и использования standby выглядит так:

• создать инфраструктуру каталогов БД, журналов, init и passwd файлы, ссылки в oratab для standby базы
• сконфигурировать listener на слушание для master и standby баз
• прописать сетевые имена в tnsnames.ora каждого сервера для обращения к обоим базам (master и standby)
• внедрить в init файл master сервера команды
  log_archive_start = true
  #-- вариант для версии 9i
  log_archive_dest_1 = 'LOCATION=/base/arc/redo_'
  #-- вариант для версии 11 с учётом использования FRA,
  #-- при отсутствии можно явно указать путь вместо USE_DB_RECOVERY_FILE_DEST
  log_archive_dest_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'
  log_archive_dest_state_1 = ENABLE
  #-- вариант для версии 9i
  log_archive_dest_2 = 'SERVICE=standby_tns_alias'
  #-- вариант для версии 11
  log_archive_dest_2 = 'SERVICE=standby_tns_alias VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'
  log_archive_dest_state_2 = ENABLE
  log_archive_min_succeed_dest = 1
  log_archive_format = %S.arc
  remote_archive_enable = TRUE
  fal_server = standby_tns_alias
  fal_client = master_tns_alias
  standby_file_management = auto
  #-- опция применима к версии 8 и отдельным вариантам конфигурирования в 9
  standby_archive_dest = '/base/standby_arc/'
• внедрить в init файл standby сервера команды
  log_archive_start = true
  #-- вариант для версии 9i
  log_archive_dest_1 = 'LOCATION=/base/arc/redo_'
  #-- вариант для версии 11 с учётом использования FRA,
  #-- при отсутствии можно явно указать путь вместо USE_DB_RECOVERY_FILE_DEST
  log_archive_dest_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'
  log_archive_dest_state_1 = ENABLE
  #log_archive_dest_2 = 'master_tns_alias'
  #log_archive_dest_state_2 = ENABLE
  log_archive_min_succeed_dest = 1
  log_archive_format = %S.arc
  #remote_archive_enable = RECEIVE
  remote_archive_enable = TRUE
  fal_server = master_tns_alias
  fal_client = standby_tns_alias
  standby_file_management = auto
  #-- опция применима к версии 8 и отдельным вариантам конфигурирования в 9
  standby_archive_dest = '/base/standby_arc/'
• потушить master базу и скопировать ее в соответстввующие каталоги на slave
• поднять master БД и создать на ней standby контрольные файлы командой
  ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'полный_путь' ;
  после чего перенести созданный контрольный файл на slave и заместить им контрольные файлы на standby БД
• запустить standby базу на standby сервере командами
  startup nomount
  alter database mount standby database
• запустить автоприменение журналов командой
  alter database recover managed standby database disconnect from session ;
• запустить основную базу

P.S. Проверить работоспособность можно по alert логам, а также попробовать попереключать журналы на master базе командами
ALTER SYSTEM SWITCH LOGFILE
ARCHIVE LOG ALL
и сравнив вывод команды
select SEQUENCE#,FIRST_TIME,NEXT_TIME,ARCHIVED,APPLIED,creator from v$archived_log where status = 'A' order by sequence# ;

тонкие моменты

режим сохранности данных меняется формулой
alter database set standby database to maximize [PERFOMANCE | IVAILABILITY | ... ]

но !!
- при переводе из дефолта (PERF) нужно настроить копирование не ARCH, но LGWR, для чего в удаленном
archive_log_destination_x='SERVICE=... LGRW SYNC AFFIRM'

- при временной рокировке ролей master и standby (switchover) проблем возникать не должно, а вот при попытке поднять standby базу как master при отказе прежнего master (режим filover) - начинаются засады, и нужно сажать базу в mount, возвращать PERFOMANCE и выкидывать из переменной
arc_log_dest... модификаторы LGWR SYNC AFFIRM

Switchover - временная смена ролей

- режим switchover позволяет резво "рокировать" роли для тех. работ на основной базе и обратно

-- на master базе
select switchover_status from v$database ; => TO STANDBY
alter database commit to switchover to physical standby ;
shutdown immediate ;
закомментировать относящиеся к archive_log_dest_2 опции - иначе потом не просто сменить роли обратно
startup nomount ;
alter database mount standby database ;
alter database recover managed standby database disconnect from session ;

-- потом на standby базе
select switchover_status from v$database ; => TO PRIMARY
alter database commit to switchover to physical primary ;
shutdown immediate ;
раскомментировать относящиеся к archive_log_dest_2 опции для копирования журналов на standby
startup ;

-- потом на standby базе
alter system switch logfile ;

и потом обратный переход

Filover - поднятие standby до master при авари последнего

-- выверить, что накачено максимальное количество журналов
select from v$archive_gap
select from v$archived_log
при необходимости и доступности перенести недостающие журналы и
зарегистрировать их командой
alter database register physical logfile '...' ;

-- т.к. gap показывает только последний ошибочный диапазон - повторять шаг 1, пока выборка не станет нулевой

-- тушится автонакатывание
alter database recover managed standby database finish ;
или
alter database recover managed standby database finish skip standby logfile ;

-- база делается новой master
alter database commit to switchover to primary ; (альтернатива - alter
database activate standby database ;)
shutdown ;
раскомментировать относящиеся к archive_log_dest_2(xxx) опции для копирования журналов с нового master на standby
startup ;

за кадром

За кадром настоящей статьи - описание намоленных решений по организации скриптового стэндбая для standart edition и варианты настройки standby на том же сервере, что и продуктовая БД (что может быть востребовано для распараллеливания по нодам юниксового кластера)

Белонин С.С. (С), май 2007 года