Настройка режима горячего резервирования штатными средствами DB2

Краткое содержание:

IBM DB2 предоставляет возможности построения систем высокоготовных отказоустойчивых систем (High Availability Disaster Recovery) начиная с самых младших редакций сервера , включая DB2 Express-C FTL. Все эти возможности в документации и книгах по DB2 скрываются за аббревиатурой "HADR". В данной статье будет рассказано о том, как можно штатными средствами DB2 настроить отказоустойчивую конфигурацию, в которой при сбое в работе основного сервера с базой данных можно в течение нескольких секунд переключить работу системы на резервный сервер СУБД.

Введение

IBM DB2 предоставляет возможности построения систем высокоготовных отказоустойчивых систем (High Availability Disaster Recovery) начиная с самых младших редакций сервера , включая DB2 Express-C FTL. Все эти возможности в документации и книгах по DB2 скрываются за аббревиатурой "HADR".

Естественно, что в документации по DB2 есть исчерпывающая информация по возможностям конфигурирования HADR. Но есть и отдельный Redbook (на английском) "High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows", подробно рассматривающий данные вопросы, и имеющий, на мой взгляд, более удачную структуру информации.

В данной статье будет рассказано о том, как можно штатными средствами DB2 настроить отказоустойчивую конфигурацию, в которой при сбое в работе основного сервера с базой данных можно в течение нескольких секунд переключить работу  системы на резервный сервер СУБД.

О чем в этой статье НЕ БУДЕТ рассказано.

1. Здесь вы не найдете описания окон графического интерфейса для настройки и конфигурирования HADR. Графический интерфейс пользователя для управления и настройки HADR есть. Перейти на него можно по правому щелчку мышки на имени базы данных в Центре управления DB2. Но прочитав эту статью вы будете лучше понимать, что вы делаете в рамках графического интерфейса.

2. Здесь вы не найдете рецептов настройки автоматического переключения между узлами HADR кластера. Для этого может быть использовано различное кластерное ПО, например IBM Tivoli. Об этом вы можете прочитать в упомянутом Redbookе (главы 7 и 8) и документации по DB2. В рамках данной статьи будет рассказано, как переключить узлы кластера вручную.

3. В данной статье не рассматриваются различные сценарии восстановления работоспособной конфигураци после сбоя. Например в Reedbooke данным вопросам посвящены 7 страниц раздела 3.4.5.

4. Обсуждение вопросов администрирования конфигураций HADR также вынесено за рамки данной статьи. Подобные вопросы подробно изложены в документации по DB2 и.... да, в Redbookе

5. Вопросы лицензирования HADR конфигураций подробно рассмотрены в статье , опубликованной на developerWorks. к сожалению, пока на английском языке.

Для того, чтобы восползоваться HADR вам необходимо иметь коммерческую версию DB2 (или ее trial-версию). В настоящий момент для целей изучения возможностей DB2 HADR рекомендуется использовать DB2 v9.7 FP1.Скачать ее можно с сайта IBM. Официально данная версия на данный момент не рекомендована, но все исправления, что есть в сборке v9.5 22521 в нее включены.

При установке DB2 Server FixPack устанавливается trial-версия с ограниченным сроком действия.

Коротко о главном

DB2 High Availability Disaster Recovery (HADR) - это режим репликации данных, обеспечивающий режим выской доступности решения при частичном и/или полном отказе рабочего узла.

При стандартных подходах восстановление после сбоя в работе сервера, где расположена база данных, может потребовать перезагрузки сервера и с последующим восстановлением базы данных, что вызовет простой системы в целом. Использование DB2 HADR позволяет безболезненно сократить общее время простоя системы всего лишь до нескольких секунд. HADR обеспечивает сохранность данных за счет постоянной репликации изменений в основной базе (PRIMARY) в резервную (STANDBY), которая становится основной в случае сбоя. Изменения передаются в виде записей транзакционного журнала, которые,  в свою очередь, резервный сервер "накатывает" на свою копию базы данных, обеспечивая тем самым, синхронность данных с основным сервером. При этом приложения всегда работают с основным сервером, а соединение с резервным запрещено (в ближайшем будущем планируется обеспечение режима доступа "только для чтения" для резервной базы данных). Поскольку взаимодействие в рамках HADR осуществляется по протоколу TCP/IP, то резервный сервер может быть развернут на удаленном узле, что поволяет обеспечить сохранность данных даже в случае физического разрушения основного узла (т.н. катастрофо-устойчивая конфигурация).

