Hlavní navigace

Slony1 - Replikace pro PostgreSQL (5)

Radim Kolář 26. 8. 2004

Dnes budeme probírat replikaci dat v clusteru pro mírně pokročilé.

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 sesynchro­nizovat, 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…

Našli jste v článku chybu?
Vitalia.cz: Jak koupit Mikuláše a nenaletět

Jak koupit Mikuláše a nenaletět

Lupa.cz: E-shopy: jen sleva už nestačí

E-shopy: jen sleva už nestačí

Vitalia.cz: Vláknina: Rozpustná, nebo nerozpustná?

Vláknina: Rozpustná, nebo nerozpustná?

Podnikatel.cz: Přivýdělek u Airbnb nebo Uberu? Čekejte kontrolu

Přivýdělek u Airbnb nebo Uberu? Čekejte kontrolu

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Žloutenka v Brně: Nakaženo bylo 400 lidí

Žloutenka v Brně: Nakaženo bylo 400 lidí

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

DigiZone.cz: Další dva kanály nabídnou HbbTV

Další dva kanály nabídnou HbbTV

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Vitalia.cz: Říká amoleta - a myslí palačinka

Říká amoleta - a myslí palačinka

DigiZone.cz: Flix TV má set-top box s HEVC

Flix TV má set-top box s HEVC

Podnikatel.cz: Prodává přes internet. Kdy platí zdravotko?

Prodává přes internet. Kdy platí zdravotko?

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET