Nowa funkcja Hot Standby w nadchodzącym PostgreSQL 9.0 umożliwia uruchamianie zapytań względem węzłów oczekujących, które wcześniej wykonywały tylko proces odzyskiwania. Dwa typowe oczekiwania, jakie słyszałem od użytkowników oczekujących tej funkcji, to to, że pozwoli ona albo na dystrybucję krótkich zapytań w obu węzłach, albo pozwoli na uruchamianie długich raportów w trybie gotowości bez korzystania z zasobów na urządzeniu głównym. Oba są możliwe do wykonania w tej chwili, ale jeśli nie rozumiesz kompromisów związanych z działaniem funkcji Hot Standby, może wystąpić tutaj nieoczekiwane zachowanie.
Standardowe, długotrwałe zapytania
Jednym z tradycyjnych problemów w bazie danych korzystającej z MVCC, takiej jak PostgreSQL, jest to, że długotrwałe zapytanie musi utrzymywać otwarty zasób – określany jako migawka w obecnej implementacji Postgres – aby zapobiec usuwaniu przez bazę danych potrzebnych do zapytania. obsługiwać. Na przykład tylko dlatego, że inny klient usunął wiersz i zatwierdził, jeśli już uruchomione zapytanie wymaga ukończenia tego wiersza, nie można jeszcze usunąć fizycznych bloków dysku związanych z tym wierszem. Musisz poczekać, aż nie będzie żadnych otwartych zapytań, które oczekują, że ten wiersz będzie widoczny.
Ograniczenia gorącej gotowości
Jeśli masz długotrwałe zapytanie, które chcesz wykonać w trybie gotowości, istnieje kilka rodzajów złych rzeczy, które mogą się zdarzyć, gdy proces odzyskiwania stosuje aktualizacje. Zostały one szczegółowo opisane w dokumentacji Hot Standby. Niektóre z tych złych rzeczy powodują, że zapytania działające w trybie gotowości zostaną anulowane z powodów, które mogą nie być intuicyjnie oczywiste:
- Nadchodzi GORĄCA aktualizacja lub aktualizacja związana z VACUUM, aby usunąć coś, co zapytanie ma być widoczne
- Pojawia się usunięcie B-drzewa
- Występuje problem z blokowaniem między uruchomionym zapytaniem a blokadami wymaganymi do przetworzenia aktualizacji.
Sytuacja blokady jest trudna do rozwiązania, ale nie jest bardzo prawdopodobne, że stanie się to w praktyce przez tak długi czas, jeśli uruchamiasz tylko zapytania tylko do odczytu w trybie gotowości, ponieważ będą one izolowane przez MVCC. Na pozostałe dwie nietrudno się natknąć. Podstawową rzeczą do zrozumienia jest to, że dowolny UPDATE lub DELETE na urządzeniu master może spowodować przerwanie dowolnego zapytania w trybie standby; nie ma znaczenia, czy zmiany odnoszą się nawet do tego, co robi zapytanie.
Dobrze, szybko, tanio:wybierz dwa
Zasadniczo istnieją trzy rzeczy, które ludzie mogą chcieć nadać priorytet:
- Unikaj ograniczeń mastera:pozwól xidom i powiązanym migawkom na nieograniczony postęp na master, aby VACUUM i podobne czyszczenie nie było wstrzymywane przez to, co robi tryb gotowości
- Nieograniczone zapytania:uruchamiaj zapytania w trybie gotowości przez dowolny okres
- Bieżące odzyskiwanie:Utrzymuj proces odzyskiwania w trybie gotowości na bieżąco z tym, co dzieje się na urządzeniu głównym, umożliwiając szybkie przełączanie awaryjne dla HA
W każdej sytuacji z Hot Standby jest dosłownie niemożliwe, aby mieć wszystkie trzy naraz. Możesz tylko wybrać swój kompromis. Dostępne dostrajalne parametry umożliwiają już optymalizację na kilka sposobów:
- Wyłączenie wszystkich tych ustawień opóźnienia/odroczenia optymalizuje zawsze bieżące odzyskiwanie, ale wtedy odkryjesz, że zapytania są prawdopodobnie anulowane z większym prawdopodobieństwem, niż można by się spodziewać.
- max_standby_delay optymalizuje dla dłuższych zapytań, kosztem utrzymywania bieżącego odzyskiwania. Opóźnia to zastosowanie aktualizacji do trybu gotowości, gdy pojawi się ta, która spowoduje problem (GORĄCY, ODKURZAJĄCY, B-drzewo, itp.).
- vacuum_defer_cleanup_age a niektóre hacki do migawek mogą wprowadzić pewne główne ograniczenia, aby poprawić pozostałe dwa problemy, ale przy słabym interfejsie użytkownika, aby to zrobić. vacuum_defer_cleanup_age jest w jednostkach identyfikatorów transakcji. Aby zmienić sposób myślenia o tym problemie („opóźnienie o co najmniej 1 godzinę, aby moje raporty zostały uruchomione”), trzeba mieć pewne pojęcie o średniej liczbie odpływów xid w systemie w jednostce czasu. Wskaźnik konsumpcji xid po prostu nie jest powszechną ani nawet rozsądną rzeczą do mierzenia/przewidywania. Alternatywnie możesz otworzyć migawkę na podstawowej, zanim rozpoczniesz długotrwałe zapytanie w trybie gotowości. dblink jest sugerowany w dokumentacji Hot Standby jako sposób na osiągnięcie tego. Teoretycznie demon w trybie gotowości mógłby zostać napisany w przestrzeni użytkownika, żyjący na podstawowym, aby obejść ten problem (Simon ma podstawowy projekt dla jednego). Zasadniczo uruchamiasz serię procesów, z których każdy uzyskuje migawkę, a następnie śpi przez pewien czas przed jej zwolnieniem. Oddzielając czas, przez jaki każdy z nich spał, możesz mieć pewność, że migawki xid nigdy nie przesuną się do przodu zbyt szybko na wzorcu. Powinno być oczywiste, jak bardzo byłby to okropny hack.
Potencjalne ulepszenia
Jedyną z tych rzeczy, z którą naprawdę można coś zrobić, jest zaostrzenie i ulepszenie interfejsu użytkownika dla głównego ograniczenia. To zmienia to w tradycyjny problem już obecny w bazie danych:długotrwałe zapytanie utrzymuje otwartą migawkę (lub przynajmniej ogranicza postęp identyfikatorów transakcji związanych z widocznością) na urządzeniu głównym, uniemożliwiając urządzeniu głównemu usunięcie elementów potrzebnych do tego zapytania. kompletny. Możesz na przemian myśleć o tym jako o automatycznym dostrajaniu vacuum_defer_cleanup_age.
Pytanie brzmi, jak ustawić podstawową szanować potrzeby długotrwałych zapytań w trybie gotowości . Może to być możliwe, jeśli z urządzeniem głównym zostanie udostępnionych więcej informacji o wymaganiach dotyczących widoczności transakcji w trybie gotowości. Taka wymiana byłaby naprawdę czymś bardziej odpowiednim do współdzielenia przez nową implementację Streaming Replication. Sposób, w jaki udostępniany jest prosty serwer Hot Standby, nie zapewnia żadnej informacji zwrotnej dla mastera, która byłaby odpowiednia do wymiany tych danych, poza podejściami, takimi jak wspomniany już hack dblink.
Ponieważ PostgreSQL 9.0 właśnie osiągnął czwartą wersję alfa, może jeszcze czas, aby zobaczyć kilka ulepszeń w tym obszarze jeszcze przed wydaniem 9.0. Byłoby miło zobaczyć, jak Hot Standby i Streaming Replication naprawdę są ze sobą zintegrowane w sposób, który zapewnia rzeczy, których żadne z nich nie jest w stanie zrobić samodzielnie, zanim kodowanie w tym wydaniu całkowicie się zawiesi.
