Menangani kesalahan konektivitas sementara untuk Azure Database for PostgreSQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Artikel ini menjelaskan cara menangani kesalahan sementara yang menyambungkan ke server fleksibel Azure Database for PostgreSQL.

Kesalahan sementara

Kesalahan sementara, juga disebut sebagai kerusakan sementara, adalah kesalahan yang akan terselesaikan sendiri. Biasanya kesalahan ini muncul ketika koneksi ke server database terputus. Juga koneksi baru ke server tidak dapat dibuka. Kesalahan sementara dapat terjadi misalnya saat terjadi kegagalan perangkat keras atau jaringan. Alasan lain dapat berupa versi baru layanan PaaS yang sedang diluncurkan. Sebagian besar peristiwa ini otomatis dimitigasi oleh sistem dalam waktu kurang dari 60 detik. Praktik terbaik untuk merancang dan mengembangkan aplikasi di cloud adalah mengantisipasi kesalahan sementara. Anggap kesalahan itu dapat terjadi dalam komponen apa pun kapan saja dan siapkan logika yang sesuai untuk menangani situasi ini.

Menangani kesalahan sementara

Kesalahan sementara harus ditangani menggunakan logika coba ulang. Situasi yang harus dipertimbangkan:

  • Kesalahan terjadi saat Anda mencoba membuka koneksi
  • Koneksi tidak aktif terputus di sisi server. Saat Anda mencoba mengeluarkan perintah, itu tidak dapat dijalankan
  • Koneksi aktif yang saat ini sedang menjalankan perintah akan diputuskan.

Kasus pertama dan kedua cukup mudah untuk ditangani. Coba buka koneksi lagi. Ketika Anda berhasil, kesalahan sementara telah dimitigasi oleh sistem. Anda dapat menggunakan instans server fleksibel Azure Database for PostgreSQL lagi. Kami sarankan untuk menunggu sebelum mencoba kembali koneksi. Berhenti dulu jika upaya awal gagal. Dengan cara ini sistem dapat menggunakan semua sumber daya yang tersedia untuk mengatasi situasi kesalahan. Pola yang baik untuk diikuti adalah:

  • Menunggu selama 5 detik sebelum mencoba lagi.
  • Untuk setiap percobaan ulang berikut, tingkatkan tunggu secara eksponensial, hingga 60 detik.
  • Tetapkan jumlah coba ulang maksimum saat aplikasi Anda menganggap operasi gagal.

Saat koneksi dengan transaksi aktif gagal, lebih sulit untuk menangani pemulihan dengan benar. Ada dua kasus: Jika transaksi bersifat baca-saja, aman untuk membuka kembali koneksi dan mencoba kembali transaksi. Namun, jika transaksi juga menulis ke database, Anda harus menentukan apakah transaksi digulung balik, atau jika transaksi berhasil sebelum kesalahan sementara terjadi. Dalam hal ini, Anda mungkin belum menerima pengakuan komit dari server database.

Salah satu cara melakukan ini, adalah dengan membuat ID unik pada klien yang digunakan untuk semua coba ulang. Anda meneruskan ID unik ini sebagai bagian dari transaksi ke server dan menyimpannya dalam kolom dengan batasan unik. Dengan cara ini Anda dapat mencoba kembali transaksi dengan aman. Ini akan berhasil jika transaksi sebelumnya digulung balik dan klien yang membuat ID unik belum ada dalam sistem. Sebaliknya akan gagal jika menunjukkan pelanggaran kunci duplikat jika ID unik sebelumnya disimpan karena transaksi sebelumnya berhasil diselesaikan.

Saat program Anda berkomunikasi dengan server fleksibel Azure Database for PostgreSQL melalui middleware pihak ketiga, tanyakan kepada vendor apakah middleware berisi logika coba lagi untuk kesalahan sementara.

Pastikan untuk menguji logika coba lagi. Misalnya, coba jalankan kode Anda saat meningkatkan atau menurunkan skala sumber daya komputasi instans server fleksibel Azure Database for PostgreSQL Anda. Aplikasi Anda harus menangani waktu henti singkat yang dialami selama operasi ini tanpa masalah.