Przewodnik eksperta po Slony Replication dla PostgreSQL

Co to jest Slony?

Slony-I (odtąd nazywany po prostu „Slony”) to system replikacji PostgreSQL innej firmy, który pochodzi sprzed wersji 8.0, co czyni go jedną ze starszych dostępnych opcji replikacji. Działa jako metoda replikacji oparta na wyzwalaczu, która jest rozwiązaniem typu „master do wielu urządzeń podrzędnych”.

Slony działa, instalując wyzwalacze na każdej tabeli, która ma być replikowana, zarówno na nadrzędnej, jak i podrzędnej, a za każdym razem, gdy tabela otrzymuje polecenie INSERT, UPDATE lub DELETE, rejestruje, który rekord został zmieniony i jakie są zmiany. Procesy zewnętrzne, zwane „demonami slon”, łączą się z bazami danych jak każdy inny klient i pobierają zmiany od urządzenia nadrzędnego, a następnie odtwarzają je na wszystkich węzłach podrzędnych zasubskrybowanych do urządzenia nadrzędnego. W dobrze działającej konfiguracji replikacji ta asynchroniczna można oczekiwać, że replikacja będzie opóźniona o 1 do 20 sekund w stosunku do wzorca.

W chwili pisania tego tekstu najnowsza wersja Slony jest w wersji 2.2.6 i obsługuje PostgreSQL 8.3 i nowsze. Wsparcie jest kontynuowane do dnia dzisiejszego z drobnymi aktualizacjami, jednak jeśli przyszła wersja PostgreSQL zmieni podstawową funkcjonalność transakcji, funkcji, wyzwalaczy lub innych podstawowych funkcji, projekt Slony może zdecydować o przerwaniu dużych aktualizacji w celu obsługi tak drastycznych nowych podejść.

Maskotką PostgreSQL jest słoń znany jako „Slonik”, co po rosyjsku oznacza „mały słoń”. Ponieważ ten projekt replikacji dotyczy wielu baz danych PostgreSQL replikujących się między sobą, używane jest rosyjskie słowo oznaczające słonie (liczba mnoga):Slony.

Koncepcje

• Klaster:instancja replikacji Slony.
• Węzeł:konkretna baza danych PostgreSQL jako węzeł replikacji Slony, który działa jako nadrzędny lub podrzędny dla zestawu replikacyjnego.
• Zestaw replikacji:grupa tabel i/lub sekwencji do replikacji.
• Abonenci:Subskrybent to węzeł, który subskrybuje zestaw replikacji i odbiera zdarzenia replikacji dla wszystkich tabel i sekwencji w tym zestawie z węzła głównego.
• Daemony Slony:główny proces roboczy wykonujący replikację, demon Slony jest uruchamiany dla każdego węzła w zestawie replikacji i nawiązuje różne połączenia z węzłem, którym zarządza, a także z węzłem głównym.

Jak to jest używane

Slony jest instalowany przez źródła lub przez repozytoria PGDG (PostgreSQL Global Development Group), które są dostępne dla dystrybucji Linuksa opartych na Red Hat i Debianie. Te pliki binarne powinny być zainstalowane na wszystkich hostach, które będą zawierać węzeł główny lub podrzędny w systemie replikacji.

Po instalacji klaster replikacji Slony jest konfigurowany przez wydawanie kilku poleceń przy użyciu pliku binarnego „slonik”. „slonik” to polecenie o prostej, ale unikalnej składni własnej, służącej do inicjowania i utrzymywania slony klastra. Jest to główny interfejs do wydawania poleceń działającemu klasterowi Slony, który odpowiada za replikację.

Połączenie z Slony można wykonać, pisząc niestandardowe polecenia slonik lub kompilując slony z flagą --with-perltools, która zapewnia skrypty „altperl”, które pomagają wygenerować potrzebne skrypty slonik.

Tworzenie klastra replikacji Slony

„Klaster replikacji” to zbiór baz danych, które są częścią replikacji. Podczas tworzenia klastra replikacji należy napisać skrypt startowy, który definiuje następujące elementy:

• Pożądana nazwa klastra Slony
• Informacje o połączeniu dla każdej części węzła replikacji, każda z niezmiennym numerem węzła.
• Lista wszystkich tabel i sekwencji do replikacji jako część „zestawu replikacji”.

Przykładowy skrypt można znaleźć w oficjalnej dokumentacji Slony.

