Taasta SQL Serverist Oracle'isse laadimine pärast VPN-i katkemist

Andmebaasidevaheline ülekanne sureb, kui VPN katkeb, ja „käivita uuesti“ ei ole taastamisplaan. Allika ekstraktimine võib olla lõpetatud, sihtkoht võib olla juba commiti teinud või vastus võib lihtsalt tagasiteel kaduda. Need kolm olekut nõuavad erinevaid tegevusi ja klient, kes teab ainult „viga“, ei suuda neid eristada.

Lahendus on arhitektuurne: anna igale käivitusele kestev partii-identiteet ja lase andmebaasidel küsimustele vastata, selle asemel et klient oletaks.

Mida andmebaas tegelikult tagab

SQL Server ja Oracle annavad mõlemad atomaarsuse tehingu sees. Kumbki ei anna sulle atomaarsust nende kahe vahel. Kadunud ühendus ei riku andmebaasi ega sunni käsitsi tagasipööramist, sest server lahendab oma tehingu ilma sinuta. See, mis katkeb, on kutsuja teadmine tulemusest.

Eraldi committimine tähendab eraldi committimist. VPN, mis kannab mõlemat ühendust, ei ühenda kahte commiti üheks tööühikuks.

Commit, millest sa kunagi ei kuulnud

Üks tõrerežiim karistab naiivset korduskatse loogikat: server commitib ja kinnitus ei jõua kunagi kutsujani. Oracle dokumenteerib selle tundmatu tulemuse probleemina ja pakub selle jaoks Transaction Guardi tehingute dokumentatsioonis. Sideviga ei ole tõestus, et saadetud commit ebaõnnestus, ja selle käsitlemine tõestusena on viis, kuidas partii kaks korda postitatakse. See erinevus loeb kõige rohkem korduskatse teel, kus operaatoril on veateade ja mitte ühtegi muud signaali, mille järgi tegutseda.

Seega peab taastamissamm lugema tulemuse sihtkohast, selle asemel et see veatekstist tuletada.

Anna ülekandele partii-identiteet

Iga käivitus saab muutumatu partii-ID ja sihtkoht registreerib, mida ta selle ID-ga tegi. Elutsükkel on neli sammu ja see näeb välja ühesugune sõltumata tarnijast:

1. Ekstrakti tuvastatud, muutumatu allika partii koos registreeritud skeemi ja piiriga.
2. Kanna see sihtkoha ettevalmistusalaale ja tuvasta puudulik või vastuoluline sisu enne selle valmis kuulutamist.
3. Rakenda seda sihtkoha enda unikaalsus- või lukustusreeglite järgi ja registreeri lõpetamine samas kohalikus tehingus.
4. Võrdle kestev tulemus toetatud protokolli kaudu enne kinnitamist või uuesti proovimist.

Korduskatsed kasutavad sama ID-d. Uus ID iga katse jaoks õõnestab duplikaatide ennetamist, mille sa just ehitasid, mis kõlab ilmselgena, kuni korduskatse ümbris genereerib ühe automaatselt.

ID annab sulle ka midagi, mille vastu hiljem võrrelda, kaua pärast seda, kui kliendiprotsess on kadunud.

Nõua partii endale ja seejärel rakenda

Rakendamissamm peab partii-ID endale nõudma, ärimuudatused tegema ja lõpetamise ühes kohalikus tehingus registreerima. Kontrolli ja sisestuse eraldi lausetena tegemine toob tagasi võidujooksu, mida sa püüdsid kõrvaldada. Kui kaks töötajat võistlevad, võidab täpselt üks nõue ja teisele teatatakse sellest.

Puuduv lõpetamiskirje ei ole tõestus, et pooleliolev tehing ei commiti kunagi. Nõue peab konkureerivad katsed serialiseerima, või protokoll peab enne mistahes otsust kestva tulemuse lugema.

Kasuta selleks serialiseerimiseks andmebaasi toetatud mehhanismi, mitte rakenduse koodis kontrolli-ja-korda-tsüklit.

Mida disain siiski lubada ei saa

Ettevalmistus muudab töö taaskäivitatavaks ja vähendab sõltuvust ühest pikaajalisest sessioonist. See ei loo ühtset atomaarset commiti üle SQL Serveri, Oracle'i ja ükskõik millise välise kõrvalmõju, mida töö tekitab. Kui äri seda tõesti vajab, projekteeri ja kvalifitseeri toetatud hajutatud tehing või võrdlemisprotsess, sealhulgas see, kellele kuulub ebakindla tulemusega töö. Kõik sellest nõrgem kuulub võrdlemise runbooki, mitte ülekandekoodi.

Nõustu katkestusega kolmes kohas: ülekande ajal, rakendamise ajal ja pärast commiti, kuid enne kinnitust. Seejärel kontrolli äritulemust, mitte kliendi sõnumit, ja lase partiiregistril öelda, kas töö on puudulik, commititud või veel lahendamata.