Replikacja strumieniowa i przełączanie awaryjne na PostgreSQL


14

Robię weryfikację koncepcji replikacji PostgreSQL. Po dyskusji na forum zdecydowaliśmy się na replikację strumieniową, ponieważ wydajność jest dobra w porównaniu do innych rozwiązań. PostgreSQL nie zapewnia automatycznego przełączania awaryjnego do replikacji strumieniowej. Możemy przełączyć slave na master za pomocą pliku wyzwalacza, ale nie jest to możliwe do zarządzania. Chciałbym więc rozwiązanie z automatycznym przełączaniem awaryjnym i wysoką dostępnością.

Dostępne są różne rozwiązania:

  1. Repmgr
  2. Linux Heartbeat
  3. Pgpool-II (tylko do automatycznego przełączania awaryjnego)
  4. Każde inne narzędzie, w przypadku którego użyłeś.

Moje pytanie brzmi, które rozwiązanie należy zastosować?

Odpowiedzi:


8

W naszym sklepie wybraliśmy repmgr i pgbouncer zamiast pgpool. repmgr ma fajne narzędzie do konfiguracji i zarządzania klastrem replikowanych serwerów baz danych. W naszym przypadku 1 master i 2 slave (jeden tryb failover i jeden test wydajności odczytu na żywo, które mogą stać się trybem failover nowego master). pgpool ma problemy ze zmianami w konfiguracji, w większości przypadków musisz ponownie uruchomić usługę i dlatego masz trochę przestoju. Jest to problem, gdy potrzebujesz dostępności 24x7x365.

repmgrd (deamon) pomaga wybrać nowego mistrza po przełączeniu awaryjnym, naprawdę nie chcesz rozszczepionej sytuacji mózgu. Mamy jeden wirtualny adres IP dla głównej bazy danych, która jest w tej chwili bazą główną. Gdy inny serwer staje się master, jest to jedyny serwer używający tego adresu. Każdy serwer bazy danych ma również własny adres IP do zapytań tylko do odczytu.

repmgr jest obsługiwany przez tych samych facetów, którzy stworzyli replikację strumieniową, więc wiedzą, o czym mówią. Wersja 2.0 zostanie wkrótce wydana.

Przygotuj się na najgorszą sytuację, przeprowadź poważne testy, wyciągając wtyczkę z gniazdka sieciowego i sieciowego! Kiedy coś pójdzie nie tak, wiele innych rzeczy już poszło nie tak i ugryzie cię w plecy, gdy nie możesz sobie na to pozwolić.

Replikacja to jedno, działające przełączanie awaryjne po poważnych problemach to inna sprawa.


1

Korzystamy jednocześnie z dwóch różnych rozwiązań ...

Pgpool-II do synchronicznej replikacji i Slony2 do asynchronicznej (wyzwalanej) replikacji.

Wydajność jest doskonała


Dziękuję za odpowiedź ... Właściwie próbuję Pgpool-II z replikacją strumieniową. Zapewnia automatyczne przełączanie awaryjne. Ale jeśli ponownie uruchomię główny węzeł, czy pgpool-II uruchomi się ponownie jako główny lub węzeł rezerwowy?
Saurabh

O ile wiem zdecydowanie nie. będziesz musiał ręcznie przywrócić główny węzeł. Nasza konfiguracja jest nieco inna. jest to środowisko wielozadaniowe, a wszystkie węzły mają równe prawa. Jeśli jeden węzeł przestanie być zsynchronizowany, moduły równoważenia obciążenia odmawiają przekierowania klientów do tego węzła.
user5701
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.