Atkurti kėlimą iš SQL Server į Oracle po VPN nutrūkimo

Tarpduomenų bazinis perkėlimas miršta, kai VPN nutrūksta, o „paleisk dar kartą“ nėra atkūrimo planas. Šaltinio ištraukimas gali būti baigtas, tikslas jau gali būti atlikęs commit, arba atsakymas tiesiog dingo kelyje atgal. Šios trys būsenos reikalauja skirtingų veiksmų, o klientas, žinantis tik „klaida“, negali jų atskirti.

Sprendimas architektūrinis: suteikite kiekvienam vykdymui ilgaamžę paketo tapatybę ir leiskite duomenų bazėms atsakyti į klausimus, o ne leisti klientui spėlioti.

Ką duomenų bazė iš tikrųjų garantuoja

SQL Server ir Oracle abi suteikia atominį vientisumą transakcijos viduje. Nė viena nesuteikia atominio vientisumo tarp jųdviejų. Prarastas ryšys nesugadina duomenų bazės ir neverčia rankiniu būdu atšaukti, nes serveris pats išsprendžia savo transakciją be jūsų. Lūžta tai, ką iškvietėjas žino apie rezultatą.

Atskirai commitinta reiškia atskirai commitinta. VPN, pernešantis abu ryšius, nesulieja dviejų commit į vieną darbo vienetą.

Commit, apie kurį niekada negirdėjote

Vienas gedimo režimas baudžia naivią kartojimo logiką: serveris atlieka commit, o patvirtinimas niekada nepasiekia iškvietėjo. Oracle dokumentuoja tai kaip nežinomo rezultato problemą ir jai teikia Transaction Guard transakcijų dokumentacijoje. Ryšio klaida nėra įrodymas, kad išsiųstas commit nepavyko, o elgtis su ja kaip su įrodymu yra būdas, kuriuo paketas paskelbiamas du kartus. Šis skirtumas svarbiausias kartojimo kelyje, kur operatorius turi klaidos pranešimą ir jokio kito signalo veikti.

Todėl atkūrimo žingsnis turi perskaityti rezultatą iš tikslo, o ne jį išvesti iš klaidos teksto.

Suteikite perkėlimui paketo tapatybę

Kiekvienas vykdymas gauna nekintamą paketo ID, o tikslas įrašo, ką jis padarė su tuo ID. Gyvavimo ciklas yra keturi žingsniai, ir jis atrodo vienodai nepriklausomai nuo tiekėjo:

1. Ištraukite identifikuotą, nekintamą šaltinio paketą su įrašyta schema ir riba.
2. Perkelkite jį į tikslo paruošimo sritį ir aptikite neišsamią ar prieštaringą turinį prieš paskelbdami jį paruoštu.
3. Taikykite jį pagal tikslo pačio unikalumo ar blokavimo taisykles ir įrašykite užbaigimą toje pačioje vietinėje transakcijoje.
4. Suderinkite ilgaamžį rezultatą per palaikomą protokolą prieš patvirtindami ar bandydami dar kartą.

Kartojimai naudoja tą patį ID. Naujas ID kiekvienam bandymui sugriauna ką tik sukurtą dublikatų prevenciją, kas atrodo savaime suprantama, kol kartojimo apvalkalas automatiškai nesukuria vieno.

ID taip pat duoda jums kažką, su kuo vėliau suderinti, ilgai po to, kai kliento procesas išnyksta.

Reikalaukite paketo, tada taikykite

Taikymo žingsnis turi pareikalauti paketo ID, atlikti verslo pakeitimus ir įrašyti užbaigimą vienoje vietinėje transakcijoje. Patikros ir įterpimo atlikimas atskirais sakiniais grąžina lenktynes, kurias bandėte pašalinti. Jei du darbuotojai lenktyniauja, laimi lygiai vienas reikalavimas, o kitam apie tai pranešama.

Trūkstamas užbaigimo įrašas nėra įrodymas, kad vykstanti transakcija niekada neatliks commit. Reikalavimas turi serializuoti konkuruojančius bandymus, arba protokolas turi perskaityti ilgaamžį rezultatą prieš bet kokį sprendimą.

Tai serializacijai naudokite palaikomą duomenų bazės mechanizmą, o ne tikrink-ir-kartok ciklą programos kode.

Ko dizainas vis dar negali pažadėti

Paruošimas daro darbą paleidžiamą iš naujo ir sumažina priklausomybę nuo vienos ilgos sesijos. Jis nesukuria vieno atominio commit per SQL Server, Oracle ir bet kokį išorinį šalutinį poveikį, kurį darbas atlieka. Jei verslui to tikrai reikia, suprojektuokite ir kvalifikuokite palaikomą paskirstytą transakciją arba suderinimo procesą, įskaitant tai, kam priklauso neaiškaus rezultato darbas. Viskas silpnesnio už tai priklauso suderinimo vadovui, o ne perkėlimo kodui.

Priimkite pertraukimą trijose vietose: perkėlimo metu, taikymo metu ir po commit, bet prieš patvirtinimą. Tada patikrinkite verslo rezultatą, o ne kliento pranešimą, ir leiskite paketų knygai pasakyti, ar darbas nebaigtas, commitintas, ar dar neišspręstas.