Jo deltafeed mist lette commits: bou in betroubere cursor

Ien rige kaam let oan om't it wettermerk gjin commit-grins wie. Folgje de flater en definiearje dan dekking, grins, bewarjen en in feilige werynset.

Hjir is in flater dy't ik twa kear sjoen haw, yn twa ferskillende motoren. In eksport rint om 10:00 en registrearret it heechste tiidstimpel fan lêste wiziging dat it seach. Ien transaksje dy't om 09:58 begûn is noch iepen, commitet om 10:03 en draacht in tiidstimpel fan doe't it begûn. De folgjende eksport freget allinnich om rigen dy't nijer binne as 10:00 en sjocht it nea. De oerdrachtgrutte wie poerbêst en de gegevens wiene ferkeard.

Folgje de eksport dy't in rige ferlear

Folgje de folchoarder fan barrens, net de SQL. De applikaasje skriuwt de wizigingstiid fan 'e rige as de transaksje begjint, net as it commitet. De eksporteur lêst in muorreklok-wettermerk wylst dy transaksje noch iepen is. Dan commitet de transaksje mei in wizigingstiid dy't âlder is as it bewarre wettermerk. De folgjende batch fan 'e konsumint begjint nei it wettermerk, dus de rige bliuwt efter de cursor en sil nea wer keazen wurde.

Neat logt in flater, om't neat mislearre. Dat makket dizze klasse bug djoer: de deltafeed is fluch, de rigetallen lykje leaud, en de ûntbrekkende rige komt wiken letter op as in ôfstimmingskaartsje dat nimmen reprodusearje kin.

Folchnûmers hawwe deselde foarm fan mankement om in oare reden. In monotoan ID fertelt jo de folchoarder wêryn't wearden tawiisd waarden, net de folchoarder wêryn't transaksjes committen. In transaksje dy't in leech nûmer pakte kin committe nei ien dy't in heech nûmer pakte, dus in cursor basearre op tawiisingsfolchoarder kin ek in gat litte.

Fiif beloften dy't de feed dwaan moat

Foardat jo in transport kieze, freegje it boarnesysteem om in kontrakt mei fiif klausules. As ien klausule ûntbrekt, hawwe jo in heuristyk, net in feroaringsfeed.

  • Dekking: ynfoegingen, bywurkingen en fuortsmitingen, elk mei de stabile kaai dy't nedich is om it ta te passen.
  • Grins: wat in cursorwearde betsjut en wat in konsekwinte batch befettet.
  • Konsekwinsje: hoe't besibbe tabellen lêzen wurde sûnder ynkompatibele boarnetastannen te mingen.
  • Bewarjen: hoe lang in ôfsletten konsumint weromsette kin fan syn bewarre posysje.
  • Werinisjalisaasje: in stipe folsleine momentopname foar as dy posysje net mear jildich is.

In stipe meganisme kin alle fiif foldwaan. De dokumintaasje fan SQL Server oer feroaringsfolging is ien konkreet publisearre foarbyld: it definiearret in minimale jildige ferzje, registrearret fuortsmitingen likegoed as feroaringen en beskriuwt in momentopname-transaksje dy't falidaasje, ferzjefêstlizzing en de besibbe feroaringsquery's omfettet. It is in foarbyld fan wat jo fan in boarne freegje moatte, gjin syntaksis dy't jo yn in oare motor plakke kinne.

Untwerp it kontrôlepunt as part fan 'e pipeline

De bewarre posysje fan 'e konsumint is de echte tastânmasine, dus skriuw it as sadanich. De cursor mei allinnich foarút troch de wurkstream dy't de batch al tapast en de doeltransaksje commit hat.

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

As levering healwei mislearret, fermoedsoenje deselde batch ynstee fan in nije boarneposysje te betinken. Wer opnij ekstrahearje mei in friskere boppegrins is hoe't in partiele tapassing in permaninte leechte wurdt. De spegelregel jildt ek oan 'e oare kant: idempotinte tapassing by it doel foarkomt duplikaten en docht neat foar in feroaring dy't de ekstraksje nea seach.

Fuortsmitingen hawwe records nedich, net konklúzjes

It fergelykjen fan rigen dy't noch bestean kin in konsumint net fertelle hokker kaaien ferdwûn binne. In boarne dy't nea fuortsmitingen registrearret lit jo twa ûnfolsleine opsjes: in kaaihistoarje lang genôch byhâlde om tsjin te diffen, of in eksplisite folsleine fermoedsoening op skema útfiere. Beide binne ûntwerpkarren mei kosten, en gjinien bestiet as nimmen it besit.

Bewarjen is deselde soarte beslissing. Elke stipe feroaringsfeed hat in finster; neam it yn it kontrakt en warskôgje as it kontrôlepunt fan in konsumint der tichtby komt. In konsumint dy't wekker wurdt nei in ûnderbrekking fan twa wike moat in dúdlike flater "werinisjalisaasje nedich" lêze ynstee fan stil in partiele batch te ûntfangen.

Mjit dan oft de delta it wurdich wie

Weromfalle op it fergelykjen fan elke kaai en hash is soms goed, en it is de muoite wurdich te witten wat it kostet. Jo drage noch altyd ynformaasje oer elke rige oer, hashes jouwe jo gjin konsekwinte momentopname oer tabellen, en in hashskema bringt syn eigen fragen oer fertsjintwurdiging en botsingen. Minder bytes mei in kontrolearbere grins is it doel; minder bytes dy't stil in committe feroaring falle litte is hielendal gjin delta.

In kolom foar lêste wiziging is in oanwizing. In cursor dy't in lette commit, in fuortsmiting en in lange ûnderbrekking oerlibbet is in kontrakt.

Relatearre artikelen