SQL Server–Oracle betöltés helyreállítása VPN-kiesés után

A két adatbázis közötti átvitel meghal, amikor a VPN megszakad, és a „futtasd újra“ nem helyreállítási terv. A forrás kinyerése befejeződhetett, a cél már commitolhatott, vagy a válasz egyszerűen elveszett a visszaúton. Ez a három állapot különböző lépéseket igényel, és egy kliens, amely csak a „hibát“ ismeri, nem tudja megkülönböztetni őket.

A megoldás architekturális: adj minden futásnak tartós kötegidentitást, és hagyd, hogy az adatbázisok válaszoljanak a kérdésekre ahelyett, hogy a kliens találgatna.

Mit garantál valójában az adatbázis

Az SQL Server és az Oracle is atomitást ad egy tranzakción belül. Egyik sem ad atomitást a kettő között. Az elveszett kapcsolat nem rontja el az adatbázist, és nem kényszerít kézi visszagörgetésre sem, mert a kiszolgáló maga oldja meg a saját tranzakcióját nélküled. Ami eltörik, az a hívó tudása az eredményről.

Külön commitolva külön commitolva jelent. A két kapcsolatot szállító VPN nem olvaszt két commitot egyetlen munkaegységbe.

A commit, amelyről soha nem hallottál

Egy hibaállapot megbünteti a naiv újrapróbálkozási logikát: a kiszolgáló commitol, és a visszaigazolás soha nem ér el a hívóhoz. Az Oracle ezt ismeretlen kimenetel problémájaként dokumentálja, és erre Transaction Guardot biztosít a tranzakciós dokumentációban. A kommunikációs hiba nem bizonyíték arra, hogy egy elküldött commit meghiúsult, és bizonyítékként kezelni az az út, amelyen egy köteg kétszer kerül feladásra. A különbség a legfontosabb az újrapróbálkozási úton, ahol a kezelőnek hibaüzenete van, és semmilyen más jele nincs, amelyre támaszkodhatna.

Ezért a helyreállítási lépésnek a célból kell kiolvasnia az eredményt, nem pedig a hiba szövegéből következtetnie rá.

Adj kötegidentitást az átvitelnek

Minden futás változhatatlan kötegazonosítót kap, és a cél rögzíti, mit tett ezzel az azonosítóval. Az életciklus négy lépésből áll, és szállítótól függetlenül ugyanúgy néz ki:

1. Kinyerés egy azonosított, változhatatlan forrásköteg rögzített sémával és határral.
2. Átvitel a cél előkészítő területére, és a hiányos vagy ellentmondó tartalom felismerése a késznek nyilvánítás előtt.
3. Alkalmazás a cél saját egyediség- vagy zárolási szabályai szerint, és a befejezés rögzítése ugyanabban a helyi tranzakcióban.
4. Egyeztetés a tartós eredményről a támogatott protokollon keresztül a visszaigazolás vagy az újrapróbálkozás előtt.

Az újrapróbálkozások ugyanazt az azonosítót használják. Az új azonosító próbálkozásonként aláássa az éppen felépített duplikátumvédelmet, ami addig tűnik magától értetődőnek, amíg egy újrapróbálkozási burkoló automatikusan nem generál egyet.

Az azonosító arra is ad valamit, amihez később egyeztetni lehet, jóval azután, hogy a kliens folyamat eltűnt.

Foglald le a köteget, aztán alkalmazd

Az alkalmazási lépésnek le kell foglalnia a kötegazonosítót, végre kell hajtania az üzleti változtatásokat, és egy helyi tranzakcióban rögzítenie kell a befejezést. Az ellenőrzés és a beszúrás külön utasításként való végrehajtása visszahozza azt a versenyt, amelyet el akartál távolítani. Ha két munkás verseng, pontosan egy foglalás nyer, és a másikkal ezt közlik.

A hiányzó befejezési rekord nem bizonyíték arra, hogy egy folyamatban lévő tranzakció soha nem fog commitolni. A foglalásnak sorba kell rendeznie a versengő próbálkozásokat, vagy a protokollnak bármilyen döntés előtt ki kell olvasnia a tartós eredményt.

Ehhez a sorba rendezéshez az adatbázis támogatott mechanizmusát használd az alkalmazáskódban futó ellenőriz-és-ismétel ciklus helyett.

Amit a tervezés még mindig nem ígérhet

Az előkészítés újraindíthatóvá teszi a munkát, és csökkenti az egyetlen hosszú életű munkamenettől való függést. Nem hoz létre egyetlen atomi commitot az SQL Server, az Oracle és bármilyen külső mellékhatás fölött, amelyet a munka végrehajt. Ha az üzletnek valóban szüksége van rá, tervezz és minősíts egy támogatott elosztott tranzakciót vagy egyeztetési folyamatot, beleértve azt is, kié a bizonytalan kimenetelű munka. Bármi, ami ennél gyengébb, az egyeztetési runbookba tartozik, nem az átviteli kódba.

Fogadd el a megszakítást három helyen: az átvitel alatt, az alkalmazás alatt, és a commit után, de a visszaigazolás előtt. Ezután az üzleti eredményt ellenőrizd a kliens üzenete helyett, és hagyd, hogy a kötegnapló megmondja, a munka hiányos, commitolt vagy még megoldatlan.