Po uruchomieniu slonik połączy się ze wszystkimi zdefiniowanymi węzłami i utworzy na każdym z nich schemat Slony. Kiedy demony Slony zostaną uruchomione, usuną wszystkie dane z replikowanych tabel na urządzeniu podrzędnym (jeśli takie istnieją) i skopiują wszystkie dane z urządzenia nadrzędnego do urządzenia podrzędnego. Od tego momentu demony będą stale replikować zmiany zapisane na urządzeniu głównym we wszystkich subskrybowanych urządzeniach podrzędnych.

Inteligentne konfiguracje

Chociaż Slony jest początkowo systemem replikacji typu Master-to-Multiple-Slave i był używany głównie w ten sposób, istnieje kilka innych funkcji i sprytnych zastosowań, które sprawiają, że Slony jest bardziej użyteczny niż proste rozwiązanie do replikacji. Wysoce konfigurowalny charakter Slony sprawia, że ​​jest on odpowiedni w różnych sytuacjach dla administratorów, którzy potrafią myśleć nieszablonowo.

Replikacja kaskadowa

Węzły Slony można skonfigurować do kaskadowej replikacji w dół łańcucha różnych węzłów. Jeśli wiadomo, że węzeł główny przyjmuje bardzo duże obciążenie, każdy dodatkowy moduł podrzędny nieznacznie zwiększy to obciążenie. Dzięki replikacji kaskadowej pojedynczy węzeł podrzędny podłączony do węzła nadrzędnego można skonfigurować jako „węzeł przekazujący”, który będzie następnie odpowiedzialny za wysyłanie zdarzeń replikacji do większej liczby urządzeń podrzędnych, utrzymując obciążenie węzła głównego na minimalnym poziomie.

Przetwarzanie danych w węźle podrzędnym

W przeciwieństwie do wbudowanej replikacji PostgreSQL, węzły podrzędne nie są w rzeczywistości „tylko do odczytu”, tylko replikowane tabele są zablokowane jako „tylko do odczytu”. Oznacza to, że w węźle podrzędnym przetwarzanie danych może odbywać się poprzez tworzenie nowych tabel, które nie są częścią replikacji do przechowywania przetworzonych danych. Tabele będące częścią replikacji mogą również mieć niestandardowe indeksy tworzone w zależności od wzorców dostępu, które mogą różnić się od wzorców podrzędnych i nadrzędnych.

Tabele tylko do odczytu na urządzeniach podrzędnych mogą nadal mieć niestandardowe funkcje wyzwalania wykonywane po zmianach danych, co pozwala na większą personalizację danych.

Minimalne uaktualnienia przestojów

Aktualizacja głównych wersji PostgreSQL może być bardzo czasochłonna. W zależności od rozmiaru danych i liczby tabel uaktualnienie, w tym proces „analizy” po uaktualnieniu, może zająć nawet kilka dni. Ponieważ Slony może replikować dane między klastrami PostgreSQL w różnych wersjach, można go użyć do skonfigurowania replikacji między starszą wersją jako master i nowszą wersją jako slave. Kiedy ma nastąpić uaktualnienie, po prostu dokonaj „przełączenia”, czyniąc slave'a nowym masterem, a stary master staje się slave'em. Gdy uaktualnienie zakończy się sukcesem, zlikwiduj klaster replikacji Slony i zamknij starą bazę danych.

Wysoka dostępność dzięki częstej konserwacji serwera

Podobnie jak minimalny czas przestoju na aktualizacje, konserwację serwera można łatwo wykonać bez przestojów, wykonując „przełączanie” między dwoma lub większą liczbą węzłów, umożliwiając ponowne uruchomienie urządzenia podrzędnego z aktualizacjami / inną konserwacją. Gdy urządzenie podrzędne wróci do trybu online, ponownie połączy się z klastrem replikacji i przechwyci wszystkie zreplikowane dane. Użytkownicy końcowi łączący się z bazą danych mogą mieć zakłócone długie transakcje, ale sam przestój będzie trwał kilka sekund po przełączeniu, a nie ile czasu zajmuje ponowne uruchomienie/aktualizacja hosta.

Wysyłka dziennika

Chociaż prawdopodobnie nie będzie to popularne rozwiązanie, urządzenie podrzędne Slony można skonfigurować jako węzeł „wysyłania dziennika”, w którym wszystkie dane otrzymane przez replikację mogą być zapisywane w plikach SQL i wysyłane. Może to być używane z różnych powodów, takich jak ręczne zapisywanie na dysku zewnętrznym i przenoszenie do podrzędnej bazy danych, a nie przez sieć, skompresowane i przechowywane zarchiwizowane na potrzeby przyszłych kopii zapasowych, a nawet zlecanie zewnętrznemu programowi analizowania plików SQL i modyfikować zawartość.

