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?
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ć.
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ą.