Nejsem nasr … štvanej !

1. Nejsem nasr… štvanej! PostgreSQL replikace master-slave Slony I

2. Proč replikovat databázi? Od toho máme předmět KIV/DS :-) 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.

3. Projekty zabývající se replikací databáze v prostředí PostgreSQL • PostgreSQLReplicator • PG Replication • DB Balancer • Usogres • eRServer • RServimproved V contrib adresáři standardní distribuce PostgreSQL najdeme ještě projekty rserv a dbmirror.

4. Proč? 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

5. Slony I A máme tu další projekt! je napsán v praxí ověřeném a v opensource komunitě bezproblémovém jazyce C - dobře přijat programátorskou i uživatelskou komunitou - Slony by tak měl sjednotit současné práce na téma replikace

6. Slony je zajímavý.. Databáze se mohou replikovat nejen z master databáze, ale i jedna od druhé Z hlediska výkonnosti je nejlepší používat master databázi pouze pro writeaccess 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.

7. Hlavní rysy Slony I nástupce eRServeru asynchroní replikace Není zaručeno, že ve stejném časovém okamžiku budou na všech uzlech clusteru shodná data. triggerbased 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. cascadingslaves databáze se mohou replikovat nejen z master databáze, ale i jedna od druhé 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. storeandforward 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.

8. Hlavní rysy Slony I pullbased 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.

9. Clustery Databáze spřátelené za účelem replikace jsou organizovány do clusterů Jedna databáze může být současně členem více clusterů, naopak cluster může mít právě jednu řídící master databázi. V terminologii slony se jednotlivé databáze zapojené do clusteru nazývají uzly – NODE Master databáze clusteru musí být na uzlu s pořadovým číslem 1. a je velmi důležitý Jednotlivéslave uzly lze do clusteru přidávat a odebírat, nelze však přehodit status clustermaster z jednoho uzlu na druhý, aniž bychom museli zlikvidovat celý cluster. Znovuvytvoření clusteru není zase tak náročná operace. Status Master databáze v clusteru nemá nic společného se zdrojem dat pro replikaci, data lze replikovat i mezi jednotlivými slave databázemi nebo směrem slave – master. Slony je single-master replikační systém. To znamená, že pokud replikujeme set tabulek, je možné do tohoto setu zapisovat právě na jednom NODE. Nezáleží na tom, zda má tento node v clusteru status master, nebo slave.

10. Agenti Program, který předává zprávy mezi jednotlivými databázemi a zpracovává zprávy pro něj určené. Ve své činnost se podobá např. činnosti SMTP mailserveru. Pro každou databázi potřebujeme právě jednoho agenta na cluster. Pokud je databáze členem více clusterů, budete potřebovat spustit více agentů. Každý agent se připojí do své lokální databáze 4× a každých 10 sekund kontroluje tabulku událostí, které se následně snaží zpracovávat. Standardně jsou SYNC události generovány každých 60 sekund. Protože oba dva agenty máme v současné době připojeny pouze k jejich lokálním databázím, hromadí se nám v tabulce lokálně generované eventy, které nikdo nezpracovává. Kromě toho agent ještě provádí každých pět minut vymazání předaných eventů a po 30 minutách dokonce i s následným VACUUM.

11. A teď pár faktů z oficiálního webu..

12. Master to multiple cascaded slaves The basic structure of the systems combined in a Slony-I installation is amaster with one or more slaves nodes. Not all slave nodes must receive the replicationdata directly from the master. Every node that receives the data from avalid source can be configured to be able to forward that data to other nodes.There are three distinct ideas behind this capability. The first is scalability(škálovatelnost).One database, especially the master that receives all the update transactionsfrom the client applications, has only a limited capability to satisfy the slavenodes queries during the replication process. In order to satisfy the need for a bignumber of read-only slave systems it must be possible to cascade. Mater neobsluhuje všechny servery. The second idea is to limit the required network bandwidth for a backup sitewhile keeping the ability to have multiple slaves at the remote location. The third idea is to be able to configure failover scenarios. In a master tomultiple slave configuration, it is unlikely that all slave nodes are exactly in thesame synchronization status when the master fails. To ensure that one slave canbe promoted to the master it is necessary that all remaining systems can agreeon the status of the data. Since a committed transaction cannot be rolled back,this status is undoubtly the most recent sync status of all remaining slave nodes.The delta between this one and every other node must be easily and fast generatedand applied at least to the new master (if that’s not the same system) beforethepromotioncanoccur. Nevadí když někdo spadne.

13. Nodes, Setsandforwarding The Slony-I replication system can replicate tables and sequence numbers. Replicating sequence numbers is not unproblematic. Table and sequence objects are logically grouped into sets. Every setshould contain a group of objects that is independant from other objects originatingfrom the same master. In short, all tables that have relationships that couldbe expressed as foreign key constraints and all the sequences used to generateany serial numbers in these tables should be contained in one and the same set.

14. Exchangingmessages All configuration changes like adding nodes, subscribing or unsubscribingsets, adding a table to a set and so for theare communicated through the systémas events. An event is generated by insertingthe event information into a tableand notifying all listeners on the same. SYNC messages are communicated withthesamemechanism. The Slony-I system configuration contains information for every node whichother it will query for which events.

15. Závěrem Slony umožňuje topologii s jedním vydavatelem a více odběrateli. Jedná se tedy o jednosměrnou distribuci změn. Je však možné, aby jedna instance PostgreSQL byla jak odběratelem, tak vydavatelem. Slony také blokuje změny dat u odběratelů. Tato funkcionalita je zabezpečena přidáním spouště využívající funkci deny_access(), ta blokuje všechny operace INSERT, DELETE, UPDATE, které nejsou volány programem Slony.