Pulihkan pemuatan daripada SQL Server ke Oracle selepas VPN terputus
VPN yang terputus membuatkan pemanggil tidak pasti sama ada commit di Oracle telah berlaku. ID kelompok yang tahan lama membolehkan pengekstrakan, penggunaan dan penyelarasan dijawab satu demi satu.
Pemindahan antara pangkalan data mati apabila VPN terputus, dan «jalankan semula» bukan rancangan pemulihan. Pengekstrakan sumber mungkin sudah selesai, sasaran mungkin sudah melakukan commit, atau balasan mungkin hilang begitu sahaja dalam perjalanan balik. Ketiga-tiga keadaan ini memerlukan tindakan berbeza, dan klien yang hanya tahu «ralat» tidak dapat membezakannya.
Pembaikannya bersifat seni bina: beri setiap pelaksanaan identiti kelompok yang tahan lama, dan biarkan pangkalan data menjawab soalan daripada membiarkan klien meneka.
Apa yang sebenarnya dijamin oleh pangkalan data
SQL Server dan Oracle kedua-duanya memberikan keatoman di dalam transaksi. Kedua-duanya tidak memberikan keatoman merentas kedua-duanya. Sambungan yang hilang tidak merosakkan pangkalan data dan tidak memaksa rollback manual, kerana pelayan menyelesaikan transaksinya sendiri tanpa anda. Yang rosak ialah pengetahuan pemanggil tentang hasilnya.
Commit secara berasingan bermakna commit secara berasingan. VPN yang membawa kedua-dua sambungan tidak melakurkan dua commit menjadi satu unit kerja.
Commit yang anda tidak pernah dengar
Satu mod kegagalan menghukum logik cuba semula yang naif: pelayan melakukan commit, dan pengesahan tidak pernah sampai kepada pemanggil. Oracle mendokumenkan ini sebagai masalah hasil tidak diketahui dan menyediakan Transaction Guard untuknya dalam dokumentasi transaksi. Ralat komunikasi bukan bukti bahawa commit yang dihantar telah gagal, dan memperlakukannya sebagai bukti ialah cara sesuatu kelompok disiarkan dua kali. Perbezaan ini paling penting pada laluan cuba semula, di mana pengendali mempunyai mesej ralat dan tiada isyarat lain untuk bertindak.
Jadi langkah pemulihan mesti membaca hasil daripada sasaran dan bukannya menyimpulkannya daripada teks ralat.
Beri pemindahan identiti kelompok
Setiap pelaksanaan mendapat ID kelompok yang tidak berubah, dan sasaran merekodkan apa yang dilakukannya dengan ID itu. Kitaran hayat mempunyai empat langkah, dan ia kelihatan sama tanpa mengira vendor:
- Ekstrak kelompok sumber yang dikenal pasti dan tidak berubah dengan skema dan sempadan yang direkodkan.
- Pindahkan ke kawasan pementasan sasaran dan kesan kandungan tidak lengkap atau bercanggah sebelum mengisytiharkannya sedia.
- Guna di bawah peraturan keunikan atau penguncian sasaran sendiri dan rekodkan penyempurnaan dalam transaksi tempatan yang sama.
- Segerakkan hasil tahan lama melalui protokol yang disokong sebelum mengesahkan atau mencuba semula.
Cuba semula menggunakan ID yang sama. ID baharu bagi setiap percubaan menggagalkan pencegahan pendua yang baru anda bina, yang kedengaran jelas sehingga pembalut cuba semula menjana satu secara automatik.
ID itu juga memberikan anda sesuatu untuk disegerakkan kemudian, lama selepas proses klien hilang.
Tuntut kelompok itu, kemudian gunakan
Langkah penggunaan mesti menuntut ID kelompok, membuat perubahan perniagaan, dan merekodkan penyempurnaan dalam satu transaksi tempatan. Melakukan pemeriksaan dan sisipan sebagai kenyataan berasingan memperkenalkan semula perlumbaan yang anda cuba hapuskan. Jika dua pekerja bersaing, tepat satu tuntutan menang dan yang lain diberitahu.
Rekod penyempurnaan yang tiada bukan bukti bahawa transaksi yang sedang berjalan tidak akan pernah commit. Tuntutan itu mesti menyiri pesaing, atau protokol mesti membaca hasil tahan lama sebelum memutuskan apa-apa.
Gunakan mekanisme pangkalan data yang disokong untuk penyirian itu dan bukannya gelung semak-dan-ulang dalam kod aplikasi.
Apa yang reka bentuk masih tidak boleh janjikan
Pementasan menjadikan kerja boleh dimulakan semula dan mengurangkan pergantungan pada satu sesi yang panjang. Ia tidak mencipta satu commit atomik merentas SQL Server, Oracle dan apa-apa kesan sampingan luaran yang dilakukan oleh kerja itu. Jika perniagaan benar-benar memerlukannya, reka dan kelayakan transaksi teragih yang disokong atau proses penyelarasan, termasuk siapa yang memiliki kerja yang hasilnya tidak pasti. Apa-apa yang lebih lemah daripada itu tergolong dalam runbook penyelarasan, bukan dalam kod pemindahan.
Terima gangguan di tiga tempat: semasa pemindahan, semasa penggunaan, dan selepas commit tetapi sebelum pengesahan. Kemudian semak hasil perniagaan dan bukannya mesej klien, dan biarkan lejar kelompok mengatakan sama ada kerja itu tidak lengkap, telah commit, atau masih belum diselesaikan.