Jak zoptymalizować replikację logiczną PostgreSQL

Logiczna replikacja lub Pglogical to mechanizm replikacji na poziomie tabeli oparty na WAL, który replikuje dane określonych tabel między dwiema instancjami PostgreSQL. Wydaje się, że istnieje pomyłka między „pglogicznymi” a „logiczną replikacją”. Oba zapewniają ten sam mechanizm replikacji z pewnymi różnicami w funkcjach i możliwościach. Logiczna replikacja jest wprowadzona w PostgreSQL-10 jako wbudowana funkcja, w przeciwieństwie do pglogical, który jest rozszerzeniem. „Pglogical”, z ciągłym rozwojem, pozostaje jedyną opcją do implementacji Logicznej Replikacji w środowiskach korzystających z wersji PostgreSQL wcześniejszych niż 10. Ostatecznie wszystkie funkcje pglogical będą częścią Logicznej Replikacji. Innymi słowy, pglogical (rozszerzenie) stał się Logiczną Replikacją (funkcją wbudowaną). Podstawową zaletą replikacji logicznej jest to, że nie wymaga instalowania/tworzenia żadnych rozszerzeń, co z kolei jest korzystne w środowiskach, w których instalowanie rozszerzeń jest ograniczone.

Ten blog skupi się na optymalizacji replikacji logicznej. Oznacza to, że wskazówki i techniki optymalizacji przedstawione na tym blogu będą miały zastosowanie zarówno do replikacji pglogicznej, jak i logicznej.

Replikacja logiczna to pierwsza w swoim rodzaju replikacja oparta na technologii WAL. Jako administrator DBA byłby to znacznie bardziej niezawodny i wydajny mechanizm replikacji w porównaniu z innymi rozwiązaniami replikacji opartymi na wyzwalaczach. Zmiany wprowadzone w tabelach będących częścią replikacji pglogicznej są replikowane w czasie rzeczywistym za pośrednictwem rekordów WAL, co czyni ją wysoce wydajną i nieskomplikowaną. Wszystkie inne mechanizmy replikacji na rynku są oparte na wyzwalaczach, co może stanowić wyzwanie dla wydajności i konserwacji. Wraz z nadchodzącą replikacją logiczną, zależność od replikacji opartej na wyzwalaczach prawie zniknęła.

Istnieją inne blogi, które szczegółowo wyjaśniają, jak skonfigurować replikację logiczną.

W tym blogu skupimy się na optymalizacji replikacji logicznej.

Optymalizacja replikacji logicznej

Po pierwsze, zachowanie „replikacji logicznej” jest dość podobne do „replikacji strumieniowej”, jedyną różnicą jest to, że replikacja strumieniowa replikuje całą bazę danych, podczas gdy replikacja logiczna replikuje tylko pojedyncze tabele. Wybierając konkretne poszczególne tabele do replikacji, należy przewidzieć czynniki/wyzwania.

Przyjrzyjmy się czynnikom wpływającym na replikację logiczną.

Czynniki wpływające na wydajność replikacji logicznej

Optymalizacja replikacji logicznej jest ważna, aby zapewnić bezproblemową replikację danych bez żadnych przerw. Istnieją czynniki, które należy przewidzieć przed jego założeniem. Przyjrzyjmy się im:

• Rodzaj danych przechowywanych w tabelach do replikacji
• Jak aktywne są transakcyjnie tabele (część replikacji)
• Należy przewidzieć przepustowość infrastruktury
• Konfiguracja parametrów musi być wykonana optymalnie

Wszystkie powyższe czynniki w większym stopniu wpływają na replikację logiczną. Przyjrzyjmy się im szczegółowo.

Typy danych replikacji logicznej PostgreSQL

Ważne jest zrozumienie rodzaju danych przechowywanych w tabeli. Jeśli część tabeli replikacji przechowuje duże obiekty tekstowe lub binarne i napotka dużą liczbę transakcji, replikacja może ulec spowolnieniu z powodu dużego wykorzystania zasobów infrastruktury. Przepustowość infrastruktury musi być odpowiednia do obsługi tak złożonej i dużej replikacji danych.

Jak aktywne tabele są transakcyjnie częścią replikacji

Podczas replikacji wysoce aktywnych transakcyjnie tabel, replikacja może mieć opóźnienia w synchronizacji z powodu problemów z wydajnością we/wy, zakleszczeń itp., co należy wziąć pod uwagę. Może to nie sprawić, że produkcyjne środowiska baz danych będą wyglądać na zdrowsze. Jeśli liczba replikowanych tabel jest duża, a dane są replikowane do wielu witryn, może wystąpić duże obciążenie procesora i wymagana jest większa liczba procesorów (lub rdzeni procesorów).

Pojemność infrastruktury

Przed rozważeniem replikacji logicznej jako rozwiązania, należy upewnić się, że przepustowość infrastruktury serwerów baz danych jest wystarczająca. Jeśli replikowana jest duża liczba tabel, musi być dostępna wystarczająca liczba procesorów, aby wykonać zadanie replikacji.