Udostępnianie wielu baz danych

Ponieważ dowolna liczba tabel może być replikowana, zestawy replikacji Slony można skonfigurować tak, aby udostępniały określone tabele między bazami danych. Chociaż podobny dostęp można uzyskać za pomocą zewnętrznych opakowań danych (które zostały ulepszone w ostatnich wydaniach PostgreSQL), lepszym rozwiązaniem może być użycie Slony w zależności od zastosowania. Jeśli potrzebna jest duża ilość danych do pobrania z jednego hosta na drugi, zreplikowanie tych danych przez Slony oznacza, że ​​potrzebne dane będą już istniały w żądającym węźle, eliminując długi czas przesyłania.

Opóźniona replikacja

Zwykle pożądane jest, aby replikacja była jak najszybsza, ale mogą istnieć scenariusze, w których pożądane jest opóźnienie. Demon slon dla węzła podrzędnego można skonfigurować z lag_interval, co oznacza, że ​​nie otrzyma żadnych danych replikacji, dopóki dane nie będą stare, jak określono. Może to być przydatne do szybkiego dostępu do utraconych danych, jeśli coś pójdzie nie tak, na przykład jeśli wiersz zostanie usunięty, pozostanie on na urządzeniu podrzędnym przez 1 godzinę w celu szybkiego odzyskania.

Co warto wiedzieć:

• Wszelkie zmiany DDL w tabelach, które są częścią replikacji, muszą być wykonane przy użyciu polecenia slonik execute.
• Każda replikowana tabela musi mieć albo klucz podstawowy, albo UNIKALNY indeks bez kolumn dopuszczających wartość null.
• Dane replikowane z węzła głównego są replikowane po tym, jak jakiekolwiek dane mogły zostać wygenerowane funkcjonalnie. Oznacza to, że jeśli dane zostały wygenerowane przy użyciu czegoś takiego jak „random()”, wynikowa liczba jest przechowywana i replikowana na urządzeniach podrzędnych, a nie „random()” uruchamiana ponownie na urządzeniu podrzędnym zwracającym inny wynik.
• Dodanie replikacji Slony nieznacznie zwiększy obciążenie serwera. Chociaż efektywnie napisana, każda tabela będzie miała wyzwalacz, który rejestruje każde INSERT, UPDATE i DELETE w tabeli Slony, spodziewaj się około 2-10% wzrostu obciążenia serwera, w zależności od rozmiaru bazy danych i obciążenia.

Wskazówki i wskazówki:

• Demony Slony mogą działać na dowolnym hoście, który ma dostęp do wszystkich innych hostów, jednak najwydajniejszą konfiguracją jest uruchomienie demonów na zarządzanych przez nich węzłach. Na przykład demon główny działający na węźle głównym, demon podrzędny działający na węźle podrzędnym.
• Jeśli konfigurujesz klaster replikacji z bardzo dużą ilością danych, początkowa kopia może zająć dość dużo czasu, co oznacza, że ​​wszystkie zmiany, które zajdą od rozpoczęcia do ukończenia kopii, mogą oznaczać jeszcze więcej czasu na nadrobienie zaległości i synchronizację . Można to rozwiązać, dodając kilka tabel naraz do replikacji (bardzo czasochłonne) lub tworząc kopię katalogu danych głównej bazy danych do urządzenia podrzędnego, a następnie wykonując „zestaw subskrypcji” z opcją OMIŃ KOPIOWANIE ustawioną na PRAWDA. Dzięki tej opcji Slony założy, że tabela podrzędna jest w 100% identyczna z tabelą główną, i nie wyczyści jej i nie przekopiuje danych.
• Najlepszym scenariuszem jest utworzenie Hot Standby przy użyciu wbudowanych narzędzi dla PostgreSQL, a podczas okna konserwacji bez połączeń modyfikujących dane, przełączenie trybu gotowości online jako mastera, sprawdzenie zgodności danych między nimi, zainicjowanie klaster replikacji slony z opcją OMIT COPY =true, a na koniec ponownie włącz połączenia klienckie. Konfiguracja gorącego trybu gotowości może zająć trochę czasu, ale proces ten nie spowoduje ogromnego negatywnego wpływu na klientów.

Społeczność i dokumentacja

Społeczność Slony można znaleźć na listach dyskusyjnych znajdujących się pod adresem http://lists.slony.info/mailman/listinfo/slony1-general, które obejmują również archiwa.

Dokumentacja jest dostępna na oficjalnej stronie internetowej http://slony.info/documentation/ i zapewnia pomoc w analizie logów oraz specyfikacji składni dla połączenia ze slony.