Wysoka dostępność PostgreSQL dzięki architekturze Master-Slave i Master-Master

Poniżej znajduje się fragment naszego raportu „Zarządzanie i automatyzacja PostgreSQL z ClusterControl”, który można pobrać bezpłatnie.

Uwaga dotycząca wersji: należy pamiętać, że terminy używane w tym blogu Master-Slave są synonimami terminów Master-Standby używanych przez PostgreSQL. Używamy Master-Slave, aby zachować równoległość z innymi technologiami.

W przypadku konfiguracji HA możemy mieć kilka architektur, ale podstawowymi będą architektury master-slave i master-master.Serwery baz danych mogą współpracować, aby umożliwić drugiemu serwerowi szybkie przejęcie kontroli w przypadku awarii serwera podstawowego (wysoka dostępność ) lub umożliwienie kilku komputerom obsługi tych samych danych (równoważenie obciążenia).

Architektury Master-Slave PostgreSQL

Architektury te umożliwiają nam utrzymywanie głównej bazy danych z jednym lub większą liczbą serwerów rezerwowych gotowych do przejęcia operacji w przypadku awarii serwera podstawowego. Te rezerwowe bazy danych pozostaną zsynchronizowane (lub prawie zsynchronizowane) z masterem.

Replikacja pomiędzy urządzeniem nadrzędnym i podrzędnymi może odbywać się za pomocą instrukcji SQL (rezerwy logiczne) lub poprzez modyfikacje wewnętrznej struktury danych (rezerwy fizyczne). PostgreSQL używa strumienia rekordów dziennika zapisu z wyprzedzeniem (WAL) do utrzymywania synchronizacji rezerwowych baz danych. Jeśli serwer główny ulegnie awarii, rezerwa zawiera prawie wszystkie dane serwera głównego i można ją szybko przekształcić w nowy główny serwer bazy danych. Może to być synchroniczne lub asynchroniczne i można to zrobić tylko dla całego serwera bazy danych.

Konfigurowanie replikacji strumieniowej to zadanie, które wymaga dokładnego wykonania kilku kroków. Aby zapoznać się z tymi krokami i dodatkowymi informacjami na ten temat, zobacz:Zostań administratorem baz danych PostgreSQL — jak skonfigurować replikację strumieniową w celu zapewnienia wysokiej dostępności.

Od wersji 10 PostgreSQL zawiera opcję ustawienia replikacji logicznej.

Replikacja logiczna umożliwia serwerowi bazy danych wysyłanie strumienia modyfikacji danych do innego serwera. Logiczna replikacja PostgreSQL tworzy strumień logicznych modyfikacji danych z WAL. Replikacja logiczna umożliwia replikację zmian danych z poszczególnych tabel. Nie wymaga wyznaczenia konkretnego serwera jako głównego lub repliki, ale umożliwia przepływ danych w wielu kierunkach.

Więcej informacji na temat replikacji logicznej znajdziesz:Blog:Przegląd replikacji logicznej w PostgreSQL.

Aby skutecznie zapewnić wysoką dostępność, nie wystarczy mieć architektura master-slave. Musimy również włączyć jakąś automatyczną formę przełączania awaryjnego, więc jeśli coś zawiedzie, możemy mieć najmniejsze możliwe opóźnienie w wznowieniu normalnej funkcjonalności. PostgreSQL nie zawiera mechanizmu automatycznego przełączania awaryjnego, który identyfikuje awarie w głównej bazie danych i powiadamia salve o przejęciu na własność, więc będzie to wymagało trochę pracy po stronie DBA. Powinieneś popracować nad skryptem, który zawiera komendę promującą pg_ctl, która będzie promować slave'a jako nowego mastera. Istnieją również narzędzia innych firm do tej automatyzacji. Istnieje wiele takich narzędzi, które są dobrze zintegrowane z funkcjami systemu operacyjnego wymaganymi do pomyślnego przełączenia awaryjnego, takimi jak migracja adresów IP.

Po awarii, musisz odpowiednio zmodyfikować swoją aplikację, aby mogła pracować z nowym masterem. Będziesz mieć również działający tylko jeden serwer, więc trzeba będzie odtworzyć architekturę master-slave, więc wrócimy do tej samej normalnej sytuacji, którą mieliśmy przed tym problemem.

Architektury Master-Master PostgreSQL

Ta architektura zapewnia sposób na zminimalizowanie wpływu błędu w jednym z węzłów, ponieważ drugi węzeł może zająć się całym ruchem, być może nieznacznie wpływając na wydajność, ale nigdy nie tracąc funkcjonalności. Służy również do osiągania (i może jest to nawet bardziej interesujące) skalowalności poziomej (skalowanie w poziomie), w przeciwieństwie do koncepcji skalowalności pionowej, w której dodajemy więcej zasobów do serwera (skalowanie w górę).

Aby zaimplementować tę architekturę, będziesz musiał użyć zewnętrznych narzędzi, ponieważ ta funkcja nie jest (jeszcze) natywnie obsługiwana przez PostgreSQL.

Musisz być bardzo ostrożny przy wyborze rozwiązania do wdrożenia master-master, ponieważ istnieje wiele różnych produktów. Wiele z nich jest nadal „zielonych”, z kilkoma poważnymi użytkownikami lub przypadkami sukcesu. Z drugiej strony niektóre inne projekty zostały porzucone, ponieważ nie ma aktywnych opiekunów.

Więcej informacji na temat dostępnych narzędzi można znaleźć na:Blog:Top PG Clustering HA Solutions for PostgreSQL.

Równoważenie obciążenia i łączenie połączeń

Istnieje kilka narzędzi do równoważenia obciążenia, których można użyć do zarządzania ruchem z aplikacji, aby w pełni wykorzystać architekturę bazy danych. W ten sam sposób istnieje kilka innych, które mogą pomóc w zarządzaniu sposobem, w jaki aplikacja łączy się z bazą danych, łącząc te połączenia i ponownie wykorzystując je między różnymi żądaniami.

Istnieje kilka produktów, które są używane do obu celów, takie jak dobrze znany pgpool, i kilka innych, które skupiają się tylko na jednej z tych funkcji, takich jak pgbouncer (zestawianie połączeń) i HAProxy (używane do równoważenia obciążenia).