Jou deltastroom mis laat commit: bou 'n betroubare wyser

'n Ry het laat deurgekom omdat die watermerk nie 'n commit-grens was nie. Volg die fout en definieer dan dekking, grens, bewaring en 'n veilige hervatting.

Hier is 'n fout wat ek twee keer sien gebeur het, in twee verskillende enjins. 'n Uitskakeling loop om 10:00 en teken die hoogste laas-gewysigde tydstempel op wat dit sien. Een transaksie wat om 09:58 begin het, is nog oop, commit om 10:03 en dra 'n tydstempel van toe dit begin het. Die volgende uitskakeling vra net vir rye nuwer as 10:00 en sien dit nooit. Die oordraggrootte was uitstekend en die data was verkeerd.

Volg die uitskakeling wat 'n ry verloor het

Volg die volgorde van gebeure eerder as die SQL. Die toepassing skryf die ry se wysigingstyd wanneer die transaksie begin, nie wanneer dit commit nie. Die uitvoerder lees 'n muurklok-watermerk terwyl daardie transaksie nog oop is. Die transaksie commit dan met 'n wysigingstyd ouer as die gestoorde watermerk. Die verbruiker se volgende bondel begin ná die watermerk, so die ry is agter die wyser en sal nooit weer gekies word nie.

Niks teken 'n fout aan nie, want niks het gefaal nie. Dit is wat hierdie klas fout duur maak: die deltastroom is vinnig, die rytellings lyk geloofwaardig, en die ontbrekende ry duik weke later op as 'n rekonsiliasiekaartjie wat niemand kan reproduseer nie.

Volgnommers het dieselfde tipe fout om 'n ander rede. 'n Monotone ID vertel jou die volgorde waarin waardes toegeken is, nie die volgorde waarin transaksies commit het nie. 'n Transaksie wat 'n lae nommer gegryp het, kan ná een commit wat 'n hoë nommer gegryp het, so 'n wyser gebaseer op toekenningsorde kan ook 'n gat laat.

Vyf beloftes wat die stroom moet nakom

Voordat jy 'n transport kies, vra die bronsisteem om 'n kontrak met vyf klousules. As enige klousule ontbreek, het jy 'n heuristiek eerder as 'n veranderingsstroom.

  • Dekking: invoegings, opdaterings en skrappings, elk met die stabiele sleutel wat nodig is om dit toe te pas.
  • Grens: wat 'n wyserwaarde beteken en wat 'n konsekwente bondel bevat.
  • Konsekwentheid: hoe verwante tabelle gelees word sonder om onversoenbare brontoestande te meng.
  • Bewaring: hoe lank 'n ontkoppelde verbruiker van sy gestoorde posisie kan hervat.
  • Herinitialisering: 'n ondersteunde volledige snapfoto vir wanneer daardie posisie nie meer geldig is nie.

'n Ondersteunde meganisme kan al vyf nakom. SQL Server se dokumentasie oor veranderingsnasporing is een konkrete gepubliseerde voorbeeld: dit definieer 'n minimum geldige weergawe, teken skrappings sowel as veranderinge aan, en beskryf 'n snapfoto-transaksie wat validasie, weergawevaslegging en die verwante veranderingsnavrae oorspan. Dit is 'n voorbeeld van wat om van 'n bron te eis, nie sintaksis wat jy in 'n ander enjin kan plak nie.

Ontwerp die kontrolepunt as deel van die pyplyn

Die verbruiker se gestoorde posisie is die werklike toestandmasjien, so skryf dit as een neer. Die wyser mag net vorder deur die werkvloei wat die bondel reeds toegepas en die teikentransaksie commit het.

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 aflewering halfpad faal, versoen dieselfde bondel eerder as om 'n nuwe bronposisie te bedink. Om weer met 'n vars boonste grens te onttrek, is hoe 'n gedeeltelike toepassing 'n permanente gaping word. Die spieëlreël geld ook aan die ander kant: idempotente toepassing by die teiken voorkom duplikate en doen niks vir 'n verandering wat die onttrekking nooit gesien het nie.

Skrappings het rekords nodig, nie gevolgtrekkings nie

Om rye te vergelyk wat nog bestaan, kan 'n verbruiker nie sê watter sleutels verdwyn het nie. 'n Bron wat nooit skrappings aanteken nie, laat jou met twee onvolmaakte opsies: hou 'n sleutelgeskiedenis lank genoeg om teen te diff, of voer 'n eksplisiete volle rekonsiliasie volgens 'n skedule uit. Albei is ontwerpkeuses met 'n koste, en nie een bestaan tensy iemand dit besit nie.

Bewaring is dieselfde soort besluit. Elke ondersteunde veranderingsstroom het 'n venster; stel dit in die kontrak en waarsku wanneer 'n verbruiker se kontrolepunt dit nader. 'n Verbruiker wat ná 'n onderbreking van twee weke wakker word, behoort 'n duidelike fout "herinitialisering nodig" te lees eerder as om stil 'n gedeeltelike bondel te ontvang.

Meet dan of die delta die moeite werd was

Om terug te val op die vergelyking van elke sleutel en hash is soms reg, en dit is die moeite werd om te weet wat dit kos. Jy dra steeds inligting oor elke ry oor, hashes gee jou nie 'n konsekwente kruistabel-snapfoto nie, en 'n hashskema bring sy eie vrae oor voorstelling en botsings. Minder grepe met 'n verifieerbare grens is die doel; minder grepe wat stil 'n gecommitte verandering laat val, is glad nie 'n delta nie.

'n Laas-gewysigde kolom is 'n wenk. 'n Wyser wat 'n laat commit, 'n skrapping en 'n lang onderbreking oorleef, is 'n kontrak.

Verwante artikels