Zure delta jarioak beranduko commitak galtzen ditu: eraiki kurtsore fidagarria

Errenkada bat berandu iritsi zen watermark-a ez zelako commit muga. Jarraitu hutsegitea, eta gero definitu estaldura, muga, atxikipena eta berrekite segurua.

Hona hemen bi aldiz ikusi dudan hutsegite bat, bi motor ezberdinetan. Esportazio bat 10:00etan exekutatzen da eta ikusi duen azken aldaketaren denbora-zigilu altuena erregistratzen du. 09:58an hasi zen transakzio bat oraindik irekita dago, 10:03an commit egiten du eta hasi zen uneko denbora-zigilua darama. Hurrengo esportazioak 10:00ak baino berriagoak diren errenkadak baino ez ditu eskatzen eta ez du inoiz ikusten. Transferentziaren tamaina bikaina zen eta datuak okerrak.

Jarraitu errenkada bat galdu zuen esportazioari

Jarraitu gertaeren ordenari, SQLari baino. Aplikazioak errenkadaren aldaketa-denbora transakzioa hasten denean idazten du, ez commit egiten duenean. Esportatzaileak horma-erloju watermark bat irakurtzen du transakzio hori oraindik irekita dagoen bitartean. Gero transakzioak commit egiten du gordetako watermark-a baino zaharragoa den aldaketa-denborarekin. Kontsumitzailearen hurrengo sortak watermark-aren ondoren hasten da, beraz errenkada kurtsorearen atzean geratzen da eta ez da inoiz berriro hautatuko.

Ezerk ez du errorerik erregistratzen, ezerk huts egin ez duelako. Hori da akats-mota hau garestia egiten duena: delta jarioa azkarra da, errenkada-kontuak sinesgarriak dirudite, eta falta den errenkada aste batzuk geroago agertzen da inork erreproduzitu ezin duen adiskidetze-txartel gisa.

Segida-zenbakiek akats formaren berbera dute beste arrazoi batengatik. ID monotonikoak balioak esleitu ziren ordena esaten dizu, ez transakzioak commit egin zuten ordena. Zenbaki baxua hartu zuen transakzio bat zenbaki altua hartu zuenaren ondoren commit egin daiteke, beraz esleitzeko ordenan oinarritutako kurtsoreak ere hutsune bat utz dezake.

Jarioak eman behar dituen bost promes

Garraioa aukeratu aurretik, eskatu iturburu-sistemari bost klausulako kontratua. Klausula bat falta bada, heuristika bat duzu, ez aldaketen jario bat.

  • Estaldura: txertaketak, eguneratzeak eta ezabaketak, bakoitza aplikatzeko behar den gako egonkorrarekin.
  • Muga: zer esan nahi duen kurtsore-balio batek eta zer duen sorta koherente batek.
  • Koherentzia: nola irakurtzen diren erlazionatutako taulak iturburu-egoera bateraezinak nahastu gabe.
  • Atxikipena: zenbat denbora dezakeen deskonektatutako kontsumitzaile batek bere gordetako posiziotik berrekin.
  • Berrabiaraztea: onartutako snapshot oso bat posizio hori jada baliozkoa ez denean.

Onartutako mekanismo batek bostak bete ditzake. SQL Serverren aldaketen jarraipenari buruzko dokumentazioa argitaratutako adibide zehatz bat da: gutxieneko bertsio baliozkoa definitzen du, ezabaketak eta aldaketak erregistratzen ditu, eta baliozkotzea, bertsioaren harrapaketa eta erlazionatutako aldaketa-kontsultak hartzen dituen snapshot transakzio bat deskribatzen du. Iturburu bati zer eskatu behar zaion adibidea da, ez beste motor batean itsats dezakezun sintaxia.

Diseinatu kontrol-puntua pipelinearen parte gisa

Kontsumitzailearen gordetako posizioa benetako egoera-makina da, beraz idatzi horrela. Kurtsoreak aurrera egin dezake jada sorta aplikatu eta helburuko transakzioa commit egin duen workflowaren bidez soilik.

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

Entrega erdibidean huts egiten badu, adiskidetu sorta bera iturburu-posizio berria asmatu beharrean. Goiko muga freskoago batekin berriro erauztea da aplikazio partziala hutsune iraunkor bihurtzeko bidea. Ispilu-arauak beste aldean ere balio du: helburuan aplikazio idempotenteak bikoiztuak saihesten ditu eta erauzketak inoiz ikusi ez zuen aldaketa baterako ezer ez du egiten.

Ezabaketek erregistroak behar dituzte, ez ondorioak

Oraindik existitzen diren errenkadak alderatzeak ezin dio kontsumitzaileari esan zein gako desagertu ziren. Ezabaketak inoiz erregistratzen ez dituen iturburu batek bi aukera inperfektu uzten dizkizu: gako-historia nahikoa luze mantentzea diff egiteko, edo adiskidetze oso esplizitua egutegi baten arabera exekutatzea. Biak dira kostua duten diseinu-erabakiak, eta bat ere ez da existitzen inork bere gain hartu ezean.

Atxikipena erabaki mota bera da. Onartutako aldaketa-jario bakoitzak leiho bat du; adierazi kontratuan eta abisatu kontsumitzaile baten kontrol-puntua hurbiltzen denean. Bi astez eten ondoren esnatzen den kontsumitzaileak "berrabiaraztea beharrezkoa" errore argia irakurri beharko luke, isilpean sorta partzial bat jaso beharrean.

Gero neurtu delta merezi izan zuen

Gako eta hash bakoitza alderatzera itzultzea batzuetan zuzena da, eta merezi du kostua zenbat den jakitea. Errenkada bakoitzaren informazioa transferitzen jarraitzen duzu, hashek ez dizute taulen arteko snapshot koherenterik ematen, eta hash-eskema batek bere galderak dakartza irudikapenari eta talkei buruz. Byte gutxiago muga egiaztagarri batekin da helburua; isilpean commit egindako aldaketa bat botatzen duten byte gutxiago ez da delta bat ere.

Azken aldaketaren zutabea arrasto bat da. Beranduko commit bat, ezabaketa bat eta eten luze bat gainditzen dituen kurtsorea kontratu bat da.

Erlazionatutako artikuluak