Aktualny stan zarządzania kopiami zapasowymi Open Source dla PostgreSQL

Istnieje wiele sposobów na zajęcie się wykonywaniem kopii zapasowych klastra PostgreSQL. Istnieje kilka artykułów i blogów, które prezentują różne technologie, dzięki którym możemy zapisywać nasze cenne dane w PostgreSQL. Istnieją logiczne rozwiązania do tworzenia kopii zapasowych, fizyczne kopie zapasowe na poziomie systemu operacyjnego, na poziomie systemu plików i tak dalej. W tym blogu nie będziemy omawiać części teoretycznej, która jest odpowiednio opisana na różnych blogach i artykułach, a także w oficjalnej dokumentacji.

Ten blog koncentruje się na stanie różnych dostępnych narzędzi i rozwiązań oraz stara się przedstawić dokładne porównanie oparte na doświadczeniach z życia codziennego. Ten artykuł w żaden sposób nie stara się promować żadnego konkretnego produktu, bardzo podobają mi się wszystkie narzędzia, rozwiązania i technologie opisane na tym blogu. Celem jest tutaj zanotowanie ich mocnych i słabych stron oraz wskazanie użytkownikowi końcowemu, które narzędzie najlepiej pasuje do jego środowiska, infrastruktury i konkretnych wymagań. Oto fajny artykuł opisujący narzędzia do tworzenia kopii zapasowych dla PostgreSQL na różnych poziomach.

Nie będę opisywał, jak korzystać z różnych narzędzi na tym blogu, ponieważ te informacje są udokumentowane na powyższym blogu, a także w oficjalnych dokumentach oraz innych zasobach w sieci. Ale opiszę plusy i minusy, jakich doświadczyłem w praktyce. W tym blogu zajmujemy się wyłącznie klasycznymi fizycznymi kopiami zapasowymi PostgreSQL opartymi na PITR, w zależności od:

• pg_basebackup lub pg_start_backup()/pg_stop_backup
• fizyczna kopia
• archiwizacja WAL-ów lub replikacja strumieniowa

Istnieje kilka doskonałych produktów i rozwiązań, niektóre są open source i można ich używać bezpłatnie, podczas gdy inne są komercyjne. Według mojej najlepszej wiedzy są to:

• pgbarman przez 2ndquadrant (bezpłatny)
• pgbackrest (bezpłatny)
• pg_probackup autorstwa Postgres Professional (bezpłatny)
• BART od EDB (komercyjny)

Nie miałem okazji wypróbować BART, ponieważ działa on na wersjach Linuksa, których nie używam. W tym blogu uwzględnię własne przemyślenia i wrażenia podczas interakcji z odpowiednimi autorami/społecznością/opiekunami każdego rozwiązania, ponieważ jest to bardzo ważny aspekt, który na początku jest zwykle niedoceniany. Trochę terminologii, aby lepiej zrozumieć różne terminy w każdym z narzędzi:

pgbarman

Pgbarman lub po prostu barman to najstarsze z tych narzędzi. Najnowsza wersja to 2.6 (wydana, gdy pracowałem nad tym blogiem!, co jest świetną wiadomością).

Pgbarman obsługuje kopię zapasową bazy na dwa sposoby:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

i transfer WAL przez:

• Archiwizacja WAL
  • przez rsync
  • przez barman-wal-archive / put-wal
• WAL przez replikację strumieniową z gniazdem replikacji
  • Asynchroniczny
  • Synchroniczne

Daje nam to 8 nieszablonowych kombinacji, dzięki którym możemy użyć barmana. Każdy ma swoje wady i zalety.

Podstawowa kopia zapasowa przez pg_basebackup (backup_method =postgres)

Plusy:

• najnowszy/nowoczesny sposób
• opiera się na sprawdzonej podstawowej technologii PostgreSQL
• zalecane przez oficjalne dokumenty

Minusy:

• brak przyrostowej kopii zapasowej
• brak kopii zapasowej równoległej
• brak kompresji sieci
• brak deduplikacji danych
• brak limitu przepustowości sieci

Podstawowa kopia zapasowa przez rsync (backup_method =rsync)

Plusy:

• stary i sprawdzony
• Przyrostowa kopia zapasowa
• deduplikacja danych
• kompresja sieci
• równoległa kopia zapasowa
• limit przepustowości sieci

Minusy:

• nie zalecany (przez autorów) sposób

Przesyłanie WAL przez archiwizację WAL (przez rsync)

Plusy:

• prostsze w konfiguracji

Minusy:

• Brak RPO=0 (zero utraty danych)
• brak możliwości odzyskania sprawności po długich i utrzymujących się awariach sieci

Przeniesienie WAL przez archiwizację WAL (przez barman-wal-archive / put-wal)

Plusy:

• najnowszy i zalecany sposób (wprowadzony w 2.6)
• bardziej niezawodny/bezpieczny niż rsync

Minusy:

• Brak RPO=0 (zero utraty danych)
• nadal nie ma możliwości odzyskania sprawności po długich i utrzymujących się awariach sieci

Transfer WAL przez strumieniowanie WAL ze slotem replikacji (przez pg_receivewal)

Plusy:

• bardziej nowoczesny (i polecany)
• RPO=0 (zero utraty danych) w trybie synchronicznym

Minusy:

• zawsze powiązane z gniazdem replikacji. Może rosnąć w przypadku awarii sieci

Tak więc, podczas gdy pg_basebackup (metoda postgres) wydaje się być przyszłością dla pgbarmana, w rzeczywistości wszystkie fantazyjne funkcje są dostarczane z metodą rsync. Wymieńmy więc bardziej szczegółowo wszystkie funkcje Barmana:

• Operacja zdalna (kopie zapasowe/przywracanie)
• Przyrostowe kopie zapasowe. Przyrostowe kopie zapasowe, jedna z największych zalet barmana, opierają się na porównaniu plików bazy danych na poziomie plików z ostatnimi kopiami zapasowymi w katalogu. W języku barmana termin „różnicowy” odnosi się do innej koncepcji:według terminologii barmana, różnicowa kopia zapasowa to ostatnia kopia zapasowa + poszczególne zmiany z ostatniej kopii zapasowej. Dokumentacja Barmana twierdzi, że zapewnia różnicowe kopie zapasowe za pośrednictwem WAL-ów. Przyrostowe kopie zapasowe Barman działają na poziomie plików, co oznacza, że ​​jeśli plik zostanie zmieniony, cały plik zostanie przesłany. Jest to podobne do pgbackrest i w przeciwieństwie do niektórych innych ofert, takich jak pg_probackup lub BART, które obsługują różnicowe/przyrostowe kopie zapasowe na poziomie bloków. Przyrostowe kopie zapasowe Barmana są określone przez:reuse_backup =link lub kopia. Definiując „kopiowanie” uzyskujemy skrócony czas tworzenia kopii zapasowej, ponieważ tylko zmienione pliki są przesyłane i archiwizowane, ale nadal nie zmniejszamy miejsca, ponieważ niezmienione pliki są kopiowane z poprzedniej kopii zapasowej. Definiując „link”, niezmienione pliki są dowiązywane na stałe (nie kopiowane) z ostatniej kopii zapasowej. W ten sposób osiągamy zarówno redukcję czasu, jak i redukcję przestrzeni. Nie chcę w żaden sposób wprowadzać w to więcej zamieszania, ale w rzeczywistości przyrostowe kopie zapasowe Barmana są bezpośrednio porównywalne z przyrostowymi kopiami zapasowymi pgbackrest, ponieważ Barman traktuje (poprzez łącze lub kopię) przyrostową kopię zapasową skutecznie jako pełną kopię zapasową. Tak więc w obu systemach kopia przyrostowa dotyczy plików, które zostały zmienione od czasu ostatniej kopii zapasowej. Jednak w przypadku różnicowych kopii zapasowych oznacza to coś innego w każdym z wyżej wymienionych systemów, jak zobaczymy poniżej.
• Kopia zapasowa z trybu gotowości. Barman daje możliwość wykonywania większości podstawowych operacji tworzenia kopii zapasowych w trybie gotowości, uwalniając w ten sposób podstawowy od dodatkowego obciążenia we/wy. Należy jednak pamiętać, że nadal warstwy WAL muszą pochodzić z podstawowego. Nie ma znaczenia, czy używasz streamingu archive_command czy WAL przez szczeliny replikacji, nie możesz jeszcze (w chwili pisania tego tekstu, gdy barman jest w wersji 2.6) przenieść to zadanie do trybu gotowości.
• równoległe zadania do tworzenia kopii zapasowych i odzyskiwania
• Bogate i obszerny zestaw ustawień przechowywania na podstawie:
  • Nadmiarowość (liczba kopii zapasowych do zachowania)
  • Okno odzyskiwania (jak do przeszłości należy przechowywać kopie zapasowe)
  Moim zdaniem z punktu widzenia użytkownika powyższe jest świetne. Użytkownik może zdefiniować reuse_backup =link i okno odzyskiwania, a barman (jego zadanie cron) zajmie się resztą. Żadnych różnic/przyrostów/pełnych kopii zapasowych itp., którymi trzeba się martwić, planować lub zarządzać. System (barman) po prostu robi właściwą rzecz w przejrzysty sposób.
• Programowanie własnych skryptów przechwytujących przed/po zdarzeniu.
• Ponowne mapowanie przestrzeni tabel

To są najlepsze atuty barmana. I naprawdę jest to prawie więcej niż przeciętny administrator DBA zażądałby od narzędzia do tworzenia kopii zapasowych i odzyskiwania. Jest jednak kilka punktów, które mogłyby być lepsze:

• Lista dyskusyjna nie jest tak aktywna, a jej opiekunowie rzadko piszą lub odpowiadają na pytania
• Brak funkcji wznowienia nieudanej/przerwanej kopii zapasowej
• Gniazda replikacji lub użycie rsync/barman-wal-archive do archiwizacji nie wybaczają awarii sieci lub innych awarii lokalizacji kopii zapasowej. W obu przypadkach, jeśli awaria sieci jest wystarczająco długa, a zmiany w bazie danych są warte wielu plików WAL, wówczas podstawowy ucierpi z powodu „braku miejsca na urządzeniu” i ostatecznie ulegnie awarii. (nie jest to dobra rzecz). Obiecujące jest to, że barman zapewnia teraz alternatywny (dla rsync) sposób przesyłania WAL-ów, aby zapewnić dodatkową ochronę przed m.in. Wyczerpywanie przestrzeni pg_wal może zostać zaimplementowane w przyszłości, co wraz z wznowieniem kopii zapasowej naprawdę uczyniłoby barmana idealnym, przynajmniej dla mnie.

pgbackrest

Pgbackrest to aktualny trend wśród narzędzi do tworzenia kopii zapasowych typu open source, głównie ze względu na jego wydajność w radzeniu sobie z bardzo dużymi wolumenami danych oraz wyjątkową ostrożność, jaką twórcy przykładają do sprawdzania poprawności kopii zapasowych za pomocą sum kontrolnych. W chwili pisania tego tekstu jest on dostępny w wersji v2.09, a dokumentację można znaleźć tutaj. Podręcznik użytkownika może być nieco nieaktualny, ale pozostałe dokumenty są bardzo aktualne i dokładne. Pgbackrest polega na archiwizacji WAL przy użyciu własnego archive_command i własnego mechanizmu przesyłania plików, który jest lepszy i bezpieczniejszy niż rsync. Tak więc pgbackrest jest całkiem do przodu, ponieważ nie daje większego wyboru, jaki zapewnia barman. Ponieważ nie ma trybu synchronicznego, naturalnie pgbackrest nie gwarantuje RPO=0 (zero utraty danych). Opiszmy koncepcje pgbackrest:

• Kopia zapasowa może być:
  • Pełne. Pełna kopia zapasowa kopiuje cały klaster bazy danych.
  • Różnica (różnica). Kopia różnicowa kopiuje tylko te pliki, które zostały zmienione od czasu ostatniej pełnej kopii zapasowej. W celu pomyślnego przywrócenia zarówno różnicowa kopia zapasowa, jak i poprzednia pełna kopia zapasowa muszą być prawidłowe.
  • Przyrostowy (przyrost). Przyrostowa kopia zapasowa kopiuje tylko te pliki, które zostały zmienione od czasu ostatniej kopii zapasowej (może to być kopia pełna, różnicowa lub nawet przyrostowa). Podobnie jak w przypadku różnicowej kopii zapasowej, w celu pomyślnego przywrócenia, wszystkie poprzednie wymagane kopie zapasowe (w tym ta kopia zapasowa, najnowsza różnica i poprzednia pełna) muszą być prawidłowe.
• Sekcja to definicja wszystkich wymaganych parametrów klastra PostgreSQL. Normalny serwer PostgreSQL ma swoją własną sekcję, podczas gdy serwery zapasowe będą miały jedną sekcję dla każdego klastra PostgreSQL, który tworzą kopie zapasowe.
• Konfiguracja to miejsce, w którym przechowywane są informacje o sekcjach (zwykle /etc/pgbackrest.conf)
• Repozytorium to miejsce, w którym pgbackrest przechowuje WAL i kopie zapasowe

Zachęcamy użytkownika do postępowania zgodnie z dokumentacją, jak sugeruje sama dokumentacja, od góry do dołu. Najważniejsze cechy pgbackrest to:

• Równoległe tworzenie kopii zapasowych i przywracanie
• Nie jest potrzebny bezpośredni dostęp SQL do serwera PostgreSQL
• Operacja lokalna/zdalna
• Utrzymanie na podstawie:
  • przechowywanie pełnych kopii zapasowych (liczba pełnych kopii zapasowych do zachowania)
  • Przechowywanie kopii różnicowych (liczba kopii zapasowych różnic do zachowania)
  Przyrostowe kopie zapasowe nie mają własnego czasu przechowywania i wygasają, gdy tylko poprzednia kopia zapasowa wygaśnie. Dzięki temu użytkownik może zdefiniować harmonogram wykonywania pełnych kopii zapasowych i kroczącego zestawu kopii różnicowych między nimi.
• Kopia zapasowa z trybu gotowości. Niektóre pliki nadal muszą pochodzić z pliku podstawowego, ale kopia zbiorcza odbywa się w trybie gotowości. Mimo to WAL muszą pochodzić z podstawowego.
• Integralność kopii zapasowej. Osoby stojące za pgbackrest są niezwykle ostrożne, jeśli chodzi o integralność kopii zapasowych. Każdy plik jest sumowany w czasie tworzenia kopii zapasowej, a także sprawdzany po przywróceniu, aby upewnić się, że żaden problematyczny błąd sprzętowy lub programowy nie może spowodować nieprawidłowego przywrócenia. Również jeśli sumy kontrolne na poziomie strony są włączone w klastrze PostgreSQL, są one również obliczane dla każdego pliku. Ponadto sumy kontrolne są obliczane dla każdego pliku WAL.
• Jeśli kompresja jest wyłączona, a łącza twarde są włączone, możliwe jest przywołanie klastra bezpośrednio z katalogu. Jest to niezwykle ważne w przypadku dużych baz danych z wieloma TB.
• Wznowienie nieudanego/przerwanego powrotu. Bardzo przydatne w przypadku zawodnych sieci.
• Przywracanie delta:ultraszybkie przywracanie dużych baz danych bez czyszczenia całego klastra.
• Asynchroniczne i równoległe przesyłanie WAL do serwera zapasowego. To jeden z najmocniejszych punktów pgbackrest. Archiwizator PostgreSQL kopiuje do szpuli tylko za pomocą funkcji „archive-push”, a ciężka praca transferu i przetwarzania odbywa się w oddzielnym procesie pgbackrest. Pozwala to na masowe transfery WAL przy jednoczesnym zapewnieniu krótkich czasów odpowiedzi PostgreSQL.
• Ponowne mapowanie przestrzeni tabel
• Obsługa Amazon S3
• Obsługa maksymalnego rozmiaru kolejki WAL. Gdy witryna kopii zapasowej nie działa lub sieć ulegnie awarii, użycie tej opcji będzie symulować, że archiwizacja się powiodła, umożliwiając PostgreSQLowi usunięcie WALa zapobiegającego zapełnieniu pg_wal, a tym samym uratowanie serwera pgsql przed potencjalną paniką.

Tak więc pod względem funkcji pgbackrest kładzie duży nacisk, jeśli chodzi o walidację danych i wydajność, nic dziwnego, że jest on używany przez największe i najbardziej ruchliwe instalacje PostgreSQL. Jest jednak jedna rzecz, którą można poprawić:

• Byłoby naprawdę przydatne mieć bardziej „liberalną” opcję, jeśli chodzi o retencję, tj. zapewnić sposób na deklaratywne określenie pewnego okresu retencji, a następnie pozwolić pgbackrest zająć się kopiami zapasowymi full/diff/incr w razie potrzeby.

pg_probackup

Pg_proback to kolejne obiecujące narzędzie do tworzenia kopii zapasowych. Jest pierwotnie oparty na pg_arman. Nacisk kładziony jest na wydajność kopii zapasowej. Opiera się na katalogach i instancjach, bardzo podobnych do pozostałych narzędzi, więc mamy. Jego główne cechy to:

• Obszerne wsparcie na poziomie kopii zapasowych, od:
  • Pełne kopie zapasowe
  • Przyrost trzech typów:
    • Kopia zapasowa STRONY. Zmiany poziomu znalezione przez skanowanie WAL. Wymaga pełnego dostępu do nieprzerwanej sekwencji WAL od czasu poprzedniej kopii zapasowej.
    • Kopia zapasowa DELTA. Do kopii zapasowej kopiowane są tylko zmienione strony. Niezależne od archiwizacji WAL, nakłada pewne obciążenie na serwer.
    • Kopia zapasowa PTRACK. Wymaga specjalnych poprawek rdzenia pgsql. Działa poprzez utrzymywanie mapy bitowej w locie, gdy tylko strony zostaną zmodyfikowane. Naprawdę szybka kopia zapasowa przy minimalnym obciążeniu serwera.
• Kopie zapasowe można również podzielić na:
  • Autonomiczne kopie zapasowe. Nie mają one wymagań dotyczących WAL poza kopią zapasową. Brak PITR.
  • Kopie zapasowe archiwum. Te polegają na ciągłej archiwizacji i wspierają PITR.
• model wielowątkowy (w przeciwieństwie do barmana, pgbackrest i oczywiście samego PostgreSQL, który jest zgodny z modelem wieloprocesowym)
• Spójność danych i weryfikacja na żądanie bez przywracania
• Kopia zapasowa z trybu gotowości bez dostępu do podstawowego.
• Wyraźna specyfikacja zasad przechowywania, w której nadmiarowość może być używana w sposób AND wraz z oknem. Scalanie kopii zapasowych (poprzez scalanie) jest obsługiwane przez konwersję poprzednich przyrostowych kopii zapasowych do pełnych jako sposób na zwolnienie miejsca i zapewnienie metody na płynną rotację kopii zapasowych.

Tak więc pg_probackup zapewnia zestaw wspaniałych funkcji z naciskiem na wydajność, co przyniosłoby korzyści w przypadku dużych instalacji. Jednak wciąż brakuje kilku rzeczy, a mianowicie:

• Żadna oficjalna wersja nie obsługuje zdalnych kopii zapasowych. Oznacza to, że pg_probackup musi działać na tym samym hoście, co klaster pgsql. (Istnieje gałąź deweloperska, która zajmuje się tworzeniem kopii zapasowych ze zdalnej lokalizacji, a także archiwizacją na zdalnym serwerze kopii zapasowych)
• Brak obsługi nieudanych wznowień tworzenia kopii zapasowych.

Możemy podsumować powyższe akapity za pomocą macierzy funkcji, takiej jak poniżej.

ClusterControl

ClusterControl zapewnia funkcję generowania natychmiastowej kopii zapasowej lub jej zaplanowania oraz automatyzowania zadania w prosty i szybki sposób.

Do wyboru mamy dwie metody tworzenia kopii zapasowych, pgdump (logiczną) i pg_basebackup (binarną). Możemy również określić, gdzie przechowywać kopie zapasowe (na serwerze bazy danych, na serwerze ClusterControl lub w chmurze), poziom kompresji i szyfrowanie.

Ponadto dzięki ClusterControl możemy użyć funkcji odzyskiwania do punktu w czasie i weryfikacji kopii zapasowej, aby zweryfikować wygenerowaną kopię zapasową.