Топология и архитектура HADR

В общем виде устройство HADR в DB2 показано на рисунке ниже.

Концепция HADR

Передача между основным и резервным сервером HADR данных, включая сигналы готовности и управляющую информацию о состоянии репликации, происходит по выделенному порту TCP/IP,  причем номер этого порта  отличен от номера порта, на котором работает сам экземпляр DB2. Единственный доступный режим конфигурации - в котором присутствуют 2 узла - основной и резервный. Построить топологию с нескоклькими резервными серверами в данном случае не получится. НО!

Поскольку HADR-репликация осуществляется на уровне базы данных, а не экземпляра DB2, то на "большом" сервере могут быть сосредоточены несколько первичных баз, а вот резервные базы, могут быть разнесены на несколько физических серверов. Причем для одной базы сервер может быть первичным, а в другом случае - вторичным (Database A,C на рисунке ниже)

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

Режимы синхронизации HADR

В рамках HADR можно использовать три уровня защиты от потенциальной потери данных, выбирая один из трех режимов синхронизации:

Синхронный (Synchronous):

Запись в транзакционный журнал считается успешной в том случае, когда буфер журнала был записан на диск на основном сервере и получено уведомление, что он также был записан в транзакционный журнал на резервном сервере. В данном режиме потеря данных невозможна, если узлы находятся в состоянии Peer.

Почти синхронный (Near-synchronous):

Этот режим используется по-умолчанию. Запись в транзакционный журнал считается успешной в том случае, когда буфер журнала был записан на диск на основном сервере и получено уведомление, что он был полулчен резервным сервером.

Асинхронный (Asynchronous):

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

База данных называется 'hadrdb'

Первые шаги

Бесплатная DB2 Express-C не обладает лицензией, позволяющей строить HADR конфигурации. Поэтому для проверки возможностей HADR потребуется наличие либо FTL лицензии на DB2 Express-C, либо редакции Workgroup или Enterprise, оценочные версии которых можно скачать с сайта IBM. В настоящий момент из публично доступных версий рекомендуется использовать DB2 v9.5 FixPack 4. Также следует отметить, что среди публично доступных версий DB2 нет версии, которая может рабтать с платформой 1С:Предприятия 8.2. Ее появление планируется с выходом FP1 для DB2 v9.7.

Прежде, чем приступить к конфигурированию HADR, убедитесь, что  версии DB2 у вас одинаковые на основном и резервном серверах. Основной и резервный сервер должны работать на одной и той же ОС, иметь одинаковую разрядность, и версии DB2 должны совпадать.

1. Архивное журналирование

По-умолчниаю базы создаются с циклическим транзакционным жунранлом. Для HADR необходимо переключить нашу базу данных на архивный режим журналирвания с циклического журналирования.

Чтобы включить данный режим журналирования, надо хотя бы одному из двух параметров LOGARCHMETH1 или LOGARCHMETH2 задать значение, отличное от OFF.

В качестве значения параметра указывается место размещения архивов транзакционнного журнала базы данных. Причем если вы зададите значение для обеих параметров, то у вас будет создаваться 2 копии архивов транзакционного журнала, но расположены они будут в разных местах.

Более подробно о параметрах конфигурации журнала транзакций при HADR можно прочитать в документации по DB2.

2. Создание начальной копии резервной базы.

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

Сделайте offline резервную копию вашей основной базы, выполнив команду

Копировать в буфер обмена
db2 backup db hadrdb to <dir>

