sql >> Databáze >  >> RDS >> PostgreSQL

Odborný průvodce replikací Slony pro PostgreSQL

Co je Slony?

Slony-I (dále jen ‚Slony‘) je replikační systém třetí strany pro PostgreSQL, jehož historie sahá až do doby před verzí 8.0, díky čemuž je jednou ze starších možností replikace. Funguje jako metoda replikace založená na spouštěči, která je řešením „master to multiple slave“.

Slony funguje tak, že instaluje spouštěče na každou tabulku, která se má replikovat, na master i slave, a pokaždé, když tabulka dostane INSERT, UPDATE nebo DELETE, zaprotokoluje, který záznam se změnil a jaká je změna. Vnější procesy, nazývané ‚slon démoni‘, se připojují k databázím jako jakýkoli jiný klient a načítají změny z hlavního serveru, poté je přehrají na všech podřízených uzlech přihlášených k hlavnímu serveru. V dobře fungujícím nastavení replikace je tato asynchronní lze očekávat, že replikace bude za hlavním serverem zpožďovat 1 až 20 sekund.

V době psaní tohoto článku je nejnovější verze Slony ve verzi 2.2.6 a podporuje PostgreSQL 8.3 a vyšší. Podpora pokračuje dodnes s menšími aktualizacemi, ale pokud budoucí verze PostgreSQL změní základní funkce transakcí, funkcí, spouštěčů nebo jiných základních funkcí, projekt Slony se může rozhodnout ukončit velké aktualizace na podporu takových drastických nových přístupů.

Maskotem PostgreSQL je slon známý jako „Slonik“, což je rusky „malý slon“. Vzhledem k tomu, že tento replikační projekt se týká mnoha databází PostgreSQL, které se navzájem replikují, je použito ruské slovo pro slony (množné číslo):Slony.

Koncepty

  • Cluster:Instance replikace Slony.
  • Uzel:Specifická databáze PostgreSQL jako replikační uzel Slony, který funguje jako hlavní nebo podřízený pro sadu replikace.
  • Sada replikace:Skupina tabulek a/nebo sekvencí, které mají být replikovány.
  • Odběratelé:Odběratel je uzel, který je přihlášen k odběru replikační sady a přijímá události replikace pro všechny tabulky a sekvence v této sadě z hlavního uzlu.
  • Démoni Slony:Hlavní pracovníci, kteří provádějí replikaci, démon Slony je spuštěn pro každý uzel v sadě replikace a vytváří různá připojení k uzlu, který spravuje, a také k hlavnímu uzlu.

Jak se používá

Slony se instaluje buď ze zdroje, nebo prostřednictvím repozitářů PGDG (PostgreSQL Global Development Group), které jsou dostupné pro linuxové distribuce založené na Red Hatu a Debianu. Tyto binární soubory by měly být nainstalovány na všech hostitelích, kteří budou obsahovat hlavní nebo podřízený uzel v replikačním systému.

Po instalaci se nastaví replikační cluster Slony zadáním několika příkazů pomocí binárního souboru „slonik“. „slonik“ je příkaz s jednoduchou, ale jedinečnou syntaxí pro inicializaci a údržbu slony clusteru. Je to hlavní rozhraní pro vydávání příkazů běžícímu clusteru Slony, který má na starosti replikaci.

Propojení se Slony lze provést buď napsáním vlastních příkazů slonik, nebo kompilací slony s příznakem --with-perltools, který poskytuje skripty „altperl“, které pomáhají generovat tyto potřebné skripty slonik.

Vytvoření replikačního clusteru Slony

„Replikační klastr“ je kolekce databází, které jsou součástí replikace. Při vytváření replikačního clusteru je třeba napsat init skript, který definuje následující:

  • Požadovaný název clusteru Slony
  • Informace o připojení pro každou část uzlů replikace, každá s neměnným číslem uzlu.
  • Výpis všech tabulek a sekvencí, které mají být replikovány jako součást ‚replikační sady‘.

Příklad skriptu lze nalézt v oficiální dokumentaci Slony.

Po spuštění se slonik připojí ke všem definovaným uzlům a na každém vytvoří schéma Slony. Když jsou démoni Slony odhozeni, vymažou všechna data v replikovaných tabulkách na slave (pokud tam nějaká jsou) a zkopírují všechna data z mastera na slave(y). Od tohoto okamžiku budou démoni neustále replikovat změny zaznamenané na hlavním serveru na všechny přihlášené podřízené jednotky.

