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

Prezentace na téma: "Nejsem nasr… štvanej! PostgreSQL replikace master-slave Slony I."— Transkript prezentace:

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
PostgreSQL Replicator PG Replication DB Balancer Usogres eRServer RServ improved 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 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.

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. 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 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. 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.

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

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 a master with one or more slaves nodes. Not all slave nodes must receive the replication data directly from the master. Every node that receives the data from a valid 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 transactions from the client applications, has only a limited capability to satisfy the slave nodes queries during the replication process. In order to satisfy the need for a big number 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 site while 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 to multiple slave configuration, it is unlikely that all slave nodes are exactly in the same synchronization status when the master fails. To ensure that one slave can be promoted to the master it is necessary that all remaining systems can agree on 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 generated and applied at least to the new master (if that’s not the same system) before the promotion can occur. Nevadí když někdo spadne.

13 Nodes, Sets and forwarding
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 set should contain a group of objects that is independant from other objects originating from the same master. In short, all tables that have relationships that could be expressed as foreign key constraints and all the sequences used to generate any serial numbers in these tables should be contained in one and the same set.

14 Exchanging messages All configuration changes like adding nodes, subscribing or unsubscribing sets, adding a table to a set and so for the are communicated through the systém as events. An event is generated by inserting the event information into a table and notifying all listeners on the same. SYNC messages are communicated with the same mechanism. The Slony-I system configuration contains information for every node which other 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.