W przypadku replikacji dużej liczby tabel rozważ podzielenie ich na grupy i wykonanie równoległej replikacji. Ponownie, będzie to wymagać wielu procesorów, aby były dostępne do replikacji. Jeśli zmiany danych w replikowanych tabelach są częste i wysokie, może to również wpłynąć na wydajność replikacji.

Optymalizacja parametrów replikacji logicznej

Parametry skonfigurowane do działania replikacji logicznej muszą być optymalnie dostrojone, aby zapewnić, że replikacja nie zostanie przerwana.

Przyjrzyjmy się najpierw parametrom potrzebnym do jego konfiguracji:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Dostrajanie max_wal_senders

max_wal_senders musi być zawsze większa niż liczba replik. Jeśli dane są replikowane do wielu witryn, w grę wchodzi wielu max_wal_senders. Dlatego ważne jest, aby upewnić się, że ten parametr jest ustawiony na optymalną liczbę.

Dostrajanie max_replication_slots

Ogólnie wszystkie zmiany danych zachodzące w tabelach są zapisywane w plikach WAL w pg_xlog / pg_wal, które są określane jako rekordy WAL. Proces Wal sender odbierze te rekordy WAL (należące do replikowanych tabel) i wyśle ​​je do replik, a proces wal_receiver w witrynie repliki zastosuje te zmiany w węźle abonenckim.

Pliki WAL są usuwane z lokalizacji pg_xlog/pg_wal po każdym wystąpieniu punktu kontrolnego. Jeśli pliki WAL zostaną usunięte jeszcze przed zastosowaniem zmian w węźle abonenckim, wówczas replikacja zostanie przerwana i pozostanie w tyle. W przypadku opóźnień węzła abonenckiego szczelina replikacji zapewniłaby zachowanie wszystkich plików WAL potrzebnych abonentowi do synchronizacji z dostawcą. Zaleca się skonfigurowanie jednego gniazda replikacji dla każdego węzła abonenckiego.

Dostrajanie max_worker_processes

Ważne jest, aby skonfigurować optymalną liczbę procesorów roboczych. Zależy to od maksymalnej liczby procesów, które może mieć serwer. Jest to możliwe tylko w środowiskach z wieloma procesorami. Max_worker_processes zapewni, że wiele procesów zostanie uruchomionych, aby wykonać zadanie w szybszy sposób, wykorzystując wiele rdzeni procesora. Podczas replikacji danych przy użyciu replikacji logicznej ten parametr może pomóc w wygenerowaniu wielu procesów roboczych w celu szybszej replikacji danych. Istnieje określony parametr o nazwie max_logical_worker_processes, który zapewni, że do skopiowania danych zostanie użytych wiele procesów.

Dostrajanie max_logical_worker_processes

Ten parametr określa maksymalną liczbę logicznych procesów roboczych wymaganych do wykonania replikacji i synchronizacji danych tabeli. Ta wartość jest pobierana z max_worker_processes, która powinna być wyższa niż wartość tego parametru. Ten parametr jest bardzo przydatny podczas replikowania danych do wielu lokalizacji w środowiskach z wieloma procesorami. Wartość domyślna to 4. Maksymalna wartość zależy od tego, ile procesów roboczych obsługuje system.

Dostrajanie max_sync_workers_per_subscription

Ten parametr określa maksymalną liczbę procesów synchronizacji wymaganych na subskrypcję. Proces synchronizacji odbywa się podczas początkowej synchronizacji danych i aby zapewnić szybsze działanie, można użyć tego parametru. Obecnie na jedną tabelę można skonfigurować tylko jeden proces synchronizacji, co oznacza, że ​​wiele tabel można początkowo synchronizować równolegle. Domyślna wartość to 2. Ta wartość jest wybierana z wartości max_logical_worker_processes.

Są to parametry, które należy dostroić, aby replikacja logiczna była wydajna i szybsza. Inne parametry, które również wpływają na replikację logiczną, są następujące.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Te parametry nie mają żadnego wpływu na węzeł dostawcy.

Wniosek

Tabele specyficzne dla replikacji są powszechnym wymogiem, który pojawia się w dużych i złożonych systemach baz danych. Może to służyć do celów sprawozdawczości biznesowej lub hurtowni danych. Jako administrator DBA wierzę, że replikacja logiczna doskonale spełnia takie cele ze względu na łatwą implementację i mniejszą złożoność. Konfiguracja i dostrajanie replikacji logicznej wymaga dużej ilości planowania, architektury i testowania. Ilość danych replikowanych w czasie rzeczywistym musi zostać oceniona w celu zapewnienia wydajnego i niewidocznego systemu replikacji. Podsumowując, Bazy danych działające w PostgreSQL-10, Logiczna replikacja jest drogą do zrobienia, a dla tych baz danych działających w wersjach PostgreSQL <10, pglogical jest opcją.