W zeszłym tygodniu byłem na Nordic PGDay 2018 i odbyłem sporo rozmów na temat narzędzia, które napisałem, a mianowicie pglupgrade , aby zautomatyzować aktualizacje głównych wersji PostgreSQL w konfiguracji klastra replikacji. Byłem bardzo szczęśliwy, że zostało to usłyszane, a kilka innych osób z różnych społeczności wygłaszało przemówienia na spotkaniach i innych konferencjach na temat prawie zerowych przestojów przy użyciu replikacji logicznej. Biorąc pod uwagę, że jest mowa, którą wygłosiłem na PGDAY'17 Rosja, PGConf.EU 2017 w Warszawie i wreszcie na FOSDEM PGDay 2018 w Brukseli, pomyślałem, że lepiej stworzyć post na blogu, aby udostępnić tę prezentację osobom, które mogłyby nie dostać się na żadną z wyżej wymienionych konferencji. Jeśli chcesz bezpośrednio przejść do rozmowy i pominąć czytanie tego wpisu na blogu, oto Twój link:Zautomatyzowane aktualizacje klastrów PostgreSQL w chmurze o niemal zerowym czasie przestoju
Główną motywacją do stworzenia tego narzędzia było zaproponowanie rozwiązania minimalizującego przestoje podczas głównych aktualizacji wersji, które niestety dotykają prawie każdego, kto korzysta z PostgreSQL. Obecnie nie mamy narzędzia, które pozwalałoby użytkownikom PostgreSQL na aktualizowanie baz danych bez przestojów i jest to oczywisty problem dla wielu użytkowników, zwłaszcza firm. A jeśli mamy rozwiązać problem z aktualizacją, powinniśmy pomyśleć o więcej niż jednym serwerze (od teraz będzie nazywany klastrem), po prostu dlatego, że niewiele osób korzysta już tylko z jednego serwera bazy danych. Najczęstszym scenariuszem jest konfiguracja fizycznej replikacji strumieniowej w celu zapewnienia wysokiej dostępności lub skalowania zapytań odczytu.
Aktualizacje bazy danych
Zanim zagłębimy się w rozwiązanie, porozmawiajmy trochę o tym, jak ogólnie działają aktualizacje baz danych. Istnieją cztery główne możliwe podejścia do aktualizacji bazy danych:
- Pierwsze podejście polegałoby na utrzymywaniu przez bazy danych tego samego formatu przechowywania lub przynajmniej zgodności we wszystkich wersjach. Jest to jednak trudne do zagwarantowania na dłuższą metę, ponieważ nowe funkcje mogą wymagać zmian w sposobie przechowywania danych lub dodania większej liczby informacji o metadanych, aby działały poprawnie. Ponadto wydajność jest często poprawiana przez optymalizację struktur danych.
- Drugim podejściem jest wykonanie logicznej kopii (zrzutu) starego serwera i załadowanie go na nowy serwer. Jest to najbardziej tradycyjne podejście, które wymaga, aby stary serwer nie otrzymywał żadnych aktualizacji podczas procesu i powoduje przedłużone przestoje godzin, a nawet dni w dużych bazach danych.
- Trzecia opcja to konwersja danych ze starego formatu na nowy. Można to zrobić w locie, gdy nowy system jest uruchomiony, ale wiąże się to z obniżeniem wydajności, które jest trudne do przewidzenia, ponieważ zależy to od wzorców dostępu do danych, lub można to zrobić w trybie offline, gdy serwery nie działają, co ponownie wiąże się z przedłużonym przestoje (chociaż często krótsze niż druga metoda).
- Czwartą metodą jest użycie zrzutu logicznego do zapisywania i przywracania bazy danych podczas przechwytywania zmian zachodzących w międzyczasie i logicznie replikuje je do nowej bazy danych po zakończeniu początkowego przywracania. Ta metoda wymaga orkiestracji kilku komponentów, ale także skraca czas, przez który baza danych nie może odpowiadać na zapytania.
Metody aktualizacji w PostgreSQL
Aktualizacje PostgreSQL można dopasować za pomocą czterech wymienionych powyżej metod. Na przykład mniejsze wersje PostgreSQL, które nie zawierają nowych funkcji, a jedynie poprawki, nie zmieniają istniejącego formatu danych i pasują do pierwszego podejścia. W przypadku drugiego podejścia PostgreSQL udostępnia narzędzia o nazwie pg_dump i pg_restore, które wykonują logiczne tworzenie kopii zapasowych i przywracanie. Istnieje również narzędzie pg_upgrade (było to moduł contrib i zostało przeniesione do głównego drzewa PostgreSQL 9.5), które dokonuje konwersji offline (serwery nie są uruchomione) starego katalogu danych do nowego, co może zmieścić się w trzeciej opcji. W przypadku czwartego podejścia istnieją rozwiązania oparte na wyzwalaczach innych firm, takie jak Slony do aktualizacji, ale mają one pewne zastrzeżenia, które omówimy później.
Tradycyjne metody aktualizacji mogą tylko uaktualnij serwer główny, podczas gdy serwery replik muszą zostać później odbudowane (konwersja offline) . Prowadzi to do dodatkowych problemów zarówno z dostępnością, jak i pojemnością klastra, co skutecznie zwiększa postrzegany czas przestoju bazy danych zarówno z punktu widzenia aplikacji, jak i użytkowników. Replikacja logiczna pozwala na replikację gdy system jest działający w międzyczasie można zająć się testowaniem (konwersja online) .
Istnieją różne metody aktualizacji mające zastosowanie do różnych środowisk. Na przykład pg_dump umożliwia aktualizację z bardzo starych wersji (np. 7.0) do ostatnich wydań, więc jeśli używasz starej wersji PostgreSQL, najlepszą metodą jest użycie pg_dump/restore (i lepiej zrób to teraz!). Jeśli twoja wersja PostgreSQL to wersja 8.4 lub nowsza możesz użyć pg_upgrade . Jeśli używasz PostgreSQL 9.4 i nowsze oznacza to, że masz podstawowe „Dekodowanie logiczne” i możesz użyć pglogicznego rozszerzenie jako środek uaktualnienia. Wreszcie, jeśli używasz PostgreSQL 10 , będziesz mieć możliwość uaktualnienia bazy danych do PostgreSQL 11 i nowszych (gdy będą dostępne) za pomocą wbudowanej „Replikacji logicznej” (tak!).
Replikacja logiczna dla uaktualnień
Skąd pomysł na aktualizację PostgreSQL przy użyciu replikacji logicznej pochodzi?Oczywiście, pglogical nie twierdzi otwarcie celu aktualizacji, jak pg_upgrade robi (to był jeden z argumentów przeciwko pglogikowi na przyjęciu konferencyjnym ), ale to nie znaczy, że nie możemy używać tego narzędzia do aktualizacji. W rzeczywistości, kiedy projektowano pglogical, aktualizacje prawie zerowe przestojów były uważane za jeden z oczekiwanych przypadków użycia przez twórców rozszerzenia.
W przeciwieństwie do replikacji fizycznej, która przechwytuje zmiany w surowych danych na dysku, replikacja logiczna przechwytuje zmiany logiczne poszczególnych rekordów w bazie danych i replikuje je. Rekordy logiczne działają we wszystkich głównych wydaniach , stąd replikacja logiczna może być użyta do uaktualnienia z jednego wydania do drugiego. Pomysł wykorzystania replikacji logicznej jako sposobu uaktualniania wersji jest daleki od bycia nowym, narzędzia replikacji oparte na wyzwalaniu wykonują aktualizacje w logiczny sposób, przechwytując i wysyłając zmiany za pomocą wyzwalaczy (ponieważ wyzwalacze mogą działać również niezależnie od wersji bazy danych! ).
Jeśli możesz używać rozwiązań replikacji opartej na wyzwalaczach w celu minimalizacji przestojów, dlaczego zamiast tego preferujesz replikację logiczną? W mechanizmie opartym na wyzwalaczach wszystkie zmiany są przechwytywane za pomocą wyzwalaczy i zapisywane w tabelach kolejek. Ta procedura podwaja operacje zapisu, podwaja pliki dziennika i spowalnia system, ponieważ wszystkie zmiany muszą być zapisywane dwukrotnie; co skutkuje większą liczbą operacji we/wy na dysku i obciążeniem serwera źródłowego. W przeciwieństwie do tego, replikacja logiczna w rdzeniu (to samo dotyczy rozszerzenia pglogicznego) jest zbudowana na podstawie logicznego dekodowania. Dekodowanie logiczne to mechanizm, który wyodrębnia informacje z plików WAL do logicznych zmian (WSTAW/AKTUALIZUJ/USUŃ). Ponieważ dane z mechanizmu WAL są wykorzystywane do dekodowania dzienników transakcji, nie ma wzmocnienia zapisu tak jak w przypadku rozwiązań replikacji opartych na wyzwalaczach, stąd ta metoda działa lepiej . W rezultacie rozwiązania oparte na dekodowaniu logicznym mają po prostu mniejszy wpływ na system niż rozwiązania oparte na wyzwalaczach.
Wniosek
W tym wpisie wprowadzającym chciałem wyjaśnić, dlaczego powinniśmy rozważyć użycie replikacji logicznej, aby zminimalizować przestoje podczas uaktualniania głównych wersji. Będziemy kontynuować szczegóły architektury i implementacji narzędzia w nadchodzącym poście.
