Ahojte,
existuje nějaké standardizované řešení níže popsaného systému, nebo jak by jste to řešili Vy?
Mám webové aplikace v centrále firmy a data čtou a plní i na vzdálených pobočkách, v případě výpadku mezi firmami bych potřeboval nějak jednoduše přejít na ostrovní provoz. V každé lokalitě jsou serverovny, a tak není problém mít všude webservery a online replikované databáze (kvůli číselníkům a stavu před výpadkem).
Po detekci výpadku by na prohlížení šlo použít replikovanou databázi ale už ne na další práci s ní (po obnově spojení by došlo ke kolizím v generovaných ID).
Napadá mě možnost druhé databáze na ostrovní pobočce kde by se po výpadku vytvořila kopie té replikované, začaly by se někam souběžně se zápisem do této DB ukládat i změnové SQL (něco jako transakční log) a aplikace by nadále fungovala.
Po znovu spojení s centrálou by se pak nejdříve vyřídili tyto pseudo transakční logy a pak se aplikace opět přepla na DB z centrály.
Díky za komentáře.
A jak zesynchronizujete tyto pseudotransakcni logy mezi jednotlivymi ostrovy, pokud budou sahat na shodna data? Ktera transakce ma prednost?
Nedokazu najit smysl v tom dotazu. Jestli jsem dobre pochopil, ma jit o obousmerny provoz R+W a do toho chcete zamontovat ostrovni system?
Citace od: MP kdy 08. 11. 2017, 10:54:36
A jak zesynchronizujete tyto pseudotransakcni logy mezi jednotlivymi ostrovy, pokud budou sahat na shodna data? Ktera transakce ma prednost?
je to spíše o centralizaci dat, data z poboček se vzájemně neovlivňují
není problém z centrály detekovat spojení na pobočku a případně hlásit že aktuální data z dané pobočky momentálně nejsou a kdy začal výpadek
číselníky se nemění nějak dramaticky a vycházejí z centrály
na pobočce by musela být možnost v případě nutnosti položku do nějakého číselníku přidat nouzovým způsobem (třeba poslání QR kódu z centrály v MMS), ale to by se vidělo až časem co bude potřeba...
To by asi chcelo distribuovanu DB na styl Hadoopu. Pobocky budu si budu ukladat data na lokalne hadoop nody a ked to bude potrebne, tak sa iba urobi distribuovany agregovany vypocet nad vsetkymi datami/nodami. Zial myslim, ze na takyto styl prace je akakolvek relacna DB nevhodna - problem rozdeleneho mozgu (split brain). Videl som nejake riesenie nad PostgreSQL, ktore tvrdilo ze zvladne aj RW master/master replikaciu v pripade vypadku spojenia, ale stale som voci takymto rieseniam skepticky.
Citace od: DFly kdy 08. 11. 2017, 10:33:49
Po detekci výpadku by na prohlížení šlo použít replikovanou databázi ale už ne na další práci s ní (po obnově spojení by došlo ke kolizím v generovaných ID).
Nemůžeš se kolizím ID vyhnout použitím UUID?
Co tohle: http://guide.couchdb.org/draft/conflicts.html
Citace od: DFly kdy 08. 11. 2017, 10:33:49
Ahojte,
existuje nějaké standardizované řešení níže popsaného systému, nebo jak by jste to řešili Vy?
Mám webové aplikace v centrále firmy a data čtou a plní i na vzdálených pobočkách, v případě výpadku mezi firmami bych potřeboval nějak jednoduše přejít na ostrovní provoz. V každé lokalitě jsou serverovny, a tak není problém mít všude webservery a online replikované databáze (kvůli číselníkům a stavu před výpadkem).
Po detekci výpadku by na prohlížení šlo použít replikovanou databázi ale už ne na další práci s ní (po obnově spojení by došlo ke kolizím v generovaných ID).
Napadá mě možnost druhé databáze na ostrovní pobočce kde by se po výpadku vytvořila kopie té replikované, začaly by se někam souběžně se zápisem do této DB ukládat i změnové SQL (něco jako transakční log) a aplikace by nadále fungovala.
Po znovu spojení s centrálou by se pak nejdříve vyřídili tyto pseudo transakční logy a pak se aplikace opět přepla na DB z centrály.
Díky za komentáře.
Vytvořil bych nějaké vyšší/aplikační transakce/operace, ty by měli být takové aby je uživatel chápal a zároveň by byli z pohledu aplikační logiky atomické.
Každá by měla stav, plánovaná/vykonaná/v kolizi.
pokud jsou systémy rozpojené, tak by uživatelé mohli prohlížet stará data, a lokálně vytvářet nové operace ale jen ve stavu plánovaném.
když se systémy propojí, tak se jednotlivé operace automaticky vykonají na odou systémech v distribuované transakci a přitom přejdou do stavu, vykonaná nebo v kolizi.
jde jen o to, zvolit takovou velikost té jedne operace, aby to bylo pro uživatele uchopitelné, asi by to neměly být jednotlivé sql-příkazy ale vyšší operace, třeba vytvoř objednávku, .... .
Su rozne riesenia, zavisi aj od navrhu. Napr bankomaty ti umoznuju ist do debetu, takze nemusia byt online. Na urovni db mozes pouzit nejake riesenie typu https://www.symmetricds.org/ (to som teraz nasiel, nic o tom neviem). Problem su konflikty a ich uzivatelsky privetive riesenie. Napr eclipse emf ma na to merge dialog - ak 2 ludia zmenia to iste, tak musis rucne zmergovat entity (vyzera to ako merge kodu).
V podstatě se jedná o asynchronní transakce (ZCELA nepodstatné, zda s webem, RDB či něčím jiným, jedná se o obecný problém) - každý z ostrovních systémů musí mít svoji frontu transakcí, kterou se po úspěšném připojení POKUSÍ nahrnout do centrálního systému, kdy se v případě konfliktu (detekováno např. verzováním záznamů při jednoznačně definovaných identifikacích entit) musí nějak zařídit (zahodit vše od konfliktní transakce, nebo vytvořit nové transakce ze starých, ...). V případě požadavku na centralizovaný systém s nestálým spojením částí to jinak nejde.
Částečně s tím souvisejí tato témata:
Compensating transaction (https://en.wikipedia.org/wiki/Compensating_transaction)
Long-running transaction (https://en.wikipedia.org/wiki/Long-running_transaction)
Optimistic concurrency control (https://en.wikipedia.org/wiki/Optimistic_concurrency_control)
Long-lived transaction (https://en.wikipedia.org/wiki/Long-lived_transaction)
Tohle je algoritmicky dost slozity problem a ani takove rozsahle a slozite systemy jako je SAP R/3 to neumi. Kdyz nemas konektivitu tak nemuzes pracovat.
A jeje, nastupujou teoretici... Chce se mi plakat pokazde, kdyz mi v systemu dodanem podobnymi optimisty pretece fronta pozadavku... Panove, toto smysluplne reseni nejspis nema, a zadalate tazateli na potize...
Díky pánové,
tak nějak rámcově vidím že jednoznačné řešení není, pokusím se to udělat tak aby to obsáhlo co nejvíce variant které mohou nastat.
Ještě pročtu ty odkazy. A dyštak dám vědět jak to dopadlo