Побудова відмовостійкої системи з допомогою Oracle Physical Standby
Розгорнувши інформаційну систему на базі СУБД Oracle і організувавши надійну стратегію резервного копіювання-відновлення, можна приступати до виробничої експлуатації системи. У разі аварії можливо буде відновити дані на необхідний момент часу. Але що робити, якщо допустимий час простою не повинно перевищувати декількох хвилин? Тоді не обійтися без різних способів дублювання даних в режимі реального часу.
Структура Oracle Data Guard
Залежно від конкретних вимог щодо часу відновлення і допустимої втрати даних на підводному човні (recovery time objective, recovery point objective [2]). Можуть бути різні сценарії реалізації:
- Physical standby DB - резервна база даних є точною фізичної копією основний, знаходиться в монтувати стані і при цьому переноситься потік redo-інформації.
- Logical standby DB - резервна база даних не є точною копією основний, відкрита в режимі читання-запису і при цьому переноситься потік SQL-команд.
У разі необхідності така база може бути в короткий термін активована в якості виробничої.
Оскільки БД 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.
Необхідно виконати наступні дії:
Включимо режим 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
sqlplus "/ as sysdba" < 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; Встановимо параметри в файлах параметрів init.ora / spfile.ora для primary і standby (див. Лістинг 2). Лістинг 2. Відомості про опції файлу init.ora / spfile.ora * .control_files = '/ tstb / ORCL / control01.ctl', '/tstb/ORCL/control02.ctl', '/tstb/ORCL/control03.ctl' * .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' Створення резервної БД standby Створимо резервні копії бази даних і файлу паролів і перенесемо скопійовані файли на резервний сервер Fastiv. Оскільки значення ORACLE_SID для основної та резервної баз відрізняються, файли паролів теж матимуть різні імена, наприклад, orapwORCL і orapwORCL1. Створимо standby control file і скопіюємо його на сервер standby в розташування, вказане в файлі параметрів бази даних standby: SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby.ctl'; Перемкнемо основну базу даних в режим maximum availability наступною командою: SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; Бази даних готові до роботи. Тепер обидві бази даних можна запускати. Операції з БД під час роботи Під час роботи необхідно виконувати певні дії - пуск, зупинка, відкриття для читання, реєстрація пропущених логів, активація резервної бази (failover), обмін статусом (switchover). Розглянемо ці операції: Скрипт stbstart відповідає за старт БД standby в режимі real-time apply. Зупинку БД standby забезпечує скрипт stbshut (див. Лістинг 4). Лістинг 4. Пуск і зупинка БД Physical Standby sqlplus "/ as sysdba" < alter database mount standby database; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; sqlplus "/ as sysdba" < ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Перевіримо механізм передачі змін перемиканням журналів. На primary: SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT GROUP #, THREAD #, SEQUENCE #, ARCHIVED, STATUS FROM V $ STANDBY_LOG; Скрипт stbreadonly відповідає за запуск БД standby в режимі read-only (див. Лістинг 5). Доставка Redo в цьому випадку триває, однак зміни будуть відкладені до виходу з цього режиму. Лістинг 5. Запуск БД standby в режимі read-only sqlplus "/ as sysdba" < ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; alter database open read only; Switchover - скрипт для зміни ролей між базами даних. Необхідно, щоб БД primary була відкрита, а standby була в режимі mount або recover (див. Лістинг 6). Як можна бачити в скрипті, для перемикання ролей необхідно мати доступ до кожної з баз даних, що беруть участь в операції. Лістинг 6. Обміну ролями між базами Poltava і Fastiv sqlplus "/ as sysdba" < 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; 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; column DATABASE_ROLE format A20 heading 'Role after | switchover' select DATABASE_ROLE from V \ $ DATABASE; Failover - cкриптов, що активує резервну базу в разі аварії на базі primary. Оскільки резервної бази більше немає, перед активацією резервної бази її слід перевести в режим maximum performance (див. Лістинг 7). SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; Реєстрація пропущених логів наочно показана в лістингу 8. Лістинг 7. Активація резервної бази даних в разі аварії sqlplus "/ as sysdba" < 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; Лістинг 8. Визначення та дозвіл вручну пропусків передачі журналів SQL> SELECT THREAD #, LOW_SEQUENCE #, HIGH_SEQUENCE # FROM V $ ARCHIVE_GAP; THREAD # LOW_SEQUENCE # HIGH_SEQUENCE # SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; Автоматизація моніторингу роботи Оскільки БД primary знаходиться в режимі maximum availability, то в разі зупинки резервного сервера основна БД продовжить свою роботу. Між станом primary і standby утворюється розрив. Для виявлення і усунення поломки потрібно час, протягом якого основна база даних не резервується. У цей момент, в разі повторної аварії вже на основній базі даних, можлива втрата даних. Щоб своєчасно виявляти і усувати подібні ситуації, необхідно автоматизувати процес спостереження за роботою обох БД. Лістинг 9. Скрипт, що виконує пошук помилок в файлі alert.log if [-f / tmp / memsg_no] FILESLIST = `ls -R / ora / admin / * / bdump / *. Log` dir1 = `dirname $ | sed 's / \ / ora \ / admin \ /// g MSG = `/ usr / local / bin / fetchlog -F 1: 100: 1000: s $ / var / adm /$.$` MSG1 = `echo" $ "| egrep -i "ora-" ` Це можна зробити, наприклад, за допомогою пакета fetchlog [6]. На базі цього програмного забезпечення створено скрипт fetchalert (див. Лістинг 9), який можна запускати за допомогою демона crond: testcase $ 0,15,30,45 * * * * / usr / local / bin / fetchalert> / dev / null 2> 1 Запропонована схема проста і не вимагає спеціального апаратного забезпечення для своєї реалізації, однак має і недоліки: Але ці чинники можуть і не чинити серйозного впливу на роботу системи, оскільки сучасні мережеві технології дозволяють передавати великі обсяги даних на значні відстані, а в якості резервного може використовуватися сервер меншої потужності.