Obnovitev nalaganja iz SQL Serverja v Oracle po izpadu VPN

Prenos med bazami podatkov umre, ko VPN pade, in „zaženi znova“ ni načrt obnovitve. Ekstrakcija iz vira je lahko končana, cilj je morda že commit-al, ali pa se je odgovor preprosto izgubil na poti nazaj. Ta tri stanja zahtevajo različne ukrepe, in odjemalec, ki pozna le „napako“, jih ne more ločiti.

Popravek je arhitekturni: vsaki izvedbi dajte trajno identiteto paketa in pustite bazam podatkov, da odgovarjajo na vprašanja, namesto da bi odjemalec ugibal.

Kaj baza podatkov v resnici zagotavlja

SQL Server in Oracle oba zagotavljata atomarnost znotraj transakcije. Nobeden ne zagotavlja atomarnosti med obema. Izgubljena povezava ne poškoduje baze podatkov in ne vsili ročnega razveljavljanja, ker strežnik sam reši svojo transakcijo brez vas. Kar se zlomi, je klicateljevo vedenje o izidu.

Ločeno commit-ano pomeni ločeno commit-ano. VPN, ki prenaša obe povezavi, ne zlije dveh commit-ov v eno delovno enoto.

Commit, o katerem niste nikoli slišali

En način napake kaznuje naivno logiko ponovnih poskusov: strežnik izvede commit, potrditev pa nikoli ne doseže klicatelja. Oracle to dokumentira kot problem neznanega izida in zanj ponuja Transaction Guard v dokumentaciji transakcij. Komunikacijska napaka ni dokaz, da poslani commit ni uspel, in obravnavati jo kot dokaz je pot, po kateri se paket objavi dvakrat. Razlika je najpomembnejša na poti ponovnega poskusa, kjer ima operater sporočilo o napaki in nobenega drugega signala za ukrepanje.

Zato mora korak obnovitve prebrati izid iz cilja, namesto da bi ga izpeljal iz besedila napake.

Prenosu dajte identiteto paketa

Vsaka izvedba dobi nespremenljiv ID paketa, cilj pa zabeleži, kaj je storil s tem ID-jem. Življenjski cikel ima štiri korake in je videti enako ne glede na ponudnika:

1. Izvlecite identificiran, nespremenljiv izvorni paket z zabeleženo shemo in mejo.
2. Prenesite ga v pripravljalno območje cilja in pred razglasitvijo za pripravljenega odkrijte nepopolno ali nasprotujočo vsebino.
3. Uporabite ga po lastnih pravilih edinstvenosti ali zaklepanja cilja in zabeležite dokončanje v isti lokalni transakciji.
4. Uskladite trajni izid prek podprtega protokola, preden potrdite ali poskusite znova.

Ponovni poskusi uporabijo isti ID. Nov ID za vsak poskus izniči preprečevanje dvojnikov, ki ste ga pravkar zgradili, kar se zdi očitno, dokler ovoj ponovnega poskusa ne ustvari enega samodejno.

ID vam da tudi nekaj, proti čemur lahko pozneje usklajujete, dolgo potem, ko je proces odjemalca izginil.

Zahtevajte paket, nato ga uporabite

Korak uporabe mora zahtevati ID paketa, izvesti poslovne spremembe in zabeležiti dokončanje v eni lokalni transakciji. Izvajanje preverjanja in vstavljanja kot ločenih stavkov ponovno uvede tekmo, ki ste jo poskušali odstraniti. Če dva delavca tekmujeta, zmaga natanko ena zahteva, drugemu pa se to sporoči.

Manjkajoč zapis o dokončanju ni dokaz, da transakcija v teku nikoli ne bo commit-ala. Zahteva mora serializirati konkurenčne poskuse, ali pa mora protokol prebrati trajni izid pred kakršno koli odločitvijo.

Za to serializacijo uporabite podprt mehanizem baze podatkov, namesto zanke preveri-in-ponovi v kodi aplikacije.

Česa zasnova še vedno ne more obljubiti

Priprava naredi delo znova zagnano in zmanjša odvisnost od ene dolge seje. Ne ustvari enega samega atomarnega commit-a čez SQL Server, Oracle in kateri koli zunanji stranski učinek, ki ga delo izvede. Če posel to res potrebuje, zasnujte in kvalificirajte podprto porazdeljeno transakcijo ali proces usklajevanja, vključno s tem, kdo ima delo z negotovim izidom. Karkoli šibkejše sodi v runbook za usklajevanje, ne v kodo prenosa.

Sprejmite prekinitev na treh mestih: med prenosom, med uporabo in po commit-u, a pred potrditvijo. Nato preverite poslovni rezultat, ne sporočila odjemalca, in pustite knjigi paketov, da pove, ali je delo nepopolno, commit-ano ali še vedno nerešeno.