už OT: ponuka prace - školství v hajzlu
RV
vicek.radek na cpost.cz
Čtvrtek Únor 9 13:46:53 CET 2012
Tak jak jsem psal trivialni to neni a zalezi na tom co to je za data a
samozrejme musite mit chytre vymysleny datovy model. ;-)
Velmi casto se delaji zmeny do takovych systemu ne prepisem konkretniho
zaznamu, ale jen zapisem o provedeni zmeny. Ma to vyhodu v tom, ze ke
kazdemu insertu muzete zapsat uzivatele, kterej zmenu udelal a
samozrejme vidite i casovou osu. Pak to neni problem doreplikovat,
protoze tam jen priskacou zaznamy porizene k nejakemu datu a je jen na
vas ktery berete jako platny. Kdyz pak prave delate sjetinu nejakeho
stavu treba k roku 2010 tak pak vam vsechno zpetne hraje - protoze pak
se nemuze stat, ze vam vypadne z dat, ze dotycny uplatnoval v roce 2010
slevu na danich na manzelku a pritom momentalne je rozvedeny.
Jinak pokud se rozpadne replikacni system tak je to dost pruser -
protoze pri sebemensi nekonzistenci dat se replikacni system odstavi -
protoze je to asi nejlepsi mozna strategie a ceka se opravdu na zasah
nejakeho operatora, kterej provede materializace tabulek.
Nejvetsi nestesti je kdyz se delaji zmeny do datoveho modelu, ktery je
pod replikacemi - protoze v tu chvili je treba vetsinou zrusit referecni
integritu nad tabulkama a pokud nekde neco neprojde tak se to odstavi a
musite najit co se kde poondilo a rucne to opravit. A samozrejme v tu
chvili se plni na tech primarnich serverech transakcni logy, ktere nejde
vydumpovat - no proste veselo.
RV
Dne 9.2.2012 13:25, Jaroslav Buchta napsal(a):
> Jen technicka, se mi proste nasadil brouk do hlavy...
> Co kdyz v offline rezimu zmeni jeden zaznam na 2 mistech? To pak vyskoci
> pri replikaci jako chyba a musi se to resit rucne?
>
Další informace o konferenci Hw-list