Czy produkcja replikacji PostgreSQL jest gotowa?

Jak natywna replikacja PostgreSQL wypada w porównaniu z MySQL?

Wiem, że asynchroniczna replikacja jest obsługiwana dłużej niż synchronizacja, która jest najnowsza. Czy synchroniczny jest niezawodny do zastosowania w prawdziwych projektach?

Produkcja gotowa?

Tak, jest gotowy do produkcji i szeroko stosowany. Obserwatorzy Heroku bazują na przykład na wbudowanej replikacji asynchronicznej PostgreSQL, podobnie jak standby AWS RDS i repliki odczytu. Replikacja strumieniowa jest używana prawie powszechnie w PostgreSQL.

Konfiguracja replikacji nie jest do końca piękna, ale narzędzia takie jak repmgr nieco w tym pomagają i powoli się poprawiają z każdą większą wersją. Dużą pomocą jest możliwość pg_basebackup pobrania kopii systemu za pomocą replikacji strumieniowej (i zrobienia tego z innego trybu gotowości).

Ogólnie rzecz biorąc, funkcja po prostu nie zostanie wydana w PostgreSQL, dopóki nie będzie gotowa do produkcji. Błędy zdarzają się, jak w każdym oprogramowaniu, ale zazwyczaj są usuwane wkrótce po ich zidentyfikowaniu. Naprawdę ważne nowe funkcje czasami zawierają błędy i problemy wykryte po wydaniu wersji .0, ale jeśli tak, naprawienie ich ma wysoki priorytet; błędy nie są po prostu pozostawione.

Nie znam żadnych poważnych problemów z replikacją strumieniową - synchronizacją lub asynchronizacją - nie widziałem też żadnych zgłoszeń przez dłuższy czas. Były mniej stabilne niż zwykły standard Pg w wydaniach .0 głównych wersji, w których zostały wprowadzone, ale oba dojrzewały szybko i są całkowicie gotowe do produkcji.

(Aktualizacja: w nowej wersji 9.3 przed 9.3.4 pojawił się konkretny błąd, który w niektórych przypadkach powodował problemy z replikacją; użytkownicy wersji 9.3 powinni natychmiast zaktualizować do wersji 9.3.4. Nie dotyczy to starszych wersji).

Jedynym zastrzeżeniem, o którym chciałbym wspomnieć, jest drobny szczegół z synchroniczną replikacją: jeśli zatwierdzasz w systemie głównym, anuluj zapytanie po jego zatwierdzeniu podczas oczekiwania na potwierdzenie, replika jest traktowana jako zatwierdzona w systemie głównym, zanim zostanie zreplikowana. Ten sam efekt uzyskuje się poprzez ponowne uruchomienie wzorca podczas oczekiwania na odpowiedź repliki. W praktyce jest to nieistotne, ale dotyczy jedynego problemu, jaki mogę wymyślić.

Porównaj z MySQL?

Natywna replikacja Pg jest zupełnie inna niż MySQL.

MySQL używa logicznej replikacji, gdzie wysyła logiczne zmiany dokonane w danych tabeli, strukturze tabeli itp., A replika stosuje te zmiany.

Replikacja PostgreSQL ma niższy poziom (w wersji 9.5 i niższej; przyszłe wersje mogą również dodawać replikę logiczną). Wysyła bloki, które zmieniły się w tabelach. Jest to prostsze, łatwiejsze do poprawnego działania i nakłada mniejsze obciążenie na serwer repliki, ale zużywa większą przepustowość sieci i wymaga więcej pamięci w systemie nadrzędnym do przechowywania jeszcze nie zreplikowanych zmian. Najlepiej jest skonfigurować replikację strumieniową z rezerwową archiwizacją WAL, co sprawia, że ​​konfiguracja jest bardziej złożona niż MySQL. Replikuje zmiany niskiego poziomu, takie jak aktywność VACUUM, a nie tylko krotki zmiany, utrzymując stan repliki na dysku taki sam jak master. Nie jest w stanie replikować tylko jednej bazy danych; cały system musi zostać zreplikowany, co może być frustrujące, jeśli masz jedną dużą, mało wymagającą bazę danych o wysokiej rezygnacji i jedną małą, istotną bazę danych o niskiej rezygnacji.

W sumie zależy to od tego, co chcesz z tym zrobić.

Uważam, że replikacja PostgreSQL jest znacznie lepsza w przypadku replik używanych do tworzenia kopii zapasowych, wysokiej dostępności i odzyskiwania po awarii. Szczególnie w połączeniu z odzyskiem w czasie (PITR) .

Z drugiej strony nie jest tak dobry w przypadku replik raportujących tylko do odczytu, ponieważ potrzeba opóźnienia zastosowania zreplikowanych danych podczas wykonywania długich transakcji oznacza, że ​​musisz pozwolić mu anulować bardzo długie zapytania lub pozostawać w tyle za urządzeniem głównym, co pochłania więcej miejsca na dysku w systemie głównym i zmuszanie go do cięższej pracy, aby nadążyć.

Trwają prace nad włączeniem logicznej replikacji w PostgreSQL , gdzie logiczne zmiany w strukturze tabeli, zawartości tabeli itp. Są replikowane, a nie ich stan na dysku. Projekt katalogu Pg i wsparcie dla wszystkiego, co zdefiniowane przez użytkownika sprawia, że ​​jest to dość złożone zadanie. Część podstaw przygotowano dla wersji 9.4, ale pełna logiczna replikacja raczej nie będzie możliwa przed wersją 9.6 lub nowszą.