Już czas.
Około rok temu opublikowaliśmy PostgreSQL 10 z obsługą natywnej replikacji logicznej. Jednym z zastosowań replikacji logicznej jest umożliwienie uaktualniania pomiędzy głównymi wersjami PostgreSQL przy krótkim czasie lub bez przestojów. Do tej pory PostgreSQL 10 był jedynym wydaniem PostgreSQL z natywną replikacją logiczną, więc nie było zbyt wielu możliwości aktualizacji w ten sposób. (Replikacja logiczna może być również używana do przenoszenia danych między instancjami w różnych systemach operacyjnych lub architekturach procesora lub z różnymi ustawieniami konfiguracji niskiego poziomu, takimi jak rozmiar bloku lub ustawienia regionalne — jeśli chcesz, sidegrading). Teraz, gdy PostgreSQL 11 jest już blisko, będzie więcej powodów, aby skorzystać z tej funkcji.
Najpierw porównajmy trzy główne sposoby uaktualnienia instalacji PostgreSQL:
- pg_dump i przywróć
- pg_upgrade
- replikacja logiczna
Możemy porównać te metody pod względem niezawodności, szybkości, wymaganego czasu przestoju i ograniczeń (i więcej, ale musimy się gdzieś zatrzymać, by przeczytać ten artykuł).
pg_dump and restore jest prawdopodobnie najbardziej niezawodną metodą, ponieważ jest najbardziej przetestowana i jest używana od dziesięcioleci. Ma również bardzo niewiele ograniczeń, jeśli chodzi o to, co może obsłużyć. Możliwe jest konstruowanie baz danych, których nie można zrzucić i przywrócić, głównie z uwzględnieniem określonych relacji zależności między obiektami, ale są to rzadkie i zwykle wiążą się z odradzanymi praktykami.
Problem z metodą zrzutu i przywracania polega oczywiście na tym, że skutecznie wymaga przestoju przez cały czas wykonywania operacji zrzutu i przywracania. Podczas gdy źródłowa baza danych jest nadal dostępna do odczytu i zapisu podczas działania procesu, wszelkie aktualizacje źródłowej bazy danych po rozpoczęciu zrzutu zostaną utracone.
pg_upgrade usprawnia proces pg_dump poprzez bezpośrednie przenoszenie plików danych bez konieczności zrzucania ich do logicznej postaci tekstowej. Zauważ, że pg_upgrade nadal używa wewnętrznie pg_dump do kopiowania schematu, ale nie danych. Kiedy pg_upgrade był nowy, jego solidność była kwestionowana i niepoprawnie aktualizował niektóre bazy danych. Ale pg_upgrade jest teraz dość dojrzały i dobrze przetestowany, więc nie trzeba już się wahać przed użyciem go z tego powodu. Podczas działania pg_upgrade system bazy danych nie działa. Ale można dokonać wyboru, jak długo działa pg_upgrade. W domyślnym trybie kopiowania całkowity czas wykonywania składa się z czasu zrzutu i przywrócenia schematu (co zwykle jest bardzo szybkie, chyba że masz tysiące tabel lub innych obiektów) oraz czasu kopiowania plików danych, co zależy od jak duża jest baza danych (oraz system we/wy, system plików itp.).
W opcjonalnym trybie łączenia pliki danych są zamiast tego sztywno połączone z nowym katalogiem danych, tak że czas jest jedynie czasem na wykonanie krótkiej operacji jądra na pliku zamiast kopiowania każdego bajtu. Wadą jest to, że jeśli coś pójdzie nie tak z aktualizacją lub będziesz musiał wrócić do starej instalacji, ta operacja zniszczy twoją starą bazę danych. (Pracuję nad najlepszym z obu światów rozwiązaniem dla PostgreSQL 12 przy użyciu reflinków lub operacji klonowania plików w obsługiwanych systemach plików.)
Replikacja logiczna jest najnowszą z tej grupy, więc prawdopodobnie zajmie trochę czasu, aby rozwiązać problemy. Jeśli nie masz czasu na eksplorację i badanie, może to nie być w tej chwili droga. (Oczywiście ludzie od wielu lat używają innych niezwiązanych z podstawowymi rozwiązaniami replikacji logicznej, takich jak Slony, Londiste i pglogical, do aktualizacji PostgreSQL, więc istnieje duże doświadczenie z zasadami, jeśli nie ze szczegółami.)
Zaletą korzystania z replikacji logicznej do uaktualniania jest to, że aplikacja może nadal działać na starej instancji podczas synchronizacji danych. Wystarczy tylko niewielka przerwa, gdy połączenia klientów zostaną przełączone. Tak więc, chociaż aktualizacja przy użyciu replikacji logicznej jest prawdopodobnie wolniejsza od początku do końca niż użycie pg_upgrade w trybie kopiowania (i zdecydowanie wolniej niż użycie trybu twardego łącza), nie ma to większego znaczenia, ponieważ rzeczywisty czas przestoju może być znacznie krótszy.
Należy zauważyć, że replikacja logiczna obecnie nie replikuje zmian schematu. W tej proponowanej procedurze uaktualniania schemat jest nadal kopiowany za pośrednictwem pg_dump, ale kolejne zmiany schematu nie są przenoszone. Aktualizacja z replikacją logiczną ma również kilka innych ograniczeń. Niektóre operacje nie są przechwytywane przez replikację logiczną:duże obiekty, OBCIĄŻENIE, zmiany sekwencji. Obejścia tych problemów omówimy później.
Jeśli masz jakieś fizyczne rezerwy (a jeśli nie, to dlaczego nie?), istnieją również pewne różnice, które należy wziąć pod uwagę między metodami. W przypadku obu tych metod należy zbudować nowe fizyczne rezerwy dla zaktualizowanej instancji. Dzięki zrzutom i przywracaniu oraz replikacji logicznej można je wdrożyć przed rozpoczęciem uaktualniania, dzięki czemu stan gotowości będzie w większości gotowy po zakończeniu początkowej synchronizacji przywracania lub replikacji logicznej, z zastrzeżeniem opóźnienia replikacji.
Dzięki pg_upgrade nowe rezerwy muszą zostać utworzone po zakończeniu aktualizacji podstawowego. (Dokumentacja pg_upgrade opisuje to bardziej szczegółowo.) Jeśli polegasz na fizycznych rezerwach w celu zapewnienia wysokiej dostępności, rezerwy powinny być dostępne przed przełączeniem na nową instancję, więc konfiguracja rezerw może wpłynąć na ogólne obliczenia czasu.
Wróćmy jednak do logicznej replikacji. Oto jak można przeprowadzić aktualizację z replikacją logiczną:
0. Stara instancja musi być przygotowana do replikacji logicznej. Wymaga to pewnych ustawień konfiguracyjnych opisanych w http://www.postgresql.org/docs/10/static/logical-replication-config.html (głównie wal_level = logical . Jeśli okaże się, że musisz wprowadzić te zmiany, będą one wymagały ponownego uruchomienia serwera. Więc sprawdź to z dużym wyprzedzeniem. Sprawdź również, czy pg_hba.conf na starej instancji jest skonfigurowany do akceptowania połączeń z nowej instancji. (Zmiana wymaga jedynie przeładowania.)
1. Zainstaluj nową wersję PostgreSQL. Potrzebujesz przynajmniej pakietu serwera i pakietu klienta, który zawiera pg_dump. Wiele opakowań pozwala teraz na instalowanie wielu wersji obok siebie. Jeśli korzystasz z maszyn wirtualnych lub instancji w chmurze, warto rozważyć zainstalowanie nowej instancji na nowym hoście.
2. Skonfiguruj nową instancję, czyli uruchom initdb. Nowa instancja może mieć inne ustawienia niż stara, na przykład lokalizacja, rozmiar segmentu WAL lub suma kontrolna. (Dlaczego nie skorzystać z tej okazji, aby włączyć sumy kontrolne danych?)
3. Przed uruchomieniem nowej instancji może być konieczna zmiana niektórych ustawień konfiguracyjnych. Jeśli instancja działa na tym samym hoście, co stara instancja, musisz ustawić inny numer portu. Przenieś również wszelkie niestandardowe zmiany, które wprowadziłeś w postgresql.conf na starej instancji, np. ustawienia pamięci, max_connections itp. Podobnie utwórz pg_hba.conf ustawienia odpowiednie dla Twojego środowiska. Zwykle możesz zacząć od skopiowania pliku pg_hba.conf plik ze starej instancji. Jeśli chcesz korzystać z SSL, skonfiguruj to teraz.
4. Uruchom nową (pustą) instancję i sprawdź, czy działa zgodnie z Twoimi oczekiwaniami. Jeśli konfigurujesz nową instancję na nowym hoście, sprawdź w tym momencie, czy możesz nawiązać połączenie z bazą danych (za pomocą psql) z nowego hosta do starej instancji bazy danych. Będziemy tego potrzebować w kolejnych krokach.
5. Skopiuj definicje schematu za pomocą pg_dumpall. (Lub możesz to zrobić za pomocą pg_dump dla każdej bazy danych osobno, ale nie zapomnij o obiektach globalnych, takich jak role).
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Wszelkie zmiany schematu po tym punkcie nie zostaną przeniesione. Musiałbyś sam nimi zarządzać. W wielu przypadkach możesz po prostu zastosować zmieniające się DDL na obu hostach, ale uruchamianie poleceń zmieniających strukturę tabeli podczas aktualizacji jest prawdopodobnie zbyt dużym wyzwaniem.
6. W każdej bazie danych w instancji źródłowej utwórz publikację, która przechwytuje wszystkie tabele:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Replikacja logiczna działa oddzielnie w każdej bazie danych, dlatego należy ją powtórzyć w każdej bazie danych. Z drugiej strony nie musisz aktualizować wszystkich baz danych naraz, więc możesz wykonywać tę jedną bazę na raz lub nawet nie aktualizować niektórych baz danych.
7. W każdej bazie danych w instancji docelowej utwórz subskrypcję, która subskrybuje właśnie utworzoną publikację. Pamiętaj, aby prawidłowo dopasować źródłową i docelową bazę danych.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Ustaw odpowiednie parametry połączenia.
8. Teraz czekasz, aż subskrypcje skopiują początkowe dane i w pełni dogonią wydawcę. Możesz sprawdzić stan początkowej synchronizacji każdej tabeli w subskrypcji w katalogu systemowym pg_subscription_rel (poszukaj r =gotowe w kolumnie srsubstate ). Ogólny stan replikacji można sprawdzić w pg_stat_replication po stronie wysyłającej i pg_stat_subscription po stronie odbiorczej.
9. Jak wspomniano powyżej, zmiany sekwencji nie są replikowane. Jednym z możliwych obejścia tego problemu jest skopiowanie wartości sekwencji za pomocą pg_dump. Możesz uzyskać zrzut bieżących wartości sekwencji, używając czegoś takiego:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Zakłada się, że wszystkie nazwy sekwencji pasują do *_seq i żadne tabele nie pasują do tej nazwy. W bardziej skomplikowanych przypadkach możesz również przejść na ścieżkę tworzenia pełnego zrzutu i wyodrębnienia danych sekwencji ze spisu treści zrzutu.)
Ponieważ sekwencje mogą się rozwijać, gdy to robisz, być może munge seq-data.sql plik, aby dodać trochę luzu do liczb.
Następnie przywróć ten plik do nowej bazy danych za pomocą psql.
10. Showtime:Przełącz aplikacje do nowych instancji. To wymaga myślenia z wyprzedzeniem. W najprostszym scenariuszu zatrzymujesz aplikacje, zmieniasz ustawienia połączenia, restartujesz. Jeśli korzystasz z serwera proxy połączenia, możesz tam przełączyć połączenie. Możesz także przełączać aplikacje klienckie jedna po drugiej, być może po to, aby trochę przetestować lub zmniejszyć obciążenie nowego systemu. Będzie to działać, o ile aplikacje nadal wskazują stary serwer, a te, które wskazują na nowy serwer, nie dokonują sprzecznych zapisów. (W takim przypadku uruchomiłbyś system multimaster, przynajmniej przez krótki czas, a to kolejny stopień złożoności).
11. Po zakończeniu aktualizacji możesz usunąć konfigurację replikacji. W każdej bazie danych w nowej instancji uruchom
DROP SUBSCRIPTION s_upgrade;
Jeśli już zamknąłeś starą instancję, zakończy się to niepowodzeniem, ponieważ nie będzie ona w stanie połączyć się ze zdalnym serwerem, aby usunąć gniazdo replikacji. Zobacz stronę podręcznika DROP SUBSKRYPCJA, aby dowiedzieć się, jak postępować w takiej sytuacji.
Możesz także upuścić publikacje na instancję źródłową, ale nie jest to konieczne, ponieważ publikacja nie zachowuje żadnych zasobów.
12. Na koniec usuń stare instancje, jeśli już ich nie potrzebujesz.
Kilka dodatkowych komentarzy na temat obejścia rzeczy, których nie obsługuje replikacja logiczna. Jeśli używasz dużych obiektów, możesz je przenieść za pomocą pg_dump, oczywiście pod warunkiem, że nie zmienią się podczas procesu aktualizacji. Jest to znaczne ograniczenie, więc jeśli intensywnie korzystasz z dużych obiektów, ta metoda może nie być dla Ciebie. Jeśli aplikacja zgłosi TRUNCATE podczas procesu uaktualniania, te działania nie zostaną zreplikowane. Być może możesz dostosować swoją aplikację, aby uniemożliwić jej robienie tego na czas aktualizacji, lub możesz zamiast tego zastąpić polecenie DELETE. PostgreSQL 11 obsługuje replikację TRUNCATE, ale będzie to działać tylko wtedy, gdy zarówno źródłowa, jak i docelowa instancja to PostgreSQL 11 lub nowszy.
Kilka komentarzy końcowych, które naprawdę odnoszą się do wszystkich przedsięwzięć modernizacyjnych:
- Aplikacje i wszystkie programy klienckie bazy danych powinny zostać przetestowane pod kątem nowej głównej wersji PostgreSQL przed wprowadzeniem do produkcji.
- W tym celu należy również przetestować procedurę aktualizacji przed wykonaniem jej w środowisku produkcyjnym.
- Zapisz lub ulepsz skrypt i zautomatyzuj jak najwięcej.
- Upewnij się, że konfiguracja kopii zapasowych, systemy monitorowania oraz wszelkie narzędzia i skrypty konserwacyjne są odpowiednio dostosowane podczas procedury aktualizacji. Najlepiej byłoby, gdyby były one na miejscu i zweryfikowane przed dokonaniem przełączenia.
Mając to na uwadze, życzę powodzenia i podziel się swoimi doświadczeniami.