Скопируйте файл бэкапа на резервный сервер.

Создайте новую базу из резервной копии выполнив команду

Копировать в буфер обмена
db2 restore db hadrdb from <dir>

  Если у вас конфигурация дисков/файловой системы не совпадает с основным сервером, то требуется при создании базы данных из резервной копии добаваить параметры ON <PATH> DBPATH ON <PATH>.

Например, если у  вас на основном сервере база размещается на диске E:, а на резервном есть только С:, то команда будет выглядеть следующим образом

Копировать в буфер обмена
db2 restore db hadrdb from <dir> on E: dbpath on E: 

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

3. Прочие параметры

В случае HADR рекомендуется задать следующие значения параметров конфигурации базы данных.

Параметр базы данных Значение
LOGINDEXBUILD  ON
 INDEXREC  RESTART

Если вы хотите подробней познакомиться с рекомендациями по установке этих параметров, отвечающих за синхронизацию индексов, их можно найти в документации по DB2, Для целей настоящей статьи мы ограничимся лишь перечислением задаваемых значений.

Параметры конфигурации

Для каждой копии базы данных (основной и резервной)  необходимо задать следующие параметры конфигурации:

Таким образом конфигуация баз данных на серверах будет выглядеть следующим образом

 Параметр базы данных Значение
 HADR_SYNCMODE Режим синхронизации. ASYNC, NEARSYNC, SYNC. Мы их вкратце рассмотрели в разделе "Режимы синхронизации HADR"
 HADR_TIMEOUT Время ожидания ответа от основного сервер в секундах.
 HADR_LOCAL_HOST Имя/адрес локального сервера
 HADR_LOCAL_SVC Номер локального порта (имя сервиса), используемого для HADR
 HADR_REMOTE_HOST Имя/адрес удаленного сервера
 HADR_REMOTE_SVC Номер порта, используемого для HADR на удаленном сервере
 HADR_REMOTE_INST

Имя экзеспляра DB2 на удаленном сервере. Имя экземпляра можно узнать выполнив команду db2level, в выводе которой в первой строке присутствует данная информация. В примере ниже имя инстанса db2inst.

DB21085I  Instance "db2inst" uses "64" bits and DB2 code release "SQL09052" 

Первые 2 параметра будут одинаковыми на обеих серверах  А последующие 5 зеркально меняются при конфигурировании основного и резервного серверов Давайте рассмотрим конкретную конфигурацию. Основной сервер IP: 172.17.192.92 Резервный сервер IP: 172.17.192.193 Имя инстанса на обоих серверах - "DB2" HADR порт тоже будем использовать один и тот же - 51000 Таким образом конфигуация баз данных на серверах будет выглядеть следующим образом

 Параметр базы данных Основной
Резервный
 HADR_SYNCMODE  SYNC
 SYNC
 HADR_TIMEOUT  120  120
 HADR_LOCAL_HOST  172.17.192.92 172.17.192.193
 HADR_LOCAL_SVC  51000 51000
 HADR_REMOTE_HOST  172.17.192.193 172.17.192.92
 HADR_REMOTE_SVC  51000 51000
 HADR_REMOTE_INST  DB2 DB2

Конфигурация альтернативного сервера.

Также для каждого из серверов необходимо укзать имя/адрес и порт альтернативного сервера, к которому будут подключаться клиенты в случая сбоя.

Конфигурирование выполняется командойна стороне, где установлен сервер 1С:Предприятия.

Копировать в буфер обмена
db2 update alternate server for database hadrdb using hostname <host|IP>  port <port>

  Это мы сконфигурировали альтернативный, а где-же основной? Как правило, сервер 1С совмещен с сервером баз данных, а значит запись об основном сервере базы данных присутствует на сервере. Посмотреть спискок всех каталогизированных баз данных можно командой

Копировать в буфер обмена
db2 list db directory 

Вот пример каталожной записи о базе данных

Копировать в буфер обмена
 Database 1 entry:
