Replikacja PostgreSQL

Cały czas robimy to w biurze, a pytanie wciąż się pojawia. Jak sobie radzisz z replikacją PostgreSQL? Nawet niekoniecznie mówię o zaawansowanych klastrach, po prostu upraszczając to w Master-Slave, Master-MultiSlave i Master-Master. Uważam, że ustawienie go w MySQL jest zazwyczaj dość proste. Przełączanie awaryjne jest proste, jeśli nie idealne, szczególnie ze względu na łatwość konfiguracji. Graliśmy ze Slony, ale jest to trochę zbyt praktyczne (zmiany schematu wymagają interwencji, nowe bazy danych wymagają interwencji itp.). PGPool2 był całkiem fajny, dopóki nie zepsuł się węzeł i nie mogliśmy znaleźć wdzięcznego sposobu (oprócz sprowadzenia wszystkiego i zresetowania upadłego węzła), aby odzyskać synchronizację. Zasadniczo oto, czego zwykle szukam:

• Łatwa konfiguracja (zadowolę się trudną konfiguracją, ale łatwo ją rozszerzyć)
• Uproszczone przełączanie awaryjne
• Ponowne sprowadzenie upadłego węzła wymaga tylko czasu (tj. Jak mysql. Serwer się psuje, uruchamiasz go i czekasz na odtworzenie replikacji)
• Zmiany schematu nie przerywają replikacji
• Dodanie nowej bazy danych do serwera jest bezproblemowe (tj. Tak jak mysql, możesz replikować cały serwer DB, więc nowa baza danych jest tworzona w systemie nadrzędnym, automatycznie propaguje się do urządzenia podrzędnego)

MySQL radzi sobie z większością z nich dość dobrze, ale podoba mi się PostgreSQL. Poza tym mamy kilka sytuacji, w których jest to nasza jedyna opcja, i chcielibyśmy dodać replikę do miksu. Czego obecnie używasz i co sądzisz o swoim rozwiązaniu? Obiecuję, że to nie jest post MySQL kontra PostgreSQL, ponieważ nie o to staram się zacząć. :)

Krótka odpowiedź - nie ma jeszcze takiego rozwiązania dla PostgreSQL, jeśli potrzebujesz online niewolników tylko do odczytu.

Obecnie w PostgreSQL 9.0 (Wiosna / Lato 2010) realizowane są dwa duże projekty rozwojowe w tym obszarze:

• Synchroniczna replikacja:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

• Tylko do odczytu w trybie gotowości niewolników:

http://wiki.postgresql.org/wiki/Hot_Standby

które w połączeniu mają na celu zapewnienie łatwości użycia replikacji w stylu MySQL bez błędów / problemów MySQL oraz niezawodności znanej użytkownikom z PostgreSQL.

Wszystko to zostało zainicjowane przez manifest z zespołu podstawowego PostgreSQL w 2008 roku:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Rozwiązania do replikacji PostgreSQL do dziś z największą bazą użytkowników to Slony-I (droższe dla zapisów, wprowadza zmiany schematu fiddly), WAL shipping / walmgr (niewolników nie można używać online) i pgQ / londiste z Skype / Skytools ( więcej narzędzi / elementów konstrukcyjnych niż gotowe rozwiązanie).

Napisałem kilka rzeczy na temat Log Shipping, Walmgr i Slony-I, rozumiesz

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20, aby uzyskać więcej informacji.

I wrzucić inne rozwiązanie do ringu: rubyrep.

Aby porównać ze swoimi wymaganiami:

• Łatwa konfiguracja
  Tak, to właściwie główny cel Rubyrep.
• Uproszczone przełączanie awaryjne
  Tak. W rzeczywistości Rubyrep wykonuje replikację master-master - aby przełączyć się w tryb failover, żadne działanie nie jest konieczne. Po prostu zacznij korzystać z innej bazy danych.
• Zmiany schematu nie przerywają replikacji
  Tak.
  W przypadku zmian kluczy innych niż podstawowe replikacja nawet nie musi się zatrzymywać (ale upewnij się, że schemat zmienia się po obu stronach jednocześnie)
  Aby dodać / usunąć tabele, po prostu zrestartuj demona replikacji. Tylko zmiana kolumny klucza podstawowego tabeli wymaga trochę wysiłku.
• Dodanie nowej bazy danych do serwera jest bezproblemowe (tzn. Tak jak mysql, możesz replikować cały serwer DB, więc nowa baza danych jest tworzona w systemie nadrzędnym, automatycznie propaguje się do urządzenia podrzędnego).
  Jest to obsługiwane tylko w ograniczony sposób: każdy rubyrep Instalator replikuje tylko jedną bazę danych na raz. (Ale konfiguracja replikacji dla więcej niż jednej bazy danych jest bardzo łatwa).

