PolarDB：Koneksi Persisten

Prasyarat

• Versi PolarProxy dari kluster PolarDB harus 2.4.7 atau lebih baru. Untuk informasi lebih lanjut tentang cara memeriksa versi saat ini dan memperbarui PolarProxy, lihat Peningkatan versi minor.

• Kluster PolarDB for MySQL versi 5.6, 5.7, atau 8.0 dalam Edisi Kluster.

• Hanya lalu lintas yang mengakses titik akhir kluster default atau titik akhir kustom dengan kebijakan Active requests-based load balancing yang mendukung koneksi persisten.

Informasi latar belakang

PolarDB mendukung failover primer/sekunder melalui komponen ketersediaan tinggi untuk memastikan kluster memiliki ketersediaan tinggi. Namun, failover dapat menyebabkan gangguan layanan sementara atau kegagalan koneksi, yang memengaruhi aplikasi Anda. Aplikasi mungkin terputus sementara dalam skenario berikut:

• Pergantian: Pergantian dipicu oleh aktivitas O&M seperti peningkatan spesifikasi, Failover otomatis dan manual, serta peningkatan versi minor.

• Failover: Failover dipicu oleh anomali seperti kegagalan node primer atau kerusakan server.

Dalam banyak kasus, masalah ini dapat diatasi dengan memulai ulang aplikasi atau mengonfigurasi mekanisme penyambungan otomatis. Namun, jika hal ini tidak diperhitungkan pada tahap awal pengembangan karena siklus pengembangan yang singkat, dapat menyebabkan sejumlah besar pengecualian atau gangguan layanan. PolarDB mendukung fitur koneksi persisten untuk mencegah masalah konektivitas yang disebabkan oleh aktivitas O&M atau anomali seperti peningkatan spesifikasi, pergantian, peningkatan versi minor, atau kerusakan server. Fitur ini meningkatkan ketersediaan kluster PolarDB.

Cara kerja koneksi persisten

Pergantian node primer

Setiap sesi dalam kluster PolarDB terdiri dari koneksi frontend antara aplikasi dan PolarProxy, serta koneksi backend antara PolarProxy dan database backend. Saat fitur koneksi persisten diaktifkan, jika PolarProxy terputus dari node primer saat ini dan terhubung ke node primer baru, koneksi (sesi yang ditampilkan di aplikasi) antara PolarProxy dan aplikasi tetap aktif. PolarProxy membuat koneksi ke node primer baru dan kemudian memulihkan sesi ke status sebelum pergantian dilakukan, sehingga membuat seluruh proses pergantian transparan bagi aplikasi.

Sesi MySQL biasanya mencakup informasi berikut: variabel sistem, variabel pengguna, tabel sementara, pengkodean set karakter, status transaksi, dan status pernyataan PREPARE. Dalam topik ini, status pengkodean set karakter digunakan sebagai contoh untuk menunjukkan bagaimana status sesi berubah sebelum dan sesudah koneksi persisten diaktifkan.

Koneksi dibuat antara aplikasi dan PolarProxy, dan pernyataan set names utf8; dieksekusi. Dalam hal ini, sesi berada dalam status names=utf8. Ketika PolarProxy terhubung ke node primer baru, status sesi harus tetap tidak berubah. Jika tidak, kesalahan pengkodean set karakter akan terjadi. Untuk mencegah kesalahan ini, status sesi harus tetap tidak berubah setelah pergantian selesai.

Penghapusan node hanya-baca

Anda dapat menghapus node hanya-baca dari titik akhir kluster default atau titik akhir kustom yang menggunakan kebijakan Active requests-based load balancing. Jika permintaan sedang dieksekusi pada node hanya-baca yang akan dihapus, dan waktu eksekusi permintaan tersebut melebihi 60 detik setelah proxy menerima permintaan penghapusan node hanya-baca, koneksi yang sesuai dengan permintaan ini terputus. Skenario lain di mana koneksi tidak dapat dipertahankan tercantum dalam Catatan Penggunaan. Setelah proxy menerima permintaan penghapusan node hanya-baca, semua koneksi baru dan permintaan baru yang menganggur tidak lagi dirutekan ke node tersebut.

Catatan Penggunaan

Koneksi dalam skenario berikut tidak dapat dipertahankan:

• Ketika PolarProxy terhubung ke node primer baru, tabel sementara ada dalam sesi.

• Ketika PolarProxy terhubung ke node primer baru, pesan hasil sedang dikirimkan dari database ke PolarProxy, namun PolarProxy hanya menerima sebagian dari pesan tersebut. Misalnya, setelah Anda mengeksekusi pernyataan SELECT, pesan hasil berukuran 100 MB dikembalikan ke PolarProxy, namun PolarProxy hanya menerima 10 MB dari pesan tersebut ketika pergantian dipicu.

• Ketika PolarProxy terhubung ke node primer baru, transaksi yang sedang berlangsung ada dalam sesi, seperti begin;insert into;.

• Metode cursor atau stmt_send_long_data digunakan dan permintaan masih dieksekusi ketika pergantian dimulai.

Tolok ukur kinerja

• Lingkungan

  • Kluster berikut digunakan untuk benchmarking:

    • Kluster PolarDB for MySQL 8.0. Secara default, kluster berisi satu node primer dan dua node hanya-baca.

    • Spesifikasi node adalah 4-core 16 GB (polar.mysql.x4.large).

  • Alat uji: Sysbench.

  • Data uji:

    • 20 tabel digunakan dalam pengujian. Setiap tabel berisi 10.000 baris.

    • Tingkat paralelisme adalah 20.

• Prosedur

  Uji rasio koneksi yang dipertahankan dalam kluster PolarDB sebelum dan sesudah aktivitas O&M dilakukan.

• Hasil Uji

  Dalam skenario berikut, rasio koneksi yang dipertahankan dalam kluster PolarDB adalah 100%.

  Catatan

  • Rasio koneksi yang dipertahankan adalah 100% hanya jika Anda meningkatkan spesifikasi kluster secara bertahap, seperti dari 4 core menjadi 8 core. Jika Anda meningkatkan spesifikasi kluster dari 4 core menjadi 16 core atau lebih tinggi, gangguan layanan mungkin terjadi.

  • Jika node proksi database diturunkan saat node hanya-baca dihapus, beberapa koneksi mungkin ditutup.

  • Dalam bagian ini, hanya peningkatan versi minor mesin kernel database yang diuji. Pengujian ini tidak termasuk peningkatan versi minor proksi database. Selama peningkatan versi minor proksi database, gangguan jaringan mungkin terjadi.

  Skenario	Rasio koneksi yang dipertahankan
  Beralih ke node primer baru	100%
  Tingkatkan versi minor mesin kernel database	100%
  Tingkatkan spesifikasi kluster	100%
  Tambah atau hapus node	100%