Vaš delta tok izgublja pozne commite: zgradite zanesljiv kazalec

Ena vrstica je prišla pozno, ker vodni znak ni bil meja commita. Prehodite napako in nato določite pokritost, mejo, hrambo in varno nadaljevanje.

Tukaj je napaka, ki sem jo videl dvakrat, v dveh različnih pogonih. Izvoz se izvede ob 10:00 in zabeleži najvišjo videno časovno oznako zadnje spremembe. Ena transakcija, ki se je začela ob 09:58, je še vedno odprta, naredi commit ob 10:03 in nosi časovno oznako iz trenutka, ko se je začela. Naslednji izvoz zahteva le vrstice, novejše od 10:00, in je nikoli ne vidi. Velikost prenosa je bila odlična, podatki pa napačni.

Prehodite izvoz, ki je izgubil vrstico

Sledite vrstnemu redu dogodkov, ne SQL. Aplikacija zapiše čas spremembe vrstice ob začetku transakcije, ne ob commitu. Izvoznik bere vodni znak po stenski uri, medtem ko je transakcija še odprta. Nato transakcija naredi commit s časom spremembe, starejšim od shranjene vodne oznake. Naslednja serija potrošnika se začne po vodni oznaki, zato vrstica ostane za kazalcem in ne bo nikoli več izbrana.

Nič ne zabeleži napake, ker ni nič spodletelo. To dela to vrsto napak drago: delta tok je hiter, število vrstic je videti verjetno, manjkajoča vrstica pa se pojavi tedne pozneje kot zahtevek za uskladitev, ki ga nihče ne more ponoviti.

Zaporedne številke imajo enako obliko pomanjkljivosti iz drugega razloga. Monotoni ID vam pove vrstni red dodelitve vrednosti, ne vrstnega reda commitov transakcij. Transakcija, ki je vzela nizko številko, lahko naredi commit po tisti, ki je vzela visoko, zato lahko tudi kazalec, ki temelji na vrstnem redu dodelitve, pusti luknjo.

Pet obljub, ki jih mora tok izpolniti

Preden izberete prenos, od izvornega sistema zahtevajte pogodbo s petimi klavzulami. Če katera manjka, imate heuristiko in ne tok sprememb.

  • Pokritost: vstavljanja, posodobitve in brisanja, vsako s stabilnim ključem, potrebnim za uporabo.
  • Meja: kaj pomeni vrednost kazalca in kaj vsebuje dosledna serija.
  • Doslednost: kako se berejo povezane tabele brez mešanja nezdružljivih stanj vira.
  • Hramba: kako dolgo lahko odklopljen potrošnik nadaljuje s svojega shranjenega položaja.
  • Ponovna inicializacija: podprt popoln posnetek, ko ta položaj ni več veljaven.

Podprt mehanizem lahko izpolni vseh pet. Dokumentacija SQL Serverja o sledenju spremembam je en konkreten objavljen primer: določa najmanjšo veljavno različico, beleži brisanja kot tudi spremembe in opisuje transakcijo posnetka, ki zajema preverjanje, zajem različice in povezane poizvedbe sprememb. To je primer, kaj zahtevati od vira, ne sintaksa, ki jo prilepite v drug pogon.

Zasnujte kontrolno točko kot del pipeline-a

Shranjeni položaj potrošnika je pravi stroj stanj, zato ga tako tudi zapišite. Kazalec lahko napreduje le skozi delovni tok, ki je serijo že uporabil in naredil commit ciljne transakcije.

cursor  = durable_checkpoint()          # last fully applied position
batch   = extract(cursor, upper_bound)  # one consistent batch
apply(batch)                            # idempotent at the target
commit()
checkpoint(batch.upper_bound)           # only now

Če dostava spodleti na pol poti, uskladite isto serijo, namesto da bi si izmislili nov položaj vira. Ponovno pridobivanje s novejšo zgornjo mejo je pot, po kateri delna uporaba postane trajna vrzel. Zrcalno pravilo velja tudi na drugi strani: idempotentna uporaba na cilju preprečuje dvojnike in ne naredi ničesar za spremembo, ki je pridobivanje ni nikoli videlo.

Brisanja potrebujejo zapise, ne sklepov

Primerjanje vrstic, ki še obstajajo, potrošniku ne more povedati, kateri ključi so izginili. Vir, ki nikoli ne beleži brisanj, vam pusti dve nepopolni možnosti: hraniti zgodovino ključev dovolj dolgo za diff ali izvajati izrecno popolno uskladitev po urniku. Obe sta oblikovalski odločitvi s ceno in nobena ne obstaja, dokler je nihče ne lasti.

Hramba je ista vrsta odločitve. Vsak podprt tok sprememb ima okno; navedite ga v pogodbi in opozorite, ko se kontrolna točka potrošnika približa. Potrošnik, ki se zbudi po dvotedenskem prekinitvi, bi moral prebrati jasno napako »potrebna je ponovna inicializacija«, namesto da tiho prejme delno serijo.

Nato izmerite, ali se je delta izplačala

Vrnitev k primerjanju vsakega ključa in zgoščene vrednosti je včasih pravilna in vredno je vedeti, koliko stane. Še vedno prenašate informacije o vsaki vrstici, zgoščene vrednosti vam ne dajo doslednega posnetka med tabelami, zgoščevalna shema pa prinaša lastna vprašanja o predstavitvi in trkih. Manj bajtov s preverljivo mejo je cilj; manj bajtov, ki tiho spustijo commitano spremembo, ni nobena delta.

Stolpec zadnje spremembe je namig. Kazalec, ki preživi pozen commit, brisanje in dolgo prekinitev, je pogodba.

Sorodni članki