Chytré konfigurace

I když je Slony zpočátku replikačním systémem typu Master-to-Multiple-Slave a byl používán hlavně tímto způsobem, existuje několik dalších funkcí a chytrých použití, díky kterým je Slony užitečnější než jednoduché řešení replikace. Díky vysoce přizpůsobitelné povaze Slony je stále relevantní pro různé situace pro administrátory, kteří mohou myslet mimo krabici.

Kaskádová replikace

Slony uzly lze nastavit tak, aby kaskádově replikovaly řetězem různých uzlů. Pokud je známo, že hlavní uzel přebírá extrémně těžké zatížení, každý další podřízený uzel toto zatížení mírně zvýší. Díky kaskádové replikaci lze jeden podřízený uzel připojený k hlavnímu uzlu nakonfigurovat jako ‚předávací uzel‘, který pak bude odpovědný za odesílání událostí replikace více podřízeným zařízením, čímž se zatížení hlavního uzlu udrží na minimu.

Kaskádová replikace se Slony

Zpracování dat na podřízeném uzlu

Na rozdíl od vestavěné replikace PostgreSQL nejsou podřízené uzly ve skutečnosti „pouze pro čtení“, pouze tabulky, které se replikují, jsou uzamčeny jako „pouze pro čtení“. To znamená, že na podřízeném uzlu může zpracování dat probíhat vytvořením nových tabulek, které nejsou součástí replikace, do kterých budou uložena zpracovaná data. Tabulky, které jsou součástí replikace, mohou mít také vytvořené vlastní indexy v závislosti na vzorech přístupu, které se mohou lišit od podřízeného a hlavního.

Tabulky pouze pro čtení na podřízených zařízeních mohou mít stále vlastní funkce založené na spouštění při změnách dat, což umožňuje větší přizpůsobení dat.

Zpracování dat na uzlu Slony Slave

Minimální upgrady prostojů

Upgrade hlavních verzí PostgreSQL může být extrémně časově náročný. V závislosti na velikosti dat a počtu tabulek může upgrade včetně procesu „analyzovat“ po upgradu trvat i několik dní. Protože Slony dokáže replikovat data mezi clustery PostgreSQL různých verzí, lze jej použít k nastavení replikace mezi starší verzí jako hlavní a novější verzí jako podřízenou. Když má dojít k upgradu, jednoduše proveďte ‚přepnutí‘, čímž se z otroka stane nový pán a ze starého pána se stane otrok. Když je upgrade označen za úspěšný, vyřaďte replikační cluster Slony z provozu a vypněte starou databázi.

Upgradujte PostgreSQL s minimálními výpadky pomocí Slony

Vysoká dostupnost s častou údržbou serveru

Stejně jako minimální prostoje u upgradů lze údržbu serveru provést snadno bez prostojů provedením „přepnutí“ mezi dvěma nebo více uzly, což umožňuje restartování podřízeného zařízení s aktualizacemi / jinou údržbou. Když se slave vrátí zpět do režimu online, znovu se připojí k replikačnímu clusteru a zachytí všechna replikovaná data. Koncoví uživatelé, kteří se připojují k databázi, mohou mít přerušení dlouhých transakcí, ale samotná prostoje by trvala několik sekund po přepnutí, spíše než jak dlouho trvá restartování / aktualizace hostitele.

Zapsat zásilku

Ačkoli to pravděpodobně nebude populární řešení, může být Slony slave nastaven jako uzel „zasílání protokolů“, kde lze všechna data, která obdrží prostřednictvím replikace, zapsat do souborů SQL a odeslat. To lze použít z různých důvodů, jako je zápis na externí disk a přenos do podřízené databáze ručně, nikoli přes síť, komprimovaný a archivovaný pro budoucí zálohy, nebo dokonce nechat externí program analyzovat soubory SQL a upravit obsah.

Sdílení dat z více databází

Protože lze libovolně replikovat libovolný počet tabulek, lze replikační sady Slony nastavit tak, aby sdílely určité tabulky mezi databázemi. Zatímco podobného přístupu lze dosáhnout pomocí Foreign Data Wrappers (které se v posledních vydáních PostgreSQL zlepšily), může být lepším řešením použít Slony v závislosti na použití. Pokud je potřeba načíst velké množství dat z jednoho hostitele na druhého, Slony replikuje tato data znamená, že potřebná data již budou existovat v žádajícím uzlu, což eliminuje dlouhou dobu přenosu.

Stáhněte si Whitepaper Today Správa a automatizace PostgreSQL s ClusterControlZjistěte, co potřebujete vědět k nasazení, monitorování, správě a škálování PostgreSQLStáhněte si Whitepaper

Zpožděná replikace

Obvykle se požaduje, aby replikace byla co nejrychlejší, ale mohou nastat některé scénáře, kdy je žádoucí zpoždění. Démon slon pro podřízený uzel lze nakonfigurovat s lag_interval, což znamená, že nebude přijímat žádná data replikace, dokud data nebudou stará, jak je uvedeno. To může být užitečné pro rychlý přístup ke ztraceným datům, pokud se něco pokazí, například pokud je smazán řádek, bude existovat na podřízeném zařízení po dobu 1 hodiny pro rychlé načtení.

Co byste měli vědět:

  • Jakékoli změny DDL v tabulkách, které jsou součástí replikace, musí být provedeny pomocí příkazu slonik execute.
  • Každá tabulka, která má být replikována, musí mít buď primární klíč, nebo UNIKÁTNÍ index bez sloupců s možnou hodnotou Null.
  • Data, která jsou replikována z hlavního uzlu, jsou replikována poté, co byla funkčně vygenerována jakákoli data. To znamená, že pokud byla data generována pomocí něčeho jako ‚random()‘, výsledné číslo je uloženo a replikováno na podřízených zařízeních, místo aby ‚random()‘ bylo znovu spuštěno na podřízeném zařízení s jiným výsledkem.
  • Přidání replikace Slony mírně zvýší zatížení serveru. I když je napsána efektivně, každá tabulka bude mít spouštěč, který zaprotokoluje každé INSERT, UPDATE a DELETE do tabulky Slony, očekávejte asi 2-10% nárůst zatížení serveru v závislosti na velikosti databáze a zátěži.

Tipy a triky:

  • Démoni Slony mohou běžet na jakémkoli hostiteli, který má přístup ke všem ostatním hostitelům, avšak nejvýkonnější konfigurací je, aby démoni běželi na uzlech, které spravují. Například hlavní démon běžící na hlavním uzlu, podřízený démon běžící na podřízeném uzlu.
  • Pokud nastavujete replikační klastr s velmi velkým množstvím dat, může počáteční kopie trvat poměrně dlouho, což znamená, že všechny změny, ke kterým dojde od zahájení až po dokončení kopie, mohou znamenat ještě delší dobu, než je dohnat a synchronizovat. . To lze vyřešit buď přidáním několika tabulek najednou do replikace (velmi časově náročné), nebo vytvořením kopie datového adresáře hlavní databáze na slave a následným provedením „souboru odběru“ s možností VYNECHAT KOPIE nastavenou na skutečný. S touto volbou bude Slony předpokládat, že podřízená tabulka je 100% identická s hlavní, a nebude ji mazat a kopírovat data.
  • Nejlepším scénářem je vytvořit Hot Standby pomocí vestavěných nástrojů pro PostgreSQL a během okna údržby s nulovým připojením k úpravě dat přepnout pohotovostní režim online jako hlavní, ověřit shody dat mezi těmito dvěma a zahájit slony replikační cluster s OMIT COPY =true a nakonec znovu povolte připojení klientů. Nastavení Hot Standby může chvíli trvat, ale tento proces nebude mít na klienty velký negativní dopad.

Komunita a dokumentace

Komunitu pro Slony najdete v mailing listech na adrese http://lists.slony.info/mailman/listinfo/slony1-general, které také obsahují archivy.

Dokumentace je k dispozici na oficiálních webových stránkách http://slony.info/documentation/ a poskytuje pomoc s analýzou protokolů a specifikací syntaxe pro propojení se slony.


  1. Změňte formát data pro aktuální relaci na serveru SQL Server

  2. Jak zkontrolovat, zda existuje řádek v MySQL? (tj. zkontrolujte, zda e-mail v MySQL existuje)

  3. Jednotky data a času v MySQL (úplný seznam)

  4. Migrace Amazon RDS (MySQL nebo MariaDB) na On-Prem Server