Date March 25th, 2011 Author Vitaly Agapov

Раньше я уже писал о том, как на DB2 можно создать High Performance Cluster. Тот механизм позволяет увеличивать производительность СУБД, меж тем как HADR позволит нам создать отказоустойчивую архитектуру. Стоит, правда помнить, что объединить эти два механизма в рамках единой реализации не получится, так как HADR не может работать с базой разделённой на партиции.
Итак, HADR позволяет зеркалировать все транзакции с активной базы на зеркальную, поддерживая актуальную резервную копию, которую в любой момент можно будет перевести в активный режим. Речь не о репликации, а именно о копировании логов с тразакциями, откуда можно сделать два вывода о работе HADR’а: на базе должно быть включено логирование (logretain) и резервная (standby) база будет недоступна для подключения. Последний вывод частично теряет свою актуальность, начиная с версии 9.7, где резервную базу можно включить в режим “reads on” и получить к ней доступ на чтение.

Итак, вот краткий алгоритм наших действий:

1. Настраиваем параметры активной базы;
2. Делаем её бэкап;
3. Восстанавливаем этот бэкап на резервном сервере;
4. Настраиваем стэндбайный сервер;
5. Стартуем HADR на стэндбайном сервере, затем на активном;
6. Проверяем, что всё работает;
7. Переключаемся по мере необходимости.

А теперь подробнее…

Для начала надо убедиться, что на DB2 разрешены внешние подключения:

db2set DB2COMM=tcpip

Проверить, что /etc/services прописаны службы для SVCENAME, а также прописать службу для HADR:

$ cat /etc/services | grep -i db2
db2c_db2inst1	50000/tcp
DB2_HADR_1      55001/tcp
DB2_HADR_3      55003/tcp

Проверить, что на базе включён LOGRETAIN, а LOGARCHMETH1 имеет значение LOGRETAIN. Если это не так, то его нужно включить, после чего сделать полный оффлайновый бэкап базы:

$ db2 update db cfg using LOGRETAIN on
$ db2 backup db <dbname> to /home/db2inst1/ without prompting

Затем можно прописать остальные важные для HADR параметры:

db2 update db cfg using LOGINDEXBUILD on
db2 update db cfg using HADR_LOCAL_HOST <active_ip>
db2 update db cfg using HADR_LOCAL_SVC DB2_HADR_1
db2 update db cfg using HADR_REMOTE_HOST <standby_ip>
db2 update db cfg using HADR_REMOTE_SVC DB2_HADR_3
db2 update db cfg using HADR_REMOTE_INST db2inst1

Делаем онлайновый бэкап базы и пересылаем его на резервный сервер. Там его надо восстановить, не делая ему rollforward. Таким образом, база на нём окажется в состоянии rollforward-pending.

Теперь здесь надо прописать те же параметры, только поменяв местами все значения для LOCAL и REMOTE:

db2 update db cfg for <dbname> using HADR_LOCAL_HOST <standby_ip>
db2 update db cfg for <dbname> using HADR_LOCAL_SVC DB2_HADR_3
db2 update db cfg for <dbname> using HADR_REMOTE_HOST <active_ip>
db2 update db cfg for <dbname> using HADR_REMOTE_SVC DB2_HADR_1
db2 update db cfg for <dbname> using HADR_REMOTE_INST db2inst1

Далее стартуем HADR на резервном сервере:

db2 start hadr on database as standby

И на активном:

db2 start hadr on database as primary

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

db2 get snapshot for database on

В выхлопе снэпшота нужно смотреть в секцию HADR Status:

HADR Status
  Role                   = Standby
  State                  = Peer
  Synchronization mode   = Nearsync
  Connection status      = Connected, 25.03.2011 10:58:28.716461
  Heartbeats missed      = 0
  Local host             = 10.0.2.192
  Local service          = DB2_HADR_1
  Remote host            = 10.0.3.80
  Remote service         = DB2_HADR_1
  Remote instance        = db2inst1
  timeout(seconds)       = 120
  Primary log position(file, page, LSN) = S0000003.LOG, 466, 0000000001D72205
  Standby log position(file, page, LSN) = S0000003.LOG, 466, 0000000001D72205
  Log gap running average(bytes) = 4068564

Всё, теперь любые изменения в активной базе приведут к соответствующим изменениям в резервной. Если мы захотим, чтобы базы поменялись ролями, то на текущей стэндбайной базе выполним команду:

db2 takeover hadr on database sample

В случае нештатных ситуаций, например при падении активного сервера, надо добавить параметр “by force”:

db2 takeover hadr on database sample by force

Tags: DB2
Category: DB2 | 1 Comment »

Comments

Один комментарий на “DB2 HADR для тех, кто делает это впервые”

1. Тимофей
   
   24 May 2013 - 9:21

   Добрый день, не подскажете я настроил HADR, всё работает, переключается.
   На основной сервер настроена WebSphere, в параметрах подключения к БД прописаны адрес сервера, порт и имя БД.
   Переключаю HADR на резерв, при том, что альтернативные серверы прописаны на обоих серверах БД, но WebSphere к базе уже соединиться не может.
   Скажите плз, должно вообще это работать?
   Спасибо.

Leave a comment