Hlavní navigace

Slony1 - Replikace pro PostgreSQL

22. 7. 2004
Doba čtení: 6 minut

Sdílet

Replikace pro PostgreSQL je stále oblíbené téma. Vzniklo a zaniklo už nemálo replikačních projektů. Slony1 je jedním z nově vzniklých.

Slony

Replikace pro PostgreSQL byla odjakživa velice lákavá. Lákala nejen programátory, ale především provozovatele databázových systémů, kteří ji využívají k zálohám a k distribuci zátěže. Za poměrně dlouhou dobu existence databáze PostgreSQL vzniklo a také zaniklo už mnoho replikačních řešení.

Připomeňme si projekty zabývající se replikací databáze v prostředí PostgreSQL.

V contrib adresáři standardní distribuce PostgreSQL najdeme ještě projekty rserv a dbmirror.

Proč existuje tolik projektů, které dělají téměř totéž? Není lepší pořádně odladit jeden projekt než zase začínat nový? Inu, programátoři (a DB zvlášť) jsou značně vybíraví, pokud jde o použitý programovací jazyk. Kromě mírně odlišné koncepce má použití neoblíbených programovacích jazyků v tomto případě za následek vytvoření nového projektu. A tak různé (a veskrze funkční) projekty upadají do nemilosti kvůli programovacímu jazyku, ve kterém byly vytvořeny. Například u dbmirroru je to kvůli Perlu, u erserveru je to kvůli Javě, RServ improved je založen na erserveru, ovšem s vykuchanou Javou. Většina těchto projektů používá trigger-based store and forward řešení. To není zas tak těžké naprogramovat, např. RServ improved má pouhých 30 kB. Těžší je dotáhnout řešení do konce, a to zejména v oblasti administrace.


A máme tu další projekt! Slony je napsán v praxí ověřeném a v opensource komunitě bezproblémovém jazyce C. Mezi největší pozitíva projektu patří hlavně to, že byl dobře přijat programátorskou i uživatelskou komunitou, což se předchozím projektům nepodařilo. Slony by tak měl sjednotit současné práce na téma replikace.

Slony je zajímavý tím, že slave databáze se mohou replikovat nejen z master databáze, ale i jedna od druhé (cascading slaves). Tato vlastnost je velmi důležitá, protože z hlediska výkonnosti je nejlepší používat master databázi pouze pro write access. Replikační dotazy slave databází zbytečně master databázi zatěžují, a co je horší, mohou držet nějaké zámky během své replikace, které brání master databázi v zápisových operacích do replikačního žurnálu.

Hlavní rysy projektu Slony1

  • nástupce eRServeru
  • asynchroní replikace
  • trigger based
  • cascading slaves
  • batch mode
  • store and forward
  • pull based
  • LAN optimised
  • online replikační systém
  • instalace bez nutnosti zastavení aplikace
  • vytvoření repliky bez nutnosti zastavení hlavní aplikace
  • podpora různých verzí PostgreSQL 7.3 i 7.4
  • manuální failover
  • manuální switchover
  • manuální switchback

Press release představující projekt je zde. Více o celkové koncepci systému Slony si přečtěte v tomto zajímavém dokumentu. Nástupce Slony2 je v současné době pouze v design fázi a bude se jednat o synchronní replikační systém.

Vysvětlení některých pojmů z oblasti replikace DB

asynchroní replikace
Není zaručeno, že ve stejném časovém okamžiku budou na všech uzlech clusteru shodná data.
trigger based
Nad replikovanými tabulkami jsou vytvořeny triggery provádějící záznam měněných dat do replikačního žurnálu. Opakem je replikační mechanismus zabudovaný v DB serveru.
cascading slaves
Vysvětleno výše.
batch mode
Při změně dat na slave uzlech není postupováno po jednotlivých transakcích tak, jak byly prováděny na master uzlu. Transakce jsou přehrávány na slave uzlech po dávkách. Jedna dávka obvykle reprezentuje určitý časový úsek na master uzlu.
store and forward
Změny jsou nejprve ukládány do žurnálu a teprve protom jsou přenášeny na další uzly. Uzly přistupují pouze k žurnálu a ne k originálním tabulkám.
pull based
Slave uzel žádá master uzel o zaslání balíku transakcí. Master uzel sám od sebe nic nikam neposílá.
optimalizace pro LAN
Předpokládá se velká šířka přenosového pásma mezi jednotlivými uzly a neprovádějí se operace, které následně snižují velikost balíku transakcí určeného k přenosu. Pokud je jedna řádka měněna v jedné dávce transakcí několikrát, nebudou redundantní změny před přenosem dat zrušeny.
online replikační systém
Souvisí s předchozím bodem. Při návrhu se předpokládala vysoká vzájemná dostupnost jednotlivých uzlů během normálního provozu.
manuální failover
Uzel je možné v případě havárie přetransformovat z pozice slave na pozici master. Tato operace není prováděna automaticky.
switchover
Podobná operace jako v předchozím případě, ovšem beze ztráty dat v podobě nejnovějších transakcí.
switchback
Opak operace switchover.

