Aktivitas O&M—seperti peningkatan spesifikasi, alih bencana, dan peningkatan versi minor—serta kejadian tak terencana seperti kegagalan node primary dapat memutus koneksi aplikasi Anda dari PolarDB. Tanpa koneksi persisten, aplikasi Anda harus mendeteksi pemutusan tersebut dan melakukan koneksi ulang, yang berpotensi menyebabkan gangguan layanan atau memerlukan logika koneksi ulang dalam kode. Dengan koneksi persisten diaktifkan, PolarProxy menjaga koneksi frontend tetap aktif selama kejadian tersebut dan memulihkan status sesi secara transparan, sehingga aplikasi Anda tidak mengalami gangguan.
Konfigurasi yang didukung
Koneksi persisten memerlukan hal-hal berikut:
Versi PolarProxy 2.4.7 atau lebih baru. Untuk memeriksa versi Anda dan melakukan upgrade, lihat Minor version upgrade.
PolarDB for MySQL 5.6, 5.7, atau 8.0 (Cluster Edition).
Jenis endpoint yang didukung (lihat tabel di bawah).
Jenis endpoint yang didukung:
| Endpoint type | Load balancing policy | Persistent connections supported |
|---|---|---|
| Default cluster endpoint | Any | Yes |
| Custom endpoint | Active requests-based load balancing | Yes |
| Custom endpoint | Connections-based load balancing | No — removing a node disconnects all connections on that node |
| Direct connection to a read-only node | N/A | No — always disconnected on node removal |
Cara kerja
Primary node switchover
Setiap sesi database memiliki dua lapisan:
Frontend connection antara aplikasi Anda dan PolarProxy
Backend connection antara PolarProxy dan node primary atau read-only
Tanpa koneksi persisten, alih bencana node primary memutus kedua lapisan tersebut, sehingga aplikasi Anda harus melakukan koneksi ulang. Dengan koneksi persisten diaktifkan, PolarProxy menjaga koneksi frontend tetap aktif sambil memutus koneksi dari node primary lama, terhubung ke node primary baru, dan memulihkan status sesi. Proses alih bencana ini transparan bagi aplikasi Anda.
Pemulihan status sesi
Sesi MySQL menyimpan status yang harus dipertahankan setelah alih bencana, seperti variabel sistem, variabel pengguna, tabel temporary, set karakter, status transaksi, dan status prepared statement. Saat PolarProxy terhubung ke node primary baru, status tersebut diputar ulang sehingga pengaturan sesi aplikasi Anda tetap konsisten.
Sebagai contoh, setelah eksekusi set names utf8;, sesi berada dalam status names=utf8. PolarProxy memulihkan pengaturan ini pada node primary baru, sehingga tidak terjadi error terkait set karakter.
Waktu selama alih bencana
Saat node primary baru mengambil alih, baik database asli maupun database baru sementara tidak dapat diakses. Durasi periode ini bergantung pada beban database.
Jika node primary baru pulih dalam waktu 60 detik, PolarProxy mengarahkan permintaan ke node tersebut dan sesi berlanjut.
Jika node primary baru tidak pulih dalam waktu 60 detik, PolarProxy memutus koneksi. Aplikasi Anda harus melakukan koneksi ulang, terlepas dari apakah koneksi persisten diaktifkan atau tidak.
Penghapusan node read-only
Setelah PolarProxy menerima permintaan penghapusan node read-only, semua koneksi baru dan permintaan idle segera dialihkan dari node tersebut.
Jika permintaan sedang berjalan di node yang akan dihapus, PolarProxy menunggu hingga 60 detik agar permintaan tersebut selesai. Jika permintaan selesai dalam jangka waktu tersebut, koneksi tetap dipertahankan. Namun, jika permintaan masih berjalan setelah 60 detik, koneksi akan diputus.
Menghapus node read-only dari endpoint yang menggunakan kebijakan Connections-based load balancing memutus semua koneksi pada node tersebut, termasuk koneksi langsung ke node tersebut.
Batasan
Koneksi persisten tidak dapat menjaga sesi tetap aktif dalam situasi berikut:
| Situation | Description |
|---|---|
| Active temporary tables | Sesi memiliki tabel temporary saat alih bencana dimulai. |
| Partial result delivery | Hasil kueri hanya sebagian yang telah dikirimkan ke PolarProxy saat alih bencana terjadi. Misalnya, pernyataan SELECT mengembalikan 100 MB, tetapi hanya 10 MB yang telah diterima saat pemicu alih bencana aktif. |
| In-progress transactions | Terdapat transaksi aktif saat alih bencana dimulai—misalnya, begin; insert into .... |
Cursor atau stmt_send_long_data sedang digunakan | Kursor atau metode stmt_send_long_data sedang digunakan, dan permintaan belum selesai saat alih bencana dimulai. |
Saat alih bencana atau penghapusan node dimulai, PolarProxy menunggu hingga 60 detik agar koneksi aktif menjadi idle—yaitu, semua permintaan telah mengembalikan tanggapan atau transaksi telah berakhir. Koneksi yang menjadi idle dalam jangka waktu ini tetap dipertahankan.
Pengujian performa
Hasil berikut menunjukkan persentase koneksi yang tetap aktif dalam berbagai skenario O&M.
Lingkungan pengujian:
| Parameter | Value |
|---|---|
| Kluster | PolarDB for MySQL 8.0, satu node primary dan dua node read-only |
| Spesifikasi node | 4-core 16 GB (polar.mysql.x4.large) |
| Tool pengujian | Sysbench |
| Data pengujian | 20 tabel, 10.000 baris per tabel, tingkat paralelisme 20 |
Prosedur: Ukur laju keep-alive sebelum dan sesudah setiap aktivitas O&M.
Hasil:
| Scenario | Keep-alive rate | Conditions |
|---|---|---|
| Switch to a new primary node | 100% | |
| Upgrade the minor version of the database kernel engine | 100% | Does not cover database proxy minor version upgrades; those upgrades may cause network interruptions. |
| Upgrade cluster specifications | 100% | Applies only to tier-by-tier upgrades (for example, 4 cores to 8 cores). Skipping tiers—such as upgrading from 4 cores to 16 cores or higher—may cause a service interruption. |
| Add or remove nodes | 100% | If the database proxy node is downgraded during a read-only node removal, some connections may be closed. |