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, .... .
13 Odpovědí
1891 Zhlédnutí