Překlad

Překlad slony vyžaduje zdrojové kódy stejné major verze PostgreSQL, jako máme nainstalovanou. Rozbalíme tedy nejprve PostgreSQL tarball a provedeme configure. Nemusíme ovšem znovu překládat celou databázi, stačí, když v adresářích ${PGSQL_SRC}/­src/interfaces/lib­pq a${PGSQL_SRC}­/src/port provedeme (g)make all. Pak spustíme configure ze slony s parametrem –with-pgsourcetree=${PGSQL_SR­C} a pokračujeme klasicky. t.j. make install. Nemusíme mít žádné obavy, instalace slony nedělá žádné zásahy do běžící databáze, jen nainstaluje pár binárek a scriptů.

Instalace

Slony vyžaduje nainstalovaný procedurální jazyk pl/PgSQL (createlang plpgsql). Dále potřebujeme vytvořit uživatele slony, a to jak v systému, tak v databázi. Databázový uživatel slony musí mít superuživatelská práva. Vytváření systémového uživatele sice není nezbytně nutné, ale ulehčí to konfiguraci autorizace v replikačním systému. Pokud chcete replikovat i nelokální databáze, musí být PostgreSQL nakonfigurován s povoleným vzdáleným přístupem. Minimálně tedy tcpip_socket=true v postgresql.conf a v pg_hba.conf záznam umožňující vzdálený přístup uživateli slony z naší lokální sítě: host all slony 192.168.0.0 255­.255.0.0 md5. Změněnou konfiguraci načte PostgreSQL po příkazu pg_ctl reload.

Konfigurace

Konfigurace replikačních systémů obvykle není ani snadná ani jednoduchá. Pokud čekáte klikací konfigurovadlo – není. Pokud čekáte konfigurační nástroj ve stylu interpretru příkazů psql – není, pokud čekáte konfigurovadlo ve stylu command line argumentů, jako je pw useradd – není. Konfigurace není ani řešena přes konfigurační soubor. Pokud čekáte konfiguraci pomocí INSERTů do systémových tabulek replikátoru, tak taky marně. Konfigurace je v současné době (1.0) řešena způsobem, který pokládám za nejhorší možné řešení. Autoři si vytvořili vlastní konfigurační jazyk a napsali program slonik, který je jeho interpretrem. Tento interpretr čte příkazy ze standardního vstupu a vykonává je.

Za nejlepší řešení v oblasti konfigurace replikačních systémů považuji konfiguraci prováděnou přímým zápisem do systémového replikačního katalogu. INSERTovat a UPDATEovat záznamy zvládá každý databázový administrátor bez problémů a systémové katalogy navíc nejsou moc složité. Replikační server s tím ovšem musí počítat a mít připravené triggery zabraňující chybné konfiguraci a provádějící následné zpracovávání změn. Konfiguraci prováděnou tímto způsobem lze velmi dobře zálohovat a navíc v ní jde jazykem SQL provádět dávkové změny.

V distribuci slony1 existuje script slony_setup.pl, který vám pomůže s úvodní konfigurací. Zeptá se vás na několik otázek a vygeneruje shell script, který nainstaluje a případně deinstaluje replikační systém replikující dvě databáze shodného jména na rozdílných uzlech.

Pokud vážně uvažujete o produkčním nasazení Slony, doporučuji tento script nepoužívat a snažit se proniknout do tajů ruční konfigurace. Až budete potřebovat změnit nastavení replikace, tak jen s instalačním scriptem nevystačíte. Proto si dále ukážeme pouze konfiguraci ruční. HTML manuál ke konfiguračnímu jazyku najdete v src/howto. V příkladech v následujících dílech budeme pro jednoduchost replikovat dvě databáze na stejném stroji a tuto konfiguraci stejně

root_podpora

slony_setup.pl neumí.

Cílem celého následujícího Slony1 howto je seznámení se se systémem Slony1 natolik, abychom jej mohli poté využít v produkčním nasazení. Slony1, ačkoliv ve verzi 1.0, je vhodný pro produkční nasazení. Systém byl poměrně dlouhou dobu testován a dolaďován. Jeho vývoj byl sponzorován společností Afilias provozující registraci domén. Hlavní vývojář Slony1 – Jan Wieck – je jejím zaměstancem.

Byl pro vás článek přínosný?