Nie wspominałeś o posiadaniu gorącego read-slave jako wymogu, więc zamierzam zaproponować użycie Heartbeat z pamięcią współdzieloną lub DRBD. Po prostu robi to dobrze, a administracja to pestka. Jest to odpowiednik starszych klastrów Microsoft SQL Server dla systemu Linux. Jeden węzeł jest aktywny, a drugi jest pasywny, podczas gdy dane są dzielone między dwoma. Nie musisz się martwić replikacją opartą na SQL, ponieważ wszystko jest obsługiwane niżej na poziomie bloku.

Poważnie, jest to zdecydowanie najlepsze rozwiązanie, jeśli nie potrzebujesz czytać niewolników. Materiały archiwalne WAL były w najlepszym razie hokey i musisz wszystko skonfigurować ponownie, jeśli kiedykolwiek zakłócisz proces wysyłki w celu ponownego uruchomienia serwera. slony i londiste nie przecinają musztardy. Jeśli chcesz pozostać na głównym drzewie źródeł i nie komercyjnie, Heartbeat jest najlepszym wyborem.

Z twoich wymagań wynika, że ​​PITR jest najprostszym sposobem rozwiązania problemu:

Kopie zapasowe online i odzyskiwanie w określonym momencie (PITR)

Nie powiedziałeś, że musisz zapytać o serwer podrzędny, więc PITR może mieć rację.

Jest to standardowa część PostgreSQL od wersji 8.0, więc prawdopodobnie masz już wszystko, czego potrzeba, aby go uruchomić.

Jeśli instrukcje są zbyt szczegółowe, spójrz na SkyTools WalMgr, który sprawi, że proces tworzenia / przełączania awaryjnego do zadania w trybie gotowości do pracy w trybie gotowości w trybie awaryjnym będzie wymagał jednego polecenia.

W przypadku bardziej złożonych scenariuszy replikacji miałem dobre doświadczenia ze Slony-1, ale PostgreSQL ma wiele dobrych opcji replikacji / HA.

Jeśli chcesz asynchroniczną replikację master / slave, rozważ Londiste (część pakietu skytools ze Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Jest łatwy w instalacji, dodanie nowego DB jest łatwe, replikacja po prostu „łapie”.

Przełączanie awaryjne nie jest jednak wbudowane. Będziesz musiał zmienić parametry połączenia aplikacji lub zaciemnić połączenie DB za inną warstwą oprogramowania.

Niektóre zmiany schematu są łatwe. Inne są trudniejsze. To zależy od twojej aplikacji. Następna wersja skytools (wersja 3.0) ma obsługiwać DDL i zawierać udogodnienia ułatwiające przełączanie awaryjne.

Przeprowadziliśmy się do Londiste po stwierdzeniu, że Slony jest zbyt bolesny w użyciu.

Zobacz dyskusję tutaj, może to może pomóc:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

i

Konkurenci do Bucardo Version One, znajdujący się niżej na stronie:

http://www.planetpostgresql.org/

Naprawdę nie ma żadnych darmowych / otwartych źródeł, aby zapewnić to, czego szukasz. Jeśli chcesz czegoś, co jest tak „pod klucz”, spójrz na różne komercyjne rozwiązania do replikacji innych firm.

Teraz możliwe jest zrolowanie własnej replikacji za pomocą Postgres przy użyciu wysyłki dziennika zapisu (WAL):

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Jest to w zasadzie miejsce, w którym można wprowadzić drugi węzeł w tryb ciągłego odzyskiwania i importować do niego dzienniki transakcji co {mały odstęp}. Konfiguracja Postgres ma „kody pośredniczące”, które pozwalają ci robić pewne rzeczy, gdy Postgres po ukończeniu WAL jest ukończony, więc nie, i na tym opiera się ta konfiguracja - wykorzystując te „kody pośredniczące”.

Nie pozwala to jednak na wykonywanie replikacji master-master i / lub cyklicznej.

W każdym razie zdecydowanie działa na erdundancję, ale nie nazwałbym tego „łatwą konfiguracją”, „uproszczonym przełączaniem awaryjnym”, „bezproblemową” lub czymkolwiek podobnym.

Oprócz „dodawania nowej bazy danych” możesz wypróbować Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). Jest open source, łatwy w konfiguracji i obsługuje przełączanie awaryjne. Główne ograniczenia to pojedyncza baza danych i brak możliwości replikacji zmian DDL, oba znajdują się na liście TODO.

Postgres-R wyglądał obiecująco, ale nie wiem, czy projekt wciąż żyje.

Obecnie patrzę na replikator wolframu, wciąż jestem daleki od jakichkolwiek ostatecznych wniosków, ale prawdopodobnie warto go zobaczyć.

www.continuent.com