Menangani kesalahan sementara dan terhubung secara efisien ke Azure Database for MySQL

  • Artikel

BERLAKU UNTUKAzure Database for MySQL - Server Tunggal

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Artikel ini menjelaskan cara menangani kesalahan sementara dan terhubung secara efisien ke Azure Database for MySQL.

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 untuk meluncurkan perintah, tindakan ini tidak dapat dijalankan
  • Koneksi aktif yang saat ini sedang menjalankan perintah akan diputuskan.

Kasus pertama dan kedua cukup sederhana untuk ditangani. Coba buka koneksi lagi. Ketika Anda berhasil, kesalahan sementara telah dimitigasi oleh sistem. Anda bisa menggunakan Azure Database for MySQL 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 coba ulang selanjutnya, tambahkan waktu 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. Cara ini akan berhasil jika transaksi sebelumnya digulung balik dan klien yang menghasilkan 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 Azure Database for MySQL melalui middleware pihak ketiga, tanyakan kepada vendor apakah middleware berisi logika retry untuk kesalahan sementara.

Pastikan untuk menguji logika coba lagi Anda. Misalnya, coba eksekusi kode Anda saat menskalakan naik atau turun sumber daya komputasi server Azure Database for MySQL. Aplikasi Anda harus menangani waktu henti singkat yang dialami selama operasi ini tanpa masalah.

Menyambung secara efisien ke Azure Database for MySQL

Koneksi database adalah sumber daya terbatas, jadi memanfaatkan kumpulan koneksi secara efektif untuk mengakses Azure Database for MySQL akan mengoptimalkan kinerja. Bagian di bawah ini menjelaskan cara menggunakan kumpulan koneksi atau koneksi tetap untuk mengakses Azure Database for MySQL secara lebih efektif.

Mengelola koneksi database dapat berdampak signifikan pada performa aplikasi secara keseluruhan. Untuk mengoptimalkan kinerja aplikasi Anda, tujuannya haruslah mengurangi berapa kali koneksi dibuat dan waktu untuk membuat koneksi di jalur kode utama. Kami sangat menyarankan penggunaan kumpulan koneksi database atau koneksi tetap untuk menyambungkan ke Azure Database for MySQL. Kumpulan koneksi database menangani pembuatan, manajemen, dan alokasi koneksi database. Ketika program meminta koneksi database, program memprioritaskan pengalokasian koneksi database siaga yang ada, alih-alih pembuatan koneksi baru. Setelah program selesai menggunakan koneksi database, koneksi dipulihkan dalam persiapan untuk penggunaan lebih lanjut, alih-alih hanya ditutup.

Untuk ilustrasi yang lebih baik, artikel ini menyediakan sepotong kode sampel yang menggunakan JAVA sebagai contoh. Untuk informasi selengkapnya, lihat Apache umum DBCP.

Catatan

Server mengonfigurasi mekanisme waktu habis untuk menutup sambungan yang telah dalam keadaan menganggur selama beberapa waktu untuk membebaskan sumber daya. Pastikan untuk menyiapkan sistem verifikasi guna memastikan efektivitas koneksi tetap saat Anda menggunakannya. Untuk informasi selengkapnya, lihat Mengonfigurasi sistem verifikasi di sisi klien untuk memastikan efektivitas koneksi persisten.

Konsep koneksi persisten mirip dengan pooling koneksi. Mengganti koneksi singkat dengan koneksi persisten hanya memerlukan perubahan kecil pada kode, tetapi memiliki efek besar dalam hal meningkatkan kinerja dalam banyak skenario aplikasi biasa.

Mengakses database menggunakan mekanisme wait dan retry dengan koneksi singkat

Jika Anda memiliki keterbatasan sumber daya, kami sangat menyarankan Anda menggunakan kumpulan database atau koneksi persisten untuk mengakses database. Jika aplikasi Anda menggunakan koneksi singkat dan mengalami kegagalan koneksi saat mendekati batas atas jumlah koneksi bersamaan, Anda dapat mencoba mekanisme wait dan retry. Anda dapat mengatur waktu tunggu yang sesuai, dengan waktu tunggu yang lebih singkat setelah upaya pertama. Setelah itu, Anda dapat mencoba menunggu peristiwa beberapa kali.

Mengonfigurasi mekanisme verifikasi pada klien untuk mengonfirmasi efektivitas koneksi persisten

Server mengonfigurasi mekanisme waktu habis untuk menutup sambungan yang berada dalam keadaan menganggur selama beberapa waktu untuk membebaskan sumber daya. Ketika klien mengakseslagi database tersebut, akan setara dengan membuat permintaan koneksi baru antara klien dan server. Untuk memastikan efektivitas koneksi selama proses penggunannya, konfigurasikan mekanisme verifikasi pada klien. Seperti yang ditunjukkan dalam contoh berikut, Anda dapat menggunakan kumpulan koneksi Tomcat JDBC untuk mengonfigurasi mekanisme verifikasi ini.

Dengan mengatur parameter TestOnBorrow, ketika ada permintaan baru, kumpulan koneksi secara otomatis memverifikasi efektivitas koneksi menganggur yang tersedia. Jika koneksi seperti itu efektif, kumpulan koneksi dikembalikan secara langsung jika tidak justru akan menarik koneksi. Kumpulan koneksi kemudian membuat koneksi efektif baru dan mengembalikannya. Proses ini memastikan bahwa database diakses secara efisien.

Untuk informasi tentang pengaturan tertentu, lihat Dokumen pengenalan resmi kumpulan koneksi JDBC. Anda terutama perlu mengatur tiga parameter berikut: TestOnBorrow (diatur ke true), ValidationQuery (diatur ke SELECT 1), dan ValidationQueryTimeout (diatur ke 1). Kode sampel spesifik ditunjukkan di bawah ini:

public class SimpleTestOnBorrowExample {
      public static void main(String[] args) throws Exception {
          PoolProperties p = new PoolProperties();
          p.setUrl("jdbc:mysql://localhost:3306/mysql");
          p.setDriverClassName("com.mysql.jdbc.Driver");
          p.setUsername("root");
          p.setPassword("password");
            // The indication of whether objects will be validated by the idle object evictor (if any). 
            // If an object fails to validate, it will be dropped from the pool. 
            // NOTE - for a true value to have any effect, the validationQuery or validatorClassName parameter must be set to a non-null string. 
          p.setTestOnBorrow(true); 

            // The SQL query that will be used to validate connections from this pool before returning them to the caller.
            // If specified, this query does not have to return any data, it just can't throw a SQLException.
          p.setValidationQuery("SELECT 1");

            // The timeout in seconds before a connection validation queries fail. 
            // This works by calling java.sql.Statement.setQueryTimeout(seconds) on the statement that executes the validationQuery. 
            // The pool itself doesn't timeout the query, it is still up to the JDBC driver to enforce query timeouts. 
            // A value less than or equal to zero will disable this feature.
          p.setValidationQueryTimeout(1);
            // set other useful pool properties.
          DataSource datasource = new DataSource();
          datasource.setPoolProperties(p);

          Connection con = null;
          try {
            con = datasource.getConnection();
            // execute your query here
          } finally {
            if (con!=null) try {con.close();}catch (Exception ignore) {}
          }
      }
  }

Langkah berikutnya