VPN kəsiləndən sonra SQL Server-dən Oracle-a yükləməni bərpa edin

VPN kəsiləndə verilənlər bazaları arası köçürmə dayanır və «yenidən işə sal» bərpa planı deyil. Mənbə çıxarışı bitmiş ola bilər, hədəf artıq commit edib ola bilər, ya da cavab sadəcə geri yolda itmiş ola bilər. Bu üç vəziyyət fərqli tədbirlər tələb edir və yalnız «xəta» bilən müştəri onları bir-birindən ayıra bilməz.

Həll arxitekturadadır: hər işə davamlı partiya kimliyi verin və müştərinin təxmin etməsinə imkan vermək əvəzinə verilənlər bazalarına sualları cavablandırmağa qoyun.

Verilənlər bazası əslində nəyə zəmanət verir

SQL Server və Oracle hər ikisi tranzaksiya daxilində atomluq verir. Heç biri ikisinin arasında atomluq vermir. İtmiş bağlantı verilənlər bazasını korlamır və əl ilə geri qaytarmaya da məcbur etmir, çünki server öz tranzaksiyasını sənsiz həll edir. Pozulan şey çağıranın nəticə barədə biliyidir.

Ayrı-ayrı commit etmək ayrı-ayrı commit etmək deməkdir. Hər iki bağlantını daşıyan VPN iki commit-i bir iş vahidinə birləşdirmir.

Heç eşitmədiyiniz commit

Bir nasazlıq rejimi sadəlövh yenidən cəhd məntiqini cəzalandırır: server commit edir və təsdiq heç vaxt çağırana çatmır. Oracle bunu naməlum nəticə problemi kimi sənədləşdirir və bunun üçün tranzaksiya sənədlərində Transaction Guard təqdim edir. Rabitə xətası göndərilmiş commit-in uğursuz olduğuna dəlil deyil, və ona dəlil kimi yanaşmaq partiyanın iki dəfə göndərilməsinin yoludur. Bu fərq ən çox yenidən cəhd yolunda önəm daşıyır, çünki operatorun əlində xəta mesajı var və hərəkət etmək üçün başqa siqnal yoxdur.

Deməli, bərpa addımı nəticəni xəta mətnindən çıxarmaq əvəzinə hədəfdən oxumalıdır.

Köçürməyə partiya kimliyi verin

Hər iş dəyişməz partiya ID-si alır və hədəf həmin ID ilə nə etdiyini qeyd edir. Həyat dövrü dörd addımdır və təchizatçıdan asılı olmayaraq eyni görünür:

1. Çıxarın qeydə alınmış sxem və sərhədi olan, müəyyən edilmiş, dəyişməz mənbə partiyasını.
2. Köçürün onu hədəfin hazırlıq sahəsinə və hazır elan etməzdən əvvəl natamam və ya ziddiyyətli məzmunu aşkarlayın.
3. Tətbiq edin onu hədəfin öz unikallıq və ya kilidləmə qaydalarına uyğun və tamamlanmanı həmin yerli tranzaksiyada qeyd edin.
4. Uzlaşdırın davamlı nəticəni dəstəklənən protokol vasitəsilə, təsdiqdən və ya yenidən cəhddən əvvəl.

Yenidən cəhdlər ID-ni təkrar istifadə edir. Hər cəhd üçün yeni ID indicə qurduğunuz dublikat qarşısının alınmasını boşa çıxarır; bu, yenidən cəhd sarğısı avtomatik bir ID yaradana qədər aydın görünür.

ID həm də sonradan, müştəri prosesi çoxdan yox olduqdan sonra uzlaşdırmaq üçün sizə bir şey verir.

Partiyanı iddia edin, sonra tətbiq edin

Tətbiq addımı partiya ID-sini iddia etməli, biznes dəyişikliklərini etməli və tamamlanmanı bir yerli tranzaksiyada qeyd etməlidir. Yoxlamanı və daxil etməni ayrı-ayrı ifadələr kimi etmək aradan qaldırmağa çalışdığınız yarışı yenidən gətirir. İki işçi yarışarsa, tam olaraq bir iddia qalib gəlir və digərinə bu barədə məlumat verilir.

Tamamlanma qeydinin olmaması davam edən tranzaksiyanın heç vaxt commit etməyəcəyinə sübut deyil. İddia rəqabət edən cəhdləri ardıcıllaşdırmalıdır, ya da protokol hər hansı qərardan əvvəl davamlı nəticəni oxumalıdır.

Həmin ardıcıllaşdırma üçün tətbiq kodunda yoxla-və-təkrar dövrəsi yerinə verilənlər bazasının dəstəklənən mexanizmindən istifadə edin.

Dizaynın hələ də vəd edə bilmədiyi şeylər

Hazırlıq işi yenidən başladıla bilən edir və bir uzunmüddətli sessiyadan asılılığı azaldır. SQL Server, Oracle və işin həyata keçirdiyi hər hansı xarici yan təsir üzərində tək atomik commit yaratmır. Əgər biznes buna həqiqətən ehtiyac duyursa, dəstəklənən paylanmış tranzaksiya və ya uzlaşdırma prosesi dizayn edin və yoxlayın, o cümlədən şübhəli işin kimə aid olduğunu. Bundan zəif olan hər şey köçürmə koduna yox, uzlaşdırma runbook-una aiddir.

Üç yerdə fasiləni qəbul edin: köçürmə zamanı, tətbiq zamanı və commit-dən sonra, lakin təsdiqdən əvvəl. Sonra müştərinin mesajı yerinə biznes nəticəsini yoxlayın və partiya jurnalı işin natamam, commit olunmuş və ya hələ də həll olunmamış olduğunu desin.