Database alias                       = NEWDB2
Database name                        = NEWDB2
Local database directory             = /home/db2inst
Database release level               = c.00
Comment                              =
Directory entry type                 = Indirect
Catalog database partition number    = 0
Alternate server hostname            =
Alternate server port number         =

Как видите, для нее не задано имя и порт альтернативного инстанса сервера DB2, где находится резервная копия базы.

Но что делать, если вы видим такую картину?

Копировать в буфер обмена
C:\IBM\SQLLIB\BIN>db2 list db directory
SQL1057W  The system database directory is empty.  SQLSTATE=01606

И это вполне возможно, если сервер 1С и сервер базы данных разнесены. Дело в том, что 1С создает каталожную запись только на момент создания базы данных, а потом ее удаляет, т.к. для механизма соединения, который использует 1С, эта каталожная запись о базе данных не нужна. Но нам придется ее воссоздать для того, чтобы иметь возможность задать альтернативный сервер для базы данных. Это можно сделать через Центр Управления DB2, а можно сделать гороздо быстрей в командной строке. Во-первых, нам надо каталогизировать удаленный узел (инстанс) DB2, а потом в рамках этого узла каталогизировать базу данных. Рассмотрим на примере, что скрывается за всеми этими словами. Есть сервер базы данных, расположенный на машине с адресом 172.17.192.92. Инстанс DB2 называется 'DB2' и работатет по стандартному порту 50000.

Вначале мы делаем каталожную запись об узле

Копировать в буфер обмена
db2 catalog tcpip node MYNODE remote 172.172.192.92 server 50000 remote_instance DB2

После этого мы каталогизируем базу данных в рамках этого узла

Копировать в буфер обмена
db2 catalog database HADRDB at MYNODE

после этого можно проверить соединение с базой командой

Копировать в буфер обмена
db2 connect to HADRDB user db2admin 

Теперь осталось только указать альтернативны сервер. Посольку при каталогизации базы мы указали основной сервер с адресом *.92, то в качестве альтернативного задаем *.193

Копировать в буфер обмена
db2 update alternate server for database HADRDB using hostname 172.17.192.193 port 50000

 После чего еще раз можно выполнить команду db2 list db directory и убедится, что для базы данных задан альтернативный сервер.

Инициализация и запуск

Порядок запуска HADR предусматривает вначале запуск резервного сервера, а потом основного. Для запуска базы данных в режиме HADR на резервном сервере HADR выполняется команда

Копировать в буфер обмена
db2 start hadr on db hadrdb as standby

Для запуска базы данных в режиме HADR на основном сервере hadr выполняется команда

Копировать в буфер обмена
db2 start hadr on db hadrdb as primary

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

Копировать в буфер обмена
db2 deactivate db HADRDB

Проверка работоспособности

Как убедиться в том, что HADR-пара работает? Эту информацию можно поулчить, сделав снимок базы данных (database snapshot), в результатах которого соддержится информация о HADR статусе.

Копировать в буфер обмена
db2 get snapshot for database on HADRDB

Ниже приведен вывод HADR статуса для резервной копии базы, сразу после запуска HADR.

Копировать в буфер обмена
HADR Status
  Role                   = Standby
  State                  = Remote catchup pending
  Synchronization mode   = Nearsync
  Connection status      = Disconnected , 14.07.2009 02:46:28.061372
  Heartbeats missed      = 0
  Local host             = 172.17.192.193
  Local service          = 51000
  Remote host            = 172.17.192.92
  Remote service         = 51000
  Remote instance        = DB2
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000000.LOG, 0, 00000001662AD2A1
  Standby log position(file, page, LSN) = S0000075.LOG, 6829, 00000001662AD2A1
  Log gap running average(bytes) = 0

А вот HADR статус основной копии базы, сразу после запуска

