Replikace dat mezi více databázemi
Vyrobíme si další databázi slave2 a připojíme ji k databázi master. Vše bylo již dříve probíráno, takže jen stručně. Jako unixový uživatel slony provedeme:
%createdb slave2 CREATE DATABASE %createlang plpgsql slave2
do souboru setup.slonik vložíme další záznam o spojení do db:
NODE 3 ADMIN CONNINFO = 'host=localhost user=slony password=iehovah
dbname=slave2'; a přidáme následné příkazy, které vytvoří replikační katalog a přidají tuto databázi do clusteru dharma.
STORE NODE( id = 3, COMMENT = 'Druha slave databaze');
STORE PATH ( client = 3,server = 1, conninfo = 'dbname=master host=localhost user=slony password=iehovah');
STORE PATH ( client = 1,server = 3, conninfo = 'dbname=slave2 host=localhost user=slony password=iehovah');
STORE LISTEN ( origin=3, receiver=1);
STORE LISTEN ( origin=1, receiver=3); Vše by mělo proběhnout bez problémů:
%slonik < setup.slonik %
Spustíme agenty pro všechny naše dosavadní databáze master, slave1, slave2 a podíváme se, co si vyměnili mezi sebou za údaje o novém uzlu.
Nejprve se podíváme do master databáze. Zavoláním stored procedury cleanupEvent vynutíme okamžité provedení úklidu již zpracovaných dat, což značně zpřehlední následující výpisy tabulek.
%psql master
master=# SELECT _dharma.cleanupEvent();
cleanupevent
--------------
0
(1 row)
master=# SELECT * from _dharma.sl_confirm ;
con_origin | con_received | con_seqno | con_timestamp
------------+--------------+-----------+----------------------------
3 | 2 | 0 | 2004-07-22 15:36:05.213015
2 | 3 | 409 | 2004-07-22 15:36:04.934888
2 | 1 | 423 | 2004-07-22 15:53:35.246455
3 | 1 | 11 | 2004-07-22 15:53:53.801308
1 | 3 | 2091 | 2004-07-22 15:53:54.284228
1 | 2 | 2091 | 2004-07-22 15:53:54.252447
(6 rows)
master=# SELECT ev_origin,ev_seqno,ev_type from _dharma.sl_event;
ev_origin | ev_seqno | ev_type
-----------+----------+--------------
2 | 409 | SYNC
3 | 1 | STORE_PATH
3 | 2 | STORE_LISTEN
2 | 410 | SYNC
2 | 411 | SYNC
2 | 412 | SYNC
3 | 3 | SYNC
2 | 413 | SYNC
2 | 414 | SYNC
2 | 415 | SYNC
2 | 416 | SYNC
3 | 4 | SYNC
2 | 417 | SYNC
3 | 5 | SYNC
2 | 418 | SYNC
[....] Z výpisu vidíme dvě věci:
- V tabulce potvrzení jsou záznamy i pro potvrzení ve směrech 3–2 a 2–3.
- V tabulce událostí zbyly záznamy i přes vynucené provedení úklidu. Toto je rychlá diagnostická metoda správnosti konfigurace clusteru.
Zejména z bodu 2 je vidět, že naše konfigurace je chybná, protože databáze 2 a 3 spolu touží komunikovat, což jim dosavadní konfigurace neumožňuje. Potvrzení číslo 409 ve směru 2–3 znamená, že uzel 3 byl vytvořen v okamžiku události 409 na uzlu č. 2. První událostí, kterou uzel číslo 3 z uzlu 2 zpracuje, bude 410, v opačném směru to bude 1.
Teď jsme narazili na další nemilou vlastnost replikačního systému Slony1, a to, že všechny databáze musí být navzájem propojené, i když vzhledem k vzájemné replikaci dat nemají spolu nic do činění. Je to nutné pro replikaci konfiguračních událostí, které se při změně konfigurace generují na příslušných uzlech. Kdyby se generovaly na master uzlu a na ostatní uzly by se dostaly replikací, tento problém by nenastal. Pokud počítáte databáze v clusteru na kusy, není to problém. Pokud je ale počítáte po desítkách, tak to již problém je. V tomto případě doporučuji nedávat všechny databáze do jednoho clusteru, ale vytvořit clusterů několik. Jedna databáze může být členem několika clusterů současně. Administrace takového monstra však nebude snadná.
V našem případě nebudeme propojovat databáze slave1 a slave2 vzájemně, ale využijeme stávající spojení přes databázi master.
STORE LISTEN (origin = 3, receiver = 2, provider = 1);
STORE LISTEN (origin = 2, receiver = 3, provider = 1); Nyní je již propojení všech tří databází v pořádku. Pokud provedeme výše uvedené selecty, uvidíme, že se nám již žádné záznamy nehromadí. Nyní již můžeme zreplikovat data na uzel slave2. Po vytvoření příslušných tabulek podle dříve uložené definice můžeme přihlásit uzel 3 k odběru dat od uzlu 1.
SUBSCRIBE SET ( ID = 1, PROVIDER = 1, RECEIVER = 3, FORWARD = NO ); Prvotní kopie dat se se ovšem nemusí vždy vytvořit ihned:
DEBUG2 localListenThread: Received event 3,71 SUBSCRIBE_SET
CONFIG storeSubscribe: sub_set=1 sub_provider=1 sub_forward='f'
DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled)
DEBUG2 remoteListenThread_1: queue event 1,2151 ENABLE_SUBSCRIPTION
DEBUG2 remoteWorkerThread_1: Received event 1,2151 ENABLE_SUBSCRIPTION
DEBUG1 copy_set 1
DEBUG1 remoteWorkerThread_1: connected to provider DB
WARN remoteWorkerThread_1: transactions earlier than XID 2548373 are still in progress
WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 15 seconds V tomto případě je nutné čekat, až budou dřívější transakce ukončeny. V případě, že se nám nechce čekat, je nutné vystopovat příslušné uživatele s dosud otevřenými transakcemi a odpojit je. Tyto transakce nejsou navíc database-wide, ale postmaster-wide. Problém s aktivními transakcemi bránící replikaci nastává pouze v okamžiku vytváření prvotní kopie dat.
Cascading slaves
Slave databáze se ale nemusí připojovat pouze k master databázi. Replikační systém Slony1 umí replikovat slave databáze od jiných slave databází. Vytvoříme databázi c1slave2, kterou budeme replikovat z nově vytvořené databáze slave2.
příkazy pro shell
%createdb c1slave2 CREATE DATABASE %createlang plpgsql c1slave2
a pro slonika
NODE 4 ADMIN CONNINFO = 'host=localhost user=slony password=iehovah
dbname=c1slave2';
STORE NODE( id = 4, COMMENT = 'Kaskada 1 ze slave2');
STORE PATH ( client = 4,server = 3, conninfo = 'dbname=slave2 host=localhost user=slony password=iehovah');
STORE LISTEN ( origin = 3, receiver = 4);
STORE LISTEN ( origin = 2, receiver = 4, provider = 3);
STORE LISTEN ( origin = 1, receiver = 4, provider = 3);
STORE PATH ( client = 3,server = 4, conninfo = 'dbname=c1slave2 host=localhost user=slony password=iehovah');
STORE LISTEN ( origin = 4, receiver = 3);
STORE LISTEN ( origin = 4, receiver = 2, provider = 1);
STORE LISTEN ( origin = 4, receiver = 1, provider = 3); Se čtvrtou databází se nám konfigurace už trochu začíná komplikovat. Pro udržení přehlednosti konfiguračního scriptu doporučuji používat výše uvedené řazení příkazů PATH a LISTEN. Pokud provedete výše zmíněný select, uvidíte že naše konfigurace je správná: v tabulce _dharma.sl_event jsou jen čtyři řádky.
Po ručním vytvoření tabulek přihlásíme uzel č.4 k odběru dat z uzlu č.3
SUBSCRIBE SET ( ID = 1, PROVIDER = 3, RECEIVER = 4, FORWARD = NO ); Databáze c1slave2 si připojí k slave2 a provede full copy tabulek. Vyrobíme nějaké změny na masteru
%pgbench -t 200 master
starting vacuum...end. transaction type: TPC-B (sort of) scaling
factor: 5 number of clients: 1 number of transactions per client: 200
number of transactions actually processed: 200/200 tps = 8.239771
(including connections establishing) tps = 8.254090 (excluding
connections establishing)
% Pohledem na obrazovky jednotlivých replikačních agentů zjistíme, že uzly 2 a 3 replikují data, zatímco uzel 4 nikoliv. Uzlu 3 jsme totiž neřekli v příkazu SUBSCRIBE, že má protokolační data uschovávat k forwardování na další uzel. Pokud propátráme replikační žurnál na uzlu slave2, tak v něm žádné změny nenalezneme. Na uzlu master dopadneme stejně.
slave2=# SELECT * from _dharma.sl_event;
ev_origin | ev_seqno | ev_timestamp | ev_minxid | ev_maxxid | ev_xip | ev_type | ev_data1 | ...
-----------+ ---------+ ---------------------------+ ----------+ ----------+ --------------------+ --------+ ---------+ ...
1 | 2328 | 2004-07-27 19:19:36.312899 | 2567211 | 2580651 | '2567211' | SYNC | | ...
1 | 2329 | 2004-07-27 19:20:36.438731 | 2567211 | 2581003 | '2567211','2581001' | SYNC | | ...
4 | 38 | 2004-07-27 19:20:02.723145 | 2567211 | 2580759 | '2567211' | SYNC | | ...
3 | 152 | 2004-07-27 19:20:29.953424 | 2567211 | 2580853 | '2567211' | SYNC | | ...
2 | 572 | 2004-07-27 19:20:31.683413 | 2567211 | 2580926 | '2567211' | SYNC | | ...
(5 rows) Změněná data jsou v tomto okamžiku už nenávratně pryč. To však nemusí být vždy nežádoucí. Tato vlastnost replikačního systému Slony1 se dá využít pro vytváření snapshotů dat.
V naprosté většině případů se nám však stalo to, co jsme původně nechtěli. Pokud budeme chtít uzel č.4 sesynchronizovat, bude nutné opětovně provést full copy tabulek, což může být podle objemu dat i mnohahodinová operace.
Uzel slave2 přepneme do forward režimu. Od tohoto okamžiku se již budou změny prováděné na masteru replikovat až na c1slave2.
SUBSCRIBE SET ( ID = 1, PROVIDER = 1, RECEIVER = 3, FORWARD = YES ); Předchozí ztracené změny ovšem na c1slave2 nebudou, a proto tato databáze nebude synchronizována s master. Toto chování považuji na hrubý nedostatek replikačního systému Slony1, protože podle mých zkušeností na to většina administrátorů přijde, až když je pozdě.
Po provedení následujících příkazů bude již replikace v pořádku.
UNSUBSCRIBE SET ( ID = 1, RECEIVER = 4);
SUBSCRIBE SET ( ID = 1, PROVIDER = 3, RECEIVER = 4, FORWARD = NO ); A tímto bychom pro dnešek skončili…
