Jak skonfigurować bazę DB2, aby zapewnić wysoką dostępność usług

W wielu obszarach gospodarczych dzisiejszego świata od systemów IT wymaga się, aby nieprzerwanie dostarczały usługę. W olbrzymiej większości systemy te są powiązane z bazami danych, których zabezpieczenie jest niezwykle istotne dla spełnienia warunku wysokiej dostępności.

Jednym z rozwiązań wysokiej dostępności HA (High Availability) baz danych jest zapewnienie synchronizacji i replikacji danych pomiędzy dwoma serwerami bazodanowymi. Jeden z nich działa, jako serwer główny (PRIMARY), który obsługuje transakcje. Drugi pełni role serwera zapasowego (STANDBY), który uaktywnia się po awarii serwera głównego. Podczas normalnej pracy system główny replikuje dane na system zapasowy. Dzięki temu system zapasowy ma zawsze aktualną kopię danych.

Opisana powyżej funkcjonalność została zaimplementowana w DB2 pod nazwą HADR (High Availability & Disaster Recovery). Jest ona dostępna bez dodatkowych opłat licencyjnych tylko w wersji Enterprise. Zanim przejdziemy do konfiguracji HADR musimy spełnić dwa warunki wstępne. Po pierwsze musi być zgodność obu serwerów na poziomie architektury procesora. Po drugie wersje zarówno DB2, jak i systemów operacyjnych muszą być zgodne. Zaleca się, aby oba serwery zarówno główny, jak i zapasowy miały porównywalną moc obliczeniową, tak aby po przełączeniu nie nastąpił spadek wydajności całego systemu. Oto konfiguracja krok po kroku.

1. Definiujemy porty TCP/IP w /etc/services do komunikacji między serwerami. Operacje wykonujemy na obu serwerach.


# echo "hadr_local_svc 50001" >> /etc/services
# echo "hadr_remote_svc 50002" >> /etc/services


2. Ustawiamy parametry konfiguracyjne HADR.


# db2 update db cfg for prod using hadr_local_host <adres IP serwera glownego>
# db2 update db cfg for prod using hadr_local_svc hadr_local_svc
# db2 update db cfg for prod using hadr_remote_host <adres IP serwera zapasowego>
# db2 update db cfg for prod using hadr_remote_svc hadr_remote_svc
# db2 update db cfg for prod using hadr_remote_inst <nazwa instancji na serwerze zapasowym>
# db2 update db cfg for prod using logindexbuild on
# db2 update db cfg for prod using logretain on
# db2 update alternate server for database prod using hostname < Ip servera zapasowego> port 50003


3. Wykonujemy kopie bazy serwera głównego, aby odtworzyć ją na serwerze zapasowym i w ten sposób przenieść konfigurację.


# db2 backup db prod


4. Przenosimy wykonaną kopię bazy na serwer zapasowy i odtwarzamy bazę poniższą komendą.


# db2 restore db prod


5. Mamy przeniesioną całą konfigurację z serwera głównego. Musimy ją zmodyfikować w następujący sposób.


# db2 update db cfg for prod using hadr_local_host <adres IP serwera zapasowego>
# db2 update db cfg for prod using hadr_local_svc hadr_remote_svc
# db2 update db cfg for prod using hadr_remote_host <adres IP serwera glownego>
# db2 update db cfg for prod using hadr_remote_svc hadr_local_svc
# db2 update alternate server for database prod using hostname < Ip servera glownego> port 50003


6. Startujemy serwery w odpowiedniej kolejności. Najpierw serwer zapasowy a po nim serwer główny. Na serwerze zapasowym startujemy usługę HADR w trybie standy.


# db2 deactivate db prod
# db2 start hadr on db prod as standby


7. Na serwerze głównym aktywujemy bazę i startujemy usługę HADR w trybie primary.

# db2 activate db prod
# db2 start hadr on db prod as primary

IBM pod koniec zeszłego roku wprowadził na rynek produkt o nazwie DB2 PureScale, który w całkowicie odmienny do HADR sposób realizuje wymagania wysokiej dostępności systemów IT. Dotykowo jest to rozwiązanie wysoko skalowalne. Ale o tym w innym razem.

Autor - Mariusz Czopiński - jest specjalistą w dziedzinie relacyjnych baz danych w IBM Polska