Копировать в буфер обмена
HADR Status
  Role                   = Primary
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 14.07.2009 02:55:57.155230
  Heartbeats missed      = 0
  Local host             = 172.17.192.92
  Local service          = 51000
  Remote host            = 172.17.192.193
  Remote service         = 51000
  Remote instance        = DB2
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000
  Standby log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000
  Log gap running average(bytes) = 1116434

В рабочем состоянии статус HADR-пары должен быть "Peer". 

Еще раз сделаем снимок реервной базы, после того как HADR был активирован на обоих узлах пары, и убедимся, что узел также находится в рабочем состоянии

Копировать в буфер обмена
HADR Status
  Role                   = Standby
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected , 14.07.2009 02:54:35.389333
  Heartbeats missed      = 0
  Local host             = 172.17.192.193
  Local service          = 51000
  Remote host            = 172.17.192.92
  Remote service         = 51000
  Remote instance        = DB2
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000
  Standby log position(file, page, LSN) = S0000076.LOG, 0, 0000000166800000
  Log gap running average(bytes) = 279108

Обратите внимание на последнюю строчку статуса. Оказывается наши копии на момент запуска были не совсем синхронны. В данном случае возникает разница в логах, которая со временем снижается до 0, по мере репликации транзакционного журнала на резервную копию базы данных.

Остановка HADR конфигурации

Если вы хотите остановить HADR операции, то рекомендуется следующая последовательность операций для остановки HADR-пары:

1.  Деактивировать основную базу данных.

2.  Деактивировать резервную базу данных.

Выполняется эта оуперация уже знакомой командой 

Копировать в буфер обмена
db2 deactivate db HADRDB

Также можно выполнить остановку HADR режима на основной базе командой

Копировать в буфер обмена
db2 stop hadr on db HADRDB

(На резервной базе такая команда приведет к ошибке!) В данном случае основная база переходит в стандартный режим работы. Причем после повторного запуска  основной базы в режиме HADR, изменения, сделанные за период работы в стандартном режиме, будут синхронизированы с резервной копией базы данных.

Управление HADR-парой

Вообще для HADR пары есть 3 основных операции: START, STOP и TAKEOVER. Один из переводов слова "takeover" означет "взятие под свой контроль и управление". Как делается запуск, мы уже знаем.

Остановка HADR конфигурации

Если вы хотите остановить HADR операции, то рекомендуется следующая последовательность операций для остановки HADR-пары:

1.  Деактивировать основную базу данных.
2.  Деактивировать резервную базу данных.

Выполняется эта операция уже знакомой командой 

Копировать в буфер обмена
db2 deactivate db HADRDB

Также можно выполнить остановку HADR режима на основной базе командой

Копировать в буфер обмена
db2 stop hadr on db HADRDB

(На резервной базе такая команда приведет к ошибке!) В данном случае основная база переходит в стандартный режим работы. Причем после повторного запуска  основной базы в режиме HADR, изменения, сделанные за период работы в стандартном режиме, будут синхронизированы с резервной копией базы данных, если для пары режим HADR Синхронный или Почти синхронный режим работы.

Переключение узлов

При помощи команды

Копировать в буфер обмена
db2 TAKEOVER HADR ON DB HADRDB [BY FORCE]

вы можете поменять ролями основную и резервную копию базы, если они находятся в состоянии "Peer". Если же произошел сбой в работе основной базы, то для перевода резервной базы в состояние основной, необходимо добавить параметр команды BY FORCE. Причем, рекомендуется убедиться, что основная база данных не обслуживает запросы. Возможно для этого будет недостаточно команды db2stop, а потребуются системные средства управления. 

Диагностика на стороне 1С:Предприятия в случае сбоя

Если произошел отказ основной базы данных, то пользователь 1С получит ошибку соединения с базой. При перезапуске он автоматически будет подключен к резервному серверу с базой данных (к тому моменту он должен быть переведен в режим primary естественно). Поскольку рабочий процесс сервера 1С держит пул соединений с базой, то многие пользователи просто не заметят отказа основного сервера, посольку "подхватят" уже рабочее соединение с резервным сервером.