Dotaz: Synchronizovaná SQL databáze na dvou lokalitách

[jan.rok]

Dobrý den,

dovolím si poprosit o osvětlení toho, jak funguje nebo nefunguje sychronizace SQL databází mezi dvěma lokalitami.

Konkrétní případ třeba takový: Ve dvou lokalitách je stejná aplikace (nemusí nutně běžet najednou), která používá SQL databázi. Bylo by ideální, kdyby tatáž data byla v daném okamžiku na obou místech. Je možné toto zajistit třeba Dropboxem? Hrozí nebezpečí, že když bude aplikace pracovat s databází a zároveň ji bude synchronizovat přes Dropbox, že dojde k porušení dat? Pokud ano, jak tedy funguje replikace databází třeba v MSSQL? Není to něco podobného?

Nebo je rozdíl v tom, že Dropbox pracuje na úrovni souborů, kdežto replikace na úrovni vět? Neřeší riziko porušení dat právě transakční způsob zpracování?

Děkuji za vysvětlení. Honza

---

---

Odpovědi

[jan.rok]

Záleží, jakým způsobem chceš rozložení zátěže, případně failover řešit.
HA řešení, kdy na více místech máš stejná data pro zápis i pro čtení jsou poněkud náročná a je to podle mně úplně jiný svět (reálně syncovat tisíce transakcí mezi dvěma lokalitama s dobrýma odezvama).
Nejčastější je klasicky master-slave replikace, kdy master db je otevřena jak pro čtení, tak pro zápis, tak slave db je jen pro čtení.
Dobrým postupem je HA řešit i samotnou aplikací. Tzn., nevyvíjet hloupě s tím, že backend a celé HA ti zařídí jen db servery.

Jinak replikace funguje tak, že primární db vytváří v nějakých intervalech(časových, nebo oběmových) transakční soubory, ty se přenášejí do druhé lokality a tam se aplikují do druhé db. Tím se zajistí 100% konzistence dat s minimálním rollbackem a trafikem.
Replikace na úrovni souborů je mimo, tak se to rozhodně neřeší, páč nejde moc dobře zajistit 100% konzistentní stav.
Zdar Max

[EtDirloth]

Pekne zhrnute.

Poznamka k file-based replikacii: v PostgreSQL bola prva (a stale pouzitelna) implementacia master-slave replikacie zalozena prave na WAL log shipping, kedy sa zmeny nestreamovali cez priame prepojenie serverov, ale vlastnou cestou - napr. cez rsync. Tento sposob je tiez uzko spojeny s PITR.

[Max]

Tak ono je jedno, zda se přenos transakčního logu řeší v rámci nějakého spojení mezi db, nebo tak, že se generuje file, který je nutné přenést. Princip to je stejný, jen první variantu člověk nemusí moc řešit.
Třeba Oracle generuje transakční soubory, ty rsyncem přenášíme do vzdálené lokality a zároveň se tam spouští pokyn k načtení transakčních logů. A tak stále dokola každých x min.
Jinak Oracle disponuje automatizovanými nástroji, ale ty jsou převážně jen pro enterprise edici, která je v jiném cenovém řádu.
Mno a pak je jedno, kolik replik člověk má, je to jen o tom, kam všude ty transakční logy bude kopírovat a výkon primárního serveru není nijak ovlivněn.
Další výhodou této replikace je i to, že je to záloha. Pokud si člověk dělá jeden dump db týdně + si nechává transakční soubory, tak se lze dostat do jakéhokoli času k datům (obnový se dump + dohrají transakční soubory k příslušnému datu/času).
Zdar Max

[EtDirloth]

Az po tomto ma napadlo, ze povodna otazka mohla byt o synchronizacii adresara celeho DB clusteru - a ze k tomu si sa asi povodne vyjadroval aj ty.

To by mohlo fungovat napr. pri SQLite.

V PgSQL by to vsak mohlo fungovat prave na urovni WAL file shipping cez dropbox. Tak, ze archive_command by kopiroval do adresara synchronizovaneho cez drop-box. A rovnakou cestou by sa mohol distribuovat base-backup pre potreby inicializacie replik(y).

[Kit]

SQLite na sdílených úložištích nefunguje jak má a je vcelku jedno, který použiješ protokol. SQLite musí být na stroji, kde sídlí i aplikace, která s touto databází pracuje.

PostgreSQL by na tom mohlo být podobně nebo ještě hůře. Kdekdo zapomíná na špinavé cache, kterých by tam byla hromada.

Raději bych synchronizoval hromadu drobných XML, to by se ještě přes Dropbox ukočírovat dalo. Databáze i s aplikací na cloudu však bude mnohem lepším řešením.

[jan.rok]

Děkuji za shrnutí.

[Kit]

Otázkou je: Proč chceš dvě databáze ve dvou lokalitách? Nestačila by jedna databáze někde na cloudu, ke které by mohly přistupovat aplikace z obou lokalit?

[jan.rok]

Asi by stačila. Spíš mě zajímalo, jak by se chovalo to řešení s Dropboxem. Nejde o nic konkrétního, jen o úvahu.

[Kit]

Obrovská režie při synchronizaci a databáze permanentně rozbitá. Stačí?

[cronin]

O zlepení synchronizácie databázy cez iné ako jej vlastné nástroje ani neuvažuj, leda že by si sa chcel niekomu pomstiť.

V prvom rade sa uisti, že rozumieš CAP teorému. A keď Ťa prejde frustrácia, realisticky zváž požiadavku na master-to-master replikáciu.

[EtDirloth]

Tomuto moc nerozumiem. IMHO zbytocne matuca reakcia - vobec neviem, ci je to len off-topic, alebo mi nieco uslo.

Ja pisem, ze v PgSQL si to musel a teraz mozes riesit vlastnymi prostriedkami. Max pise, ze s Oracle to musis robit do urcitej urovne licencie. Tazatel nespomina ani distribuovanu DB, ani master-master replikaciu. Jedine, co riesi, je redundancia dat, dokonca spomina, ze moze ist o master-slave - "aplikace nemusí nutně běžet najednou".

[Jendа]

Hrozí nebezpečí, že když bude aplikace pracovat s databází a zároveň ji bude synchronizovat přes Dropbox, že dojde k porušení dat?

Ano, extrémní. Většina těchto synchronizačních nástrojů funguje tak, že soubor otevře a pak ho lineárně čte a změny přenáší na druhou stranu. Pokud jsi uprostřed čtení a změní se něco na začátku i na konci souboru, přeneseš jenom tu změnu na konci souboru.

Teď si představ jednoduchý příklad, že databáze je obyčejný AVL strom (nejsme tak daleko od pravdy, například MySQL používá interně B-strom) a databáze zrovna zjistila, že je rozbalancovaný a je potřeba provést rotaci, což znamená přepsat pár pointrů na začátku a pár na konci. No a teď ti běží synchronizace dropboxem a pointry na začátku ukazují na původní umístění (které už třeba neexistuje nebo je tam něco úplně jiného) a pointry na konci na nové. Strom se tím totálně rozbil.