„Paradoksem, ale prawdą jest stwierdzenie, że im więcej wiemy, tym bardziej stajemy się ignorantami w sensie absolutnym, ponieważ tylko poprzez oświecenie stajemy się świadomi naszych ograniczeń. Dokładnie jednym z najbardziej satysfakcjonujących rezultatów ewolucji intelektualnej jest nieustanne otwieranie się na nowe i większe perspektywy”. Nikola Tesla
PostgreSQL to niesamowity projekt, który rozwija się w niesamowitym tempie. Skoncentrujemy się na ewolucji możliwości odporności na awarie w PostgreSQL we wszystkich jego wersjach w serii wpisów na blogu.
PostgreSQL w skrócie
PostgreSQL jest z natury odporny na błędy. Po pierwsze, jest to zaawansowany system zarządzania bazami danych typu open source, który w tym roku będzie obchodził swoje 20. urodziny. Dlatego jest to sprawdzona technologia i posiada aktywną społeczność, dzięki czemu ma szybki postęp w rozwoju.
PostgreSQL jest zgodny z SQL (SQL:2011) i w pełni zgodny z ACID (atomowość, konsystencja, izolacja, trwałość).
PostgreSQL umożliwia replikację fizyczną i logiczną oraz ma wbudowane rozwiązania replikacji fizycznej i logicznej. Porozmawiamy o metodach replikacji (w następnych wpisach na blogu) w PostgreSQL w odniesieniu do odporności na awarie.
PostgreSQL umożliwia transakcje synchroniczne i asynchroniczne, PITR (odzyskiwanie do punktu w czasie) i MVCC (kontrola współbieżności w wielu wersjach). Wszystkie te koncepcje są związane z odpornością na błędy na pewnym poziomie i postaram się wyjaśnić ich skutki, wyjaśniając niezbędne terminy i ich zastosowania w PostgreSQL.
PostgreSQL jest solidny!
Wszystkie działania w bazie danych są wykonywane w ramach transakcji , chroniony przez dziennik transakcji który wykona automatyczne przywracanie po awarii w przypadku awarii oprogramowania.
Bazy danych mogą być opcjonalnie tworzone za pomocą sum kontrolnych bloków danych aby pomóc w diagnozowaniu usterek sprzętowych. Istnieje wiele mechanizmów tworzenia kopii zapasowych, z pełnym i szczegółowym PITR, na wypadek konieczności szczegółowego odzyskiwania. Dostępnych jest wiele narzędzi diagnostycznych.
Replikacja bazy danych jest obsługiwana natywnie. Replikacja synchroniczna może zapewnić więcej niż „5 dziewiątek” (99,999 procent) dostępność i ochrona danych, jeśli są odpowiednio skonfigurowane i zarządzane.
Biorąc pod uwagę powyższe fakty, możemy z łatwością twierdzić, że PostgreSQL jest solidny!
Tolerancja błędów PostgreSQL:WAL
Rejestrowanie zapisu z wyprzedzeniem jest głównym systemem odporności na błędy w PostgreSQL.
WAL składa się z serii plików binarnych zapisanych w podkatalogu pg_xlog katalogu danych PostgreSQL. Każda zmiana dokonana w bazie danych jest najpierw rejestrowana w WAL, stąd nazwa dziennika „zapis z wyprzedzeniem”, jako synonim „dziennika transakcji”. Gdy transakcja zostaje zatwierdzona, domyślnym i bezpiecznym zachowaniem jest wymuszenie na dysku rekordów WAL.
W przypadku awarii PostgreSQL, WAL zostanie odtworzony, co spowoduje powrót bazy danych do punktu ostatniej zatwierdzonej transakcji, a tym samym zapewni trwałość wszelkich zmian w bazie danych.
Transakcja? Zobowiązać się?
Same zmiany w bazie danych nie są zapisywane na dysku podczas zatwierdzania transakcji. Te zmiany są zapisywane na dysku jakiś czas później przez program zapisujący w tle lub wskaźnik kontrolny na dobrze dostrojonym serwerze. (Sprawdź powyższy opis WAL. )
Transakcje są podstawową koncepcją wszystkich systemów baz danych. Zasadniczym punktem transakcji jest to, że łączy ona wiele kroków w jedną operację typu „wszystko albo nic”.
Stany pośrednie między krokami nie są widoczne dla innych współbieżnych transakcji, a jeśli wystąpi błąd uniemożliwiający zakończenie transakcji, żaden z kroków nie ma w ogóle wpływu na bazę danych. PostgreSQL nie obsługuje brudnych odczytów (transakcja odczytuje dane zapisane przez jednoczesną niezatwierdzoną transakcję ).
Punkt kontrolny
Odzyskiwanie po awarii odtwarza WAL, ale od którego momentu zaczyna się odzyskiwać?
Odzyskiwanie rozpoczyna się od punktów w WAL zwanych punktami kontrolnymi . Czas trwania odzyskiwania po awarii zależy od liczby zmian w dzienniku transakcji od ostatniego punktu kontrolnego. Punkt kontrolny jest znanym bezpiecznym punktem wyjścia do odzyskiwania, ponieważ gwarantuje, że wszystkie poprzednie zmiany w bazie danych zostały już zapisane na dysku.
Punkt kontrolny może być natychmiastowy lub zaplanowane . Natychmiastowe punkty kontrolne są wyzwalane przez jakąś akcję superużytkownika, taką jak CHECKPOINT dowództwo lub inne; zaplanowane punkty kontrolne są ustalane automatycznie przez PostgreSQL.
Wniosek
W tym wpisie na blogu wymieniliśmy ważne cechy PostgreSQL, które są związane z odpornością na błędy w PostgreSQL. Wspomnieliśmy o rejestrowaniu z wyprzedzeniem, transakcjach, zatwierdzaniu, poziomach izolacji, punktach kontrolnych i odzyskiwaniu po awarii. W następnym wpisie na blogu będziemy kontynuować replikację PostgreSQL.
Referencje:
Dokumentacja PostgreSQL
Administracyjna książka kucharska PostgreSQL 9 – wydanie drugie
