Diky za hodnotou inspiraci, tohle je presne co jsem potreboval v teto chvili, aby me to dalo hlavu a patu!
Fakt jsem uvazoval o API/RPC, bez primeho pristupu vyssich aplikaci do DB, ale nevedel jsem jak/k cemu to vyuzit presne, ted chapu ze to budou proste ostruvky a musim pridat dependencies, at te ktere komponente neodriznu vetev ktera ji drzi. Tohle pujde hezky i reportovat a hlidat pri vyvoji a migracich. S rozdrobenim nemam problem, uz nyni je to hodne KISS metoda tady - individualni jednoucelove nastroje/skripty.
Priklad. Soudruzi kdysi davno vytvorili policko DIC a pridali ho k zaznamu organizace. Jenze pak se zjistilo, ze jedna oganizace muze mit ruzna DIC v ruznych casovych obdobich ... a tak pridali vazbu.
Tohle jsem resil ja asi lepe - uz od pocatku jsem to musel brat ze DIC ma platnost od-do, a taky ze existuje vice DIC k jednomu subjektu (klidne v kazdem eu state jedna) a na konkretnim dokladu se nachazi jedno z nich. Pak vznikla "sluzba" (spis volani/metoda), na zjistovani DIC k subjektu X, s kontextem - povinnym parametrem data, ke kteremu se dotaz vaze (vzdy tam muzete poslat dnesek, jestli jde o obecny dotaz). Podobne kontextualni queries mam napr. na dotaz na smenarensky kurz - vaze se ke dni, nebo mesici.
Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage).
Budu zcela kategoricky nesouhlasit. Replikace ti vůbec neřeší ransomwarový útok, protože napadená data se ti okamžitě replikují do sekundáru, protože samotným smyslem a účelem sekundární repliky je v reálném čase reflektovat změny v primární replice.
Replika NENÍ záloha, replika je opatření pro zajišětění vysoké dostupnosti při TECHNICKÉ ZÁVADĚ.
Tak zas asi zalezi jak ty repliky delate. Pokud je bude delat backend vrstva nad tupejsi databazi (mysql), mimo jine z duvodu, aby se resila mj i moznost behu v rozpojene/degradovane siti (pro ty mene kriticka volani, ktere to snesou, viz napr. vytvoreni objednavky v degradovanem rezimu, potvrzeni objednavky pouze v plne synchronnim, at se nemusi resit dvoji prodej polozek ze skladu a pak omlouvani se), tak je mala sance, ze by utocnik ktery ovlada jen stroje s vyssi logikou, dokazal znicit data na backendu na ktery muze sahat jen skrze API pod RPC. Takoveho pocinu by si hned mela vsimnout logika ktera bude hlidat typicke vyuzivani sluzeb, resp. melo by byt mozne revertnout dane zasahy pokud to jadro bude append-only.
Poslední příspěvky
.
.