Blog

Jak monitorować replikację w Postgresie? W jaki sposób szybko wypromować nowy serwer główny? W tej części poradnika dotyczącego tworzenia niezawodnych klastrów bazodanowych w oparciu o PostgreSQL przyjrzymy się z wysokiego poziomu narzędziom ułatwiającym pracę administratorom i jednocześnie minimalizującym ryzyko braku dostępu do bazy danych – mowa tu o menedżerach replikacji.

W poprzednim artykule z tej serii pisaliśmy o dostępnych w PostgreSQL mechanizmach replikacji. Dziś skupimy się na tym, w jaki sposób można monitorować stan replikacji bazy danych przy pomocy narzędzi Open Source. Pokażemy także, jak zautomatyzować proces przełączenia serwera głównego na jeden z dostępnych serwerów pomocniczych w przypadku wystąpienia awarii serwera master.

Menedżer replikacji – ułatwienie pracy DBA

Korzystając z samego Postgresa, można z powodzeniem tworzyć konfiguracje replikacji pozwalające na osiągnięcie celu, jakim jest klaster wysokiej dostępności. Pod pojęciem klastra wysokiej dostępności (czasem też niezawodności) mamy tu oczywiście na myśli zespół współpracujących ze sobą serwerów trzymających pieczę nad zreplikowanymi danymi, gdzie jeden z nich będzie serwerem głównym, a reszta serwerami zapasowymi. Problem zaczyna się pojawiać w razie ewentualnej awarii.

Wyobraźmy sobie sytuację, w której serwer główny o godzinie 4:20 z jakiegoś powodu przestaje odpowiadać. Ze względu na specyfikę aplikacji baza danych musi być dostępna przez całą dobę. Zakładając, że zadziałał system monitoringu, następne działania to w kolejności: obudzenie DBA, który następnie zajmie się rozwiązywaniem problemu:

• wyborem nowego serwera głównego i jego rekonfiguracji do pełnienia tej roli
• rekonfigurację serwerów pomocniczych
• przekierowanie ruchu z aplikacji do nowego serwera głównego.

Taka sytuacja nastręcza jednak problemów, ponieważ wszystkie poszczególne kroki trzeba będzie wykonać pod presją czasu – szybko i perfekcyjnie, bez marginesu na popełnienie błędu. Oczywistym rozwiązaniem jest tutaj zwrócenie się w kierunku automatyzacji.

Wymaga to jednak napisania (a także utrzymywania!) własnego rozwiązania, które będzie ułatwiało pracę w sytuacjach kryzysowych. Warto więc wykorzystać istniejące i sprawdzone narzędzia Open Source.

Przykładem takiego rozwiązania jest repmgr. Automatyzuje on część pracy DBA podczas awarii oraz pozwala na automatyczną reakcję w razie jej wystąpienia. Dodatkowo ułatwia przeprowadzanie prac konserwatorskich związanych z prawidłowym utrzymaniem klastra wysokiej dostępności.

Failover – wybranie nowego serwera głównego w czasie awarii

Scenariusz, który zarysowaliśmy wcześniej – awaria serwera głównego oraz proces wyboru nowego serwera głównego, a także jego konfiguracja jest znana jako failover.

Jedną z trudności związanych z automatyzacją procesu przełączania serwera głównego w przypadku awarii jest wykrycie, że faktycznie do niej doszło. Jest to znany problem związany z systemami rozproszonymi rozwiązywany na przykład przez zastosowanie serwera świadka (ang. witness). Wyobraźmy sobie sytuację, gdzie w klastrze znajdują się dwa serwery – główny oraz pomocniczy. Dane z serwera głównego są replikowane do serwera zapasowego, a na obu działa menedżer replikacji. W przypadku zerwania połączenia z serwerem głównym trudno powiedzieć, z punktu widzenia serwera zapasowego, czy faktycznie należy rozpocząć procedurę failover, czy też brak połączenia wynika z jakichś problemów sieciowych.

W celu podjęcia decyzji, czy faktycznie należy wypromować nowy serwer główny, wykorzystywany jest mechanizm kworum (ang. quorum). Większość przy podejmowaniu tej decyzji zapewnia właśnie serwer świadek, który mając niezależne połączenie z serwerem głównym, jest w stanie potwierdzić lub zaprzeczyć wystąpieniu awarii.

Switchover – zmiana serwera głównego inicjowana przez DBA

Operacja switchover w zasadzie nie różni się niczym od operacji failover, z tą różnicą, że jest inicjowana nie przez wykrycie stanu awarii, a przez administratora. Na przykład w celu przeprowadzenia operacji konserwatorskich na jednym z węzłów w klastrze, takich jak aktualizacja do najnowszej wersji minor.

Podsumowanie

Jak widać, menedżer replikacji to bardzo ciekawe narzędzie dla każdego DBA. Kwestią otwartą w przypadku rozwiązań HA jest jeszcze oczywiście sposób poinformowania aplikacji łączących się z bazą, że serwer główny znajduje się w innym miejscu ze względu na awarię. Inną sprawą jest zerwanie istniejących połączeń w celu przeprowadzenia operacji konserwatorskich. Nie są to jednak rzeczy nierozwiązywalne, a możliwe sposoby na osiągnięcie prawdziwie zadowalających rezultatów omówimy w następnym artykule na temat tworzenia rozwiązania wysokiej dostępności z użyciem PostgreSQL.