Rozplątanie aktualizacji PostgreSQL

PostgreSQL 9.6 został właśnie wydany i większość użytkowników postgresa zacznie zadawać sobie pytanie, jak dokonać aktualizacji do nowej głównej wersji. Ten post ma na celu pokazanie różnych procedur aktualizacji serwera PostgreSQL.

Aktualizacja do nowej wersji głównej to zadanie, które ma wysoki stosunek przygotowania do całkowitego czasu realizacji. Szczególnie podczas pomijania wydania w środku, na przykład podczas przechodzenia z wersji 9.3 do wersji 9.5.

Wydanie punktów

Z drugiej strony, aktualizacje wydania punktowego nie wymagają tak dużego przygotowania. Ogólnie rzecz biorąc, jedynym wymaganiem jest ponowne uruchomienie usługi postgres. Nie ma zmian w podstawowej strukturze danych, więc nie ma potrzeby zrzucania i przywracania. W najgorszym przypadku może być konieczne odtworzenie niektórych indeksów po zakończeniu aktualizacji wersji punktowej.

Bardzo mądrze jest zawsze pozostać przy najnowszym wydaniu punktowym, aby nie natknąć się na znany (i prawdopodobnie naprawiony) błąd. Oznacza to, że po wydaniu najnowszej wersji zaplanuj czas aktualizacji tak szybko, jak to możliwe.

Aktualizacja głównej wersji

Wykonując złożone zadania, takie jak to, dobrze jest rozważyć wszystkie możliwe opcje, aby osiągnąć ostateczny wynik.

W przypadku uaktualnień głównych wersji istnieją trzy możliwe ścieżki:

• Uaktualnij przywracanie z logicznego zrzutu
• Aktualizacja fizyczna
• Aktualizacja online

Pozwólcie, że wyjaśnię szczegółowo każdy z nich:

1) Przywracanie aktualizacji z logicznego zrzutu

To najprostszy ze wszystkich możliwych sposobów uaktualnienia struktury danych klastra.

Krótko mówiąc, proces tutaj wymaga logicznego zrzutu przy użyciu pg_dump ze starej wersji i pg_restore na czystym klastrze utworzonym z nowo zainstalowaną wersją.

Kluczowe punkty przemawiające za korzystaniem z tej ścieżki to:

• Najbardziej przetestowany
• Kompatybilność wraca do wersji 7.0, dzięki czemu możesz ostatecznie uaktualnić wersję 7.x do jednej z ostatnich wersji

Powody, dla których należy unikać korzystania z tej opcji:

• Całkowity przestój w dużych bazach danych może stanowić problem, ponieważ musisz zatrzymać zapisywanie połączeń przed uruchomieniem pg_dump;
• Jeśli w bazie danych znajduje się wiele dużych obiektów, pg_dump będzie działać wolno. Nawet robiąc to równolegle. Przywracanie będzie nawet wolniejsze niż pg_dump, gdy w bazie danych przechowywanych jest wiele dużych obiektów;
• Wymaga podwójnego miejsca na dysku lub usunięcia starego klastra przed przywróceniem;

Na serwerach z kilkoma rdzeniami procesora możliwe jest równoległe uruchomienie pg_dump przy użyciu formatu katalogu. Po zakończeniu przywracaj również równolegle, używając przełącznika -j zarówno w pg_dump, jak i pg_restore. Ale nie możesz rozpocząć procesu przywracania, dopóki cały zrzut się nie skończy.

2) Ulepszenie fizyczne

Tego rodzaju uaktualnienia są dostępne od wersji 9.0 i umożliwiają wykonywanie uaktualnień w miejscu od wersji tak starych jak 8.3. Nazywa się je „na miejscu”, ponieważ są wykonywane na tym samym serwerze, a najlepiej w tym samym katalogu danych.

Zalety tego rodzaju ulepszeń:

• Nie potrzebujesz miejsca na kolejną kopię klastra.
• Przestój jest znacznie krótszy w porównaniu z używaniem pg_dump.

Istnieje kilka wad:

• Po uruchomieniu nowej wersji PostgreSQL nie ma możliwości powrotu do starej wersji (od tego momentu klaster będzie działał tylko z nową wersją).
• Statystyki są zerowane po aktualizacji, więc zaraz po uruchomieniu nowej wersji PostgreSQL należy przeprowadzić analizę całego klastra.
• W ciągu ostatnich lat znaleziono wiele błędów dotyczących pg_upgrade, co sprawia, że ​​niektórzy administratorzy baz danych niechętnie korzystają z tej metody do aktualizacji.
• Niektórzy ludzie mieli problemy z pominięciem głównego wydania, na przykład przejściem z wersji 9.2 do wersji 9.4.
• W przypadku dużych katalogów będzie działać słabo (klastry z wieloma bazami danych lub bazy danych z wieloma tysiącami obiektów).

Możesz także uruchomić pg_upgrade bez opcji –link (w tym przypadku pg_upgrade wygeneruje drugą kopię na dysku twojego klastra), dzięki czemu będziesz mógł wrócić do starej wersji. Ale stracisz obie wymienione powyżej zalety.

3) Aktualizacja on-line

Procedura dla tej metody wyglądałaby następująco:

1. Zainstaluj obie wersje, aby działały równolegle. Można to zrobić na tym samym serwerze lub przy użyciu dwóch serwerów fizycznych.
2. Utwórz początkową kopię i zreplikuj zmiany od momentu, w którym uruchomiłeś kopię w węźle źródłowym (byłoby to podobne do początkowego pg_dump).
3. Kontynuuj logiczne replikowanie zmian, aż opóźnienie będzie bliskie zeru.
4. Przekieruj informacje o połączeniu z serwera aplikacji, aby połączyć się z nowym serwerem.

Ten rodzaj aktualizacji był dostępny od czasu, gdy pojawiły się pierwsze rozwiązania replikacji oparte na wyzwalaczach. Innymi słowy, odkąd Slony-I był w pobliżu.

Rozwiązania replikacji oparte na wyzwalaczach nie mają znaczenia, którą wersję posiadasz po jednej lub drugiej stronie, ponieważ kopiuje zmiany za pomocą obsługiwanych poleceń SQL.

Zalecane narzędzia replikacji oparte na wyzwalaczach, w kolejności, w jakiej się pojawiają, to:

1. Skytools:PgQ + londiste
2. Slony-I

To powinien być preferowany sposób aktualizacji. Zobaczmy zalety korzystania z tej metody:

• Zero przestojów!
• Świetne również do aktualizacji do nowszego sprzętu.
• Testowanie klastra on-line z nową wersją (zapytania tylko do odczytu lub możesz skończyć z konfliktami).
• Zmniejsza wszystkie rozrosty tabel i indeksów.

Są pewne wady:

• Potrzebuje podwójnej przestrzeni do przechowywania, ponieważ musi przechowywać drugą kopię twoich danych.
• Ponieważ jest oparty na wyzwalaczach, system musi zapisywać każdą zmianę dwukrotnie, co oznacza, że ​​na serwerze źródłowym będzie więcej dyskowych operacji we/wy (stara wersja klastra).
• Wszystkie tabele muszą mieć klucz podstawowy, więc narzędzie replikacji może indywidualizować aktualizowane lub usuwane krotki
• Nie replikuje tabel katalogu, więc nie będzie replikować dużych obiektów.
• Podstawowe użycie nie obejmuje zmian schematu. Można to zrobić, ale nie w sposób przejrzysty.

Nowa granica z pglogiką

Od PostgreSQL 9.4 mamy logiczne dekodowanie logów transakcji. Oznacza to, że teraz możemy dekodować transakcje z WAL i manipulować danymi wyjściowymi.

W dziedzinie replikacji pojawił się zupełnie nowy świat możliwości. Wyzwalacze nie są już potrzebne do wykonania logicznej replikacji!

Zasadniczo oznacza to, że nie musisz już zapisywać oddzielnej kopii wszystkich wstawek, aktualizacji i usunięć za pomocą wyzwalaczy. Możesz po prostu uzyskać te operacje manipulacji danymi z dzienników transakcji, dekodując je. Następnie to narzędzie, którego używasz, musi manipulować danymi wyjściowymi i wysyłać je do subskrybowanego węzła niższego szczebla. W tym przypadku jest to narzędzie pglogiczne.

Co to wszystko oznacza?

Cóż, jeśli korzystasz z wersji 9.4 lub 9.5 PostgreSQL i chcesz uaktualnić do wersji 9.6, możesz przeprowadzić aktualizację online, taką jak ta opisana powyżej, ale używając pglogical zamiast jednego z rozwiązań replikacji opartych na wyzwalaczach.

Nie będę wchodzić w szczegóły, ponieważ istnieją inne blogi na ten konkretny temat, takie jak ten napisany przez Petra Jelinka:Pakiety PGLogical 1.1 dla PostgreSQL 9.6beta1

Wnioski

W zależności od schematu bazy danych, rozmiaru danych, możliwego okresu przestoju, wersji bieżącej instalacji PostgreSQL możesz wybrać jedną opcję zamiast innej lub inną, która najlepiej pasuje.

• Jeśli Twoja baza danych jest mała i istnieje odpowiednie okno konserwacji, z którego możesz skorzystać, możesz zdecydować się na uruchomienie pg_dump i pg_restore. W zależności od rozmiaru zestawu danych istnieje punkt, w którym opcja nie jest już możliwa.
• Jeśli masz dużą bazę danych (kilkaset GB lub nawet TB danych), będziesz musiał poszukać innych opcji, takich jak uaktualnienie w miejscu za pomocą pg_upgrade lub uaktualnienie online.
  • W przypadku aktualizacji z wersji 8.3 lub nowszej do dowolnej wersji 9.x możesz użyć pg_upgrade.
  • W przypadku wersji starszych niż 8.3 musisz wybrać jedno z rozwiązań replikacji logicznej, takie jak londiste lub slony.
  • Jeśli na bazie danych 9.4 lub 9.5 lepiej jest użyć pglogical.

Zawsze pamiętaj, że do logicznej replikacji tabele muszą mieć klucz podstawowy.

Z pglogical ta reguła nie jest tak rygorystyczna:możesz replikować tabele tylko do wstawiania. Ale w przypadku aktualizacji i usuwania nadal konieczne jest posiadanie klucza podstawowego lub TOŻSAMOŚCI REPLIKI w tabeli.

Jeśli potrzebujesz pomocy przy aktualizacji bazy danych PostgreSQL, możesz sprawdzić usługi
2nd Quadrant Upgrade.