Ułatwianie zarządzania produkcyjną bazą danych PostgreSQL

W ciągu ostatnich kilku lat nastąpił wzrost popularności PostgreSQL. PostgreSQL to niesamowita relacyjna baza danych. Jeśli chodzi o funkcje, jest tam z najlepszymi, jeśli nie najlepszymi. Jest wiele rzeczy, które w nim kocham – PL/PG SQL, inteligentne ustawienia domyślne, replikacja (która faktycznie działa po wyjęciu z pudełka) oraz aktywna i aktywna społeczność open source. Jednak poza samymi funkcjami istnieją inne ważne aspekty bazy danych, które należy wziąć pod uwagę. Jeśli planujesz zbudować dużą operację 24/7, możliwość łatwej obsługi bazy danych po jej uruchomieniu staje się bardzo ważnym czynnikiem. W tym aspekcie PostgreSQL nie radzi sobie zbyt dobrze. W tym poście na blogu opiszemy niektóre z tych wyzwań operacyjnych związanych z PostgreSQL. Nie ma tu nic zasadniczo nie do naprawienia, tylko kwestia priorytetyzacji. Mamy nadzieję, że możemy wygenerować wystarczające zainteresowanie społecznością open source, aby nadać priorytet tym funkcjom.

1. Brak automatycznego wykrywania sterowników klienta głównego przełączania awaryjnego

Sterownik klienta PostgreSQL nie wykrywa automatycznie, kiedy nastąpiło główne przełączenie awaryjne (i wybrano nowy główny). Aby obejść ten problem, administratorzy muszą wdrożyć warstwę proxy po stronie serwera. Popularne opcje to mapowanie DNS, mapowanie wirtualnego adresu IP, PgPool i HAProxy. Wszystkie te opcje można sprawić, aby działały dobrze, ale wymagane są znaczne dodatkowe czynności związane z nauką i administratorem. W przypadku, gdy w ścieżce danych zostanie wprowadzony serwer proxy, ma to również znaczny wpływ na wydajność. Jest to standardowa wbudowana funkcja w wielu nowych bazach danych NoSQL, a PostgreSQL świetnie by zrobił, jeśli chodzi o operacje.

2. Brak wbudowanego automatycznego przełączania awaryjnego między trybem głównym a trybem gotowości

Gdy serwer główny PostgreSQL ulegnie awarii, jako serwer główny należy wybrać jeden z serwerów rezerwowych. Ten mechanizm nie jest wbudowany w PostgreSQL. Zazwyczaj do obsługi tego scenariusza wykorzystywane są narzędzia programowe innych firm, takie jak Patroni, Pacemaker itp. Dlaczego nie wbudowano go w serwer? Te narzędzia innych firm wyglądają na zwodniczo proste, ale wymaga to znacznego wysiłku, wiedzy i testów ze strony administratora, aby to zrobić dobrze. Wbudowując to w bazę danych, wyświadczasz ogromną przysługę administratorowi bazy danych.

3. Bez większych przestojów bez przestojów

Nie ma możliwości uaktualnienia bazy danych PostgreSQL z jednej głównej wersji do innej bez przestoju. Zasadniczo musisz zamknąć wszystkie serwery i użyć pg_upgrade, aby zaktualizować dane do nowszej wersji. Przestój nie jest duży, ponieważ nie dotyczy to kopii danych, jednak nadal występuje przestój. Jeśli prowadzisz działalność 24/7, może to nie być dla Ciebie opcja.

Po wydaniu replikacji logicznej mamy alternatywną opcję aktualizacji online.

1. Zbuduj zupełnie nową konfigurację PostgreSQL Master-Standby z nową wersją.
2. Skonfiguruj replikację logiczną, aby replikować ze starszej wersji do nowszej wersji.
3. Gdy będziesz gotowy, zmień ciąg połączenia, aby wskazywał ze starszej konfiguracji na nową.

Ponownie można to zrobić, ale koszty są ogromne. Idealnie, potrzebny jest tutaj sposób na aktualizację na miejscu w sposób toczący się w stosunku do głównej konfiguracji w trybie gotowości. Aktualizacja MySQL umożliwia aktualizację urządzeń podrzędnych w miejscu do nowej wersji, a następnie wywołanie przełączenia awaryjnego.

4. Brak pełnej próżni na miejscu

Autovacuum/VACUUM jest bardzo przydatne i w pewnym stopniu pomaga rozwiązać ten problem. Powinieneś regularnie sprawdzać wzdęcia na stołach, aby upewnić się, że ustawienia automatycznej próżni są odpowiednie i działają dobrze na Twoim stole. Jednak autovacuum nie działa do końca – w rzeczywistości nie kończy się scalaniem i usuwaniem stron. Jeśli masz dużą liczbę aktualizacji, wstawiaj i usuwaj obciążenia, Twoje strony zostaną pofragmentowane, co wpłynie na wydajność. Jedynym sposobem na obejście tego jest uruchomienie VACUUM FULL, który zasadniczo przebuduje wszystkie strony, aby wyeliminować fragmentację. Jednak ten proces można wykonać tylko w czasie przestoju – Twój stół jest wyłączony przez czas PEŁNEGO PODCIŚNIENIA. W przypadku dużych zbiorów danych może to zająć kilka godzin i nie jest praktyczną alternatywą, jeśli chcesz działać w trybie 24/7.

Uwaga:społeczność rozpoczęła już prace nad silnikiem przechowywania zheap, który przezwycięża to ograniczenie.

Jeśli są inne ulepszenia, które Twoim zdaniem mogą być przydatne, możesz zostawić komentarz.