All Products
Search

This Product

    PolarDB:Penyeimbangan beban

    Document Center

    PolarDB:Penyeimbangan beban

    Last Updated:Jun 21, 2026

    PolarDB mendukung dua kebijakan penyeimbangan beban untuk mendistribusikan beban di beberapa node read-only: Connections-based Load Balancing dan Active Request-based Load Balancing.

    Kebijakan penyeimbangan beban

    • Connections-based Load Balancing: Kebijakan ini ideal untuk skenario berkinerja tinggi yang tidak memerlukan fitur lanjutan seperti tingkat konsistensi atau pemisahan transaksi.

    • Active Request-based Load Balancing: Permintaan baca secara otomatis dirutekan di antara beberapa node read-only dalam satu titik akhir kluster berdasarkan jumlah permintaan aktif. Kebijakan ini mendukung fitur lanjutan seperti tingkat konsistensi, pemisahan transaksi, dan persistensi koneksi, serta menyeimbangkan beban berdasarkan status real-time setiap node.

    Catatan

    PolarDB titik akhir kluster dalam mode Read-only mendukung kedua kebijakan Connections-based Load Balancing dan Active Request-based Load Balancing. Titik akhir kluster dalam mode Read/Write (Automatic Read/Write Splitting) hanya mendukung Active Request-based Load Balancing.

    Tabel berikut membandingkan kedua kebijakan tersebut.

    Nama kebijakan

    Perbedaan

    Kesamaan

    Connections-based Load Balancing

    • Aplikasi membuat satu koneksi dengan hanya satu node read-only dalam titik akhir kluster. Jumlah total koneksi yang dapat dibuat oleh aplikasi sama dengan jumlah maksimum koneksi dari semua node read-only dalam titik akhir kluster.

    • Ketika sebuah node read-only dihapus dari titik akhir terkait, koneksi pengguna ke node tersebut diputus.

    • Fitur lanjutan seperti tingkat konsistensi, pemisahan transaksi, persistensi koneksi, dan perutean otomatis penyimpanan baris/penyimpanan kolom tidak didukung.

    • Kinerjanya lebih baik karena hanya menangani pembentukan koneksi dan kurang terlibat dalam distribusi beban.

    Untuk titik akhir kluster dalam mode Read-only, tidak ada permintaan yang diteruskan ke node primer, terlepas dari kebijakan penyeimbangan beban yang digunakan.

    Active Request-based Load Balancing

    • Aplikasi membuat satu koneksi dengan semua node dalam titik akhir kluster. Jumlah total koneksi yang dapat dibuat oleh aplikasi sama dengan nilai minimum dari jumlah koneksi maksimum di semua node dalam titik akhir kluster.

    • Mendukung fitur lanjutan seperti tingkat konsistensi, pemisahan transaksi, persistensi koneksi, dan perutean otomatis penyimpanan baris/penyimpanan kolom.

    • Kinerjanya sedikit lebih rendah karena harus mengurai dan merutekan setiap permintaan.

    • Memberikan penyeimbangan beban yang lebih unggul, mendistribusikan trafik secara efektif bahkan ketika spesifikasi node berbeda-beda.

    Node primer menerima permintaan baca

    Jika Anda mengatur Primary Node Accepts Read Requests ke No, PolarProxy tidak lagi mengirim permintaan baca biasa ke node primer. Namun, permintaan baca dalam transaksi yang memerlukan konsistensi tetap dikirim ke node primer untuk memenuhi kebutuhan bisnis. Selain itu, jika semua node read-only gagal, permintaan baca juga dikirim ke node primer. Jika bisnis Anda memiliki persyaratan konsistensi yang rendah, Anda dapat mengatur tingkat konsistensi menjadi eventual consistency untuk mengurangi permintaan baca ke node primer. Anda juga dapat menggunakan fitur pemisahan transaksi untuk mengurangi permintaan baca yang dikirim ke node primer sebelum transaksi sebenarnya dimulai. Permintaan broadcast, seperti SET atau PREPARE, tetap dikirim ke node primer.

    Catatan

    • Anda dapat mengonfigurasi pengaturan Primary Node Accepts Read Requests hanya ketika Read/Write diatur ke Read/Write (Automatic Read/Write Splitting). Untuk informasi tentang cara mengubah pengaturan Primary Node Accepts Read Requests, lihat Configure PolarProxy.

    • Jika versi PolarProxy Anda adalah 1.x.x atau 2.5.1 atau lebih baru, perubahan pada pengaturan Primary Node Accepts Read Requests langsung berlaku.

    • Jika versi PolarProxy Anda adalah 2.x.x dan lebih lama dari 2.5.1, perubahan pada pengaturan Primary Node Accepts Read Requests hanya berlaku setelah Anda membuat ulang koneksi persisten. Untuk koneksi singkat, perubahan langsung berlaku.

    Pemisahan transaksi

    Ketika Anda menggunakan titik akhir kluster PolarDB dalam mode Read/Write (Automatic Read/Write Splitting), PolarProxy mendistribusikan permintaan baca dan tulis ke node primer dan node read-only. Untuk memastikan konsistensi transaksional dalam satu sesi, PolarProxy mengirim semua permintaan dalam transaksi ke node primer. Sebagai contoh, beberapa driver klien database, seperti JDBC, membungkus permintaan dalam transaksi secara default. Akibatnya, semua permintaan aplikasi dikirim ke node primer, yang dapat menyebabkan beban tinggi pada node primer sementara node read-only kurang dimanfaatkan, seperti yang ditunjukkan pada gambar berikut:

    Untuk mengatasi masalah ini, PolarDB menyediakan fitur pemisahan transaksi pada tingkat isolasi Read Committed. Fitur ini mengirim permintaan baca dalam transaksi ke node read-only untuk mengurangi beban pada node primer, sekaligus memastikan konsistensi baca/tulis bagi layanan Anda. Anda dapat mengalihkan tekanan baca dari node primer ke node read-only dan meningkatkan stabilitas node primer tanpa mengubah kode atau konfigurasi aplikasi Anda. Untuk petunjuk detail tentang cara mengaktifkan pemisahan transaksi, lihat Configure PolarProxy.

    PolarDB for MySQL menyediakan dua tingkat pemisahan transaksi: Read request splitting before first write request (default, fitur pemisahan transaksi asli) dan Full transaction splitting (read request splitting before and after first write request).

    • Read request splitting before first write request

      PolarProxy mengirim permintaan baca yang mendahului permintaan tulis pertama dalam transaksi ke node read-only, yang mengurangi beban pada node primer.

    • Full transaction splitting (read request splitting before and after first write request)

      Dengan pemisahan permintaan baca sebelum permintaan tulis pertama, permintaan baca yang terjadi setelah operasi tulis tetap dirutekan ke node primer, yang dapat menyebabkan beban tidak seimbang. Untuk sepenuhnya mengatasi masalah penyeimbangan beban yang disebabkan oleh transaksi, PolarDB for MySQL memperkenalkan full transaction splitting. Fitur ini memungkinkan semua operasi baca dalam transaksi dirutekan ke node read-only sambil memastikan hasil yang benar, sehingga lebih jauh mengurangi tekanan pada node primer.

      Permintaan baca-setelah-tulis dapat dirutekan ke node read-only hanya jika data dari operasi tulis sebelumnya dalam transaksi telah disinkronkan ke node tersebut. Jika Anda telah mengonfigurasi session consistency, PolarProxy terlebih dahulu memeriksa apakah node read-only untuk sesi saat ini telah menyinkronkan tulisan sebelumnya sebelum merutekan permintaan baca-setelah-tulis. Jika sudah, permintaan dirutekan ke node read-only; jika belum, permintaan dirutekan ke node primer. Demikian pula, jika Anda telah mengonfigurasi global consistency, PolarProxy memeriksa apakah transaksi dari semua sesi saat ini telah disinkronkan ke node read-only. Jika sudah, permintaan dirutekan ke sana; jika belum, permintaan dirutekan ke node primer. Full transaction splitting tidak mendukung eventual consistency.

      Versi dan batasan

      Untuk menggunakan fitur full transaction splitting, kluster PolarDB for MySQL Anda harus memenuhi persyaratan berikut:

      • Versi engine:

        • PolarDB for MySQL 5.6, revisi 5.6.1.0.29 atau lebih baru.

        • PolarDB for MySQL 5.7, revisi 5.7.1.0.9 atau lebih baru.

        • PolarDB for MySQL 8.0.1, revisi 8.0.1.1.18 atau lebih baru.

        • PolarDB for MySQL 8.0.2, semua revisi.

      • Parameter mesin:

        Parameter loose_query_cache_type harus diatur ke OFF. PolarDB for MySQL 5.6, 5.7, dan 8.0.1 menggunakan OFF secara default. Versi 8.0.2 menggunakan ON secara default. Mengubah parameter ini memerlukan restart kluster PolarDB.

      Catatan

      • Pemisahan transaksi hanya didukung untuk sesi pada tingkat isolasi Read Committed dan diaktifkan secara default.

      • Karena batasan konsistensi baca/tulis, permintaan baca tidak dirutekan ke node read-only jika tingkat konsistensinya tidak memenuhi persyaratan.

      • Jika versi PolarProxy Anda lebih lama dari 2.4.14, hanya read request splitting before first write request yang didukung. Full transaction splitting tidak didukung.

      • Jika versi PolarProxy Anda 2.4.14 atau lebih baru dan pemisahan transaksi dikonfigurasi untuk full transaction splitting, Anda harus membuat ulang koneksi persisten agar perubahan berlaku. Untuk koneksi singkat, perubahan langsung berlaku.

    • Nonaktifkan pemisahan transaksi

      Ketika pemisahan transaksi dinonaktifkan, semua permintaan dalam transaksi dirutekan ke node primer.

    Penyeimbangan beban berbasis bobot

    Secara default, PolarProxy PolarDB for MySQL merutekan permintaan ke node dengan jumlah permintaan aktif (concurrent) paling sedikit. Kebijakan ini umumnya menyeimbangkan trafik di node backend berdasarkan bebannya. Kebijakan ini juga berkinerja baik ketika node backend memiliki spesifikasi berbeda-beda. Namun, beban kerja produksi dan persyaratan distribusi trafik bervariasi.

    Untuk lebih memenuhi kebutuhan ini, PolarDB for MySQL memperkenalkan penyeimbangan beban berbasis bobot. Anda dapat mengonfigurasi bobot berbeda untuk setiap node. Selama proses perutean, baik bobot maupun jumlah permintaan concurrent digunakan sebagai kriteria untuk menyesuaikan keputusan perutean akhir secara dinamis. Saat ini, bobot dapat dikonfigurasi pada dua tingkat berikut:

    • Dimensi global

      Konfigurasi ini berlaku untuk semua titik akhir.

    • Dimensi titik akhir

      Bobot pada dimensi titik akhir hanya berlaku untuk penyeimbangan beban titik akhir tersebut dan menggantikan pengaturan global. Misalnya, jika Anda terlebih dahulu mengonfigurasi bobot pada dimensi global lalu mengonfigurasi bobot terpisah untuk titik akhir tertentu, penyeimbangan beban untuk titik akhir tersebut akan didasarkan pada konfigurasi tingkat titik akhir.

    Notes

    • Fitur ini memerlukan PolarProxy 2.8.3 atau lebih baru.

    • Karena kebijakan perutean mempertimbangkan beban node saat ini dan bobot yang ditentukan pengguna, rasio trafik keseluruhan mungkin sedikit menyimpang dari rasio yang dikonfigurasi. Seiring waktu, rasio tersebut akan secara bertahap konvergen menuju rasio yang dikonfigurasi.

    • Kluster Serverless tidak mendukung konfigurasi bobot pada dimensi titik akhir.

    Cara kerja

    Selama proses perutean permintaan, bobot akhir setiap node dihitung secara dinamis berdasarkan bobot yang dikonfigurasi dan jumlah permintaan concurrent saat ini pada node tersebut. Rumus sederhananya adalah sebagai berikut:

    Bobot dinamis = Bobot yang dikonfigurasi / Jumlah permintaan serentak

    Semakin tinggi bobot dinamis, semakin tinggi prioritas node tersebut. Kebijakan penyeimbangan beban bobot dinamis menyediakan metode perutean yang fleksibel. Dalam praktiknya, trafik secara bertahap bergeser sesuai dengan bobot yang dikonfigurasi, yang mungkin memerlukan waktu lebih lama dibanding pendekatan weighted round-robin sederhana.

    Prosedur

    Catatan

    • Pada awalnya, setiap node backend memiliki bobot default yang sama yaitu 1.

    • Kisaran nilai bobot yang dapat dikonfigurasi adalah 0 hingga 100.

    • Ketika bobot diatur ke 0, PolarProxy tidak merutekan permintaan ke node tersebut dalam kondisi normal. Node tersebut hanya dipilih jika semua node lain tidak tersedia.

    • Jika kluster hanya memiliki satu node penyimpanan kolom read-only, bobotnya dapat diabaikan. Jika kluster memiliki beberapa node penyimpanan kolom read-only, permintaan penyimpanan kolom diseimbangkan berdasarkan bobot node-node tersebut.

    Konfigurasi bobot pada dimensi global

    1. Masuk ke Konsol PolarDB.

    2. Di pojok kiri atas, pilih wilayah tempat kluster ditempatkan.

    3. Temukan kluster target dan klik ID-nya.

    4. Pada halaman Basic Information, di bagian Standard Enterprise Edition atau Dedicated Enterprise Edition, klik Database Proxy Settings.

    5. Pada kotak dialog Database Proxy Settings, atur bobot untuk setiap node sesuai kebutuhan bisnis Anda.

      Kotak dialog menampilkan Role setiap node (node primer atau node read-only) dan kotak input Weight. Pesan di bagian atas menunjukkan bahwa keputusan perutean disesuaikan secara dinamis berdasarkan bobot dan permintaan concurrent. Setelah selesai mengatur bobot, klik OK.

    6. Setelah mengonfigurasi bobot, klik OK.

    Konfigurasi bobot pada dimensi titik akhir

    1. Masuk ke Konsol PolarDB.

    2. Di pojok kiri atas, pilih wilayah tempat kluster ditempatkan.

    3. Temukan kluster target dan klik ID-nya.

    4. Pada halaman Basic Information, di bagian Standard Enterprise Edition atau Dedicated Enterprise Edition, klik Configure di pojok kanan atas titik akhir kluster atau titik akhir kustom.

    5. Pada halaman Modify Endpoint Settings, di area node layanan, aktifkan Configure Node Weight dan atur bobot untuk setiap node.

      Pindahkan node target, seperti node penyimpanan kolom read-only, dari daftar Available Nodes ke daftar Selected Nodes. Lalu, atur bobot untuk node yang dipilih, misalnya 1, dan klik OK.

    6. Setelah mengatur bobot, klik OK.

    Data uji

    Berikut ini menunjukkan data uji aktual setelah mengonfigurasi bobot node.

    Rasio bobot tiga node yang digunakan dalam uji adalah 1:2:3 (node primer memiliki bobot 1). Hasil uji stres sesuai ekspektasi (menggunakan suite uji Sysbench oltp_read_only).

    456789

    Catatan

    Dua node internal, pi-bp1d1mtcobuzv** dan pcbp14vvpolardbma23957**, tidak terlibat dalam perutean, sehingga metriknya dapat diabaikan.

    Koneksi sesuai permintaan

    Latar belakang

    Untuk titik akhir yang menggunakan Active Request-based Load Balancing, PolarProxy secara default membuat koneksi penuh. Setelah sesi klien dibuat melalui PolarProxy, PolarProxy membuat sesi (koneksi) dengan semua node database dalam titik akhir tersebut, menciptakan hubungan koneksi 1:N. Permintaan baca normal dalam sesi ini dirutekan ke berbagai node database berdasarkan beban aktifnya saat ini, sedangkan permintaan broadcast (seperti pernyataan SET) dirutekan ke semua node database. Ketika terdapat banyak node database, efisiensi keseluruhan turun signifikan karena overhead pembentukan koneksi dan broadcasting.

    Cara kerja

    Dengan koneksi sesuai permintaan, PolarProxy hanya membuat koneksi dengan database backend sesuai kebutuhan. Fitur ini meminimalkan jumlah koneksi backend sambil memenuhi persyaratan konsistensi dan beban baca/tulis. Hal ini mengurangi overhead database yang disebabkan oleh koneksi proxy dan eksekusi broadcast. Dalam kebanyakan kasus, satu sesi membuat koneksi dengan paling banyak satu node primer dan satu node read-only (dengan asumsi eventual consistency). Hal ini dapat meningkatkan kinerja secara signifikan untuk koneksi singkat atau beban kerja dengan banyak pernyataan broadcast.

    Seperti yang ditunjukkan pada gambar di atas, asumsikan kluster PolarDB memiliki satu node primer (RW) dan tiga node read-only (RO). Jika konsistensi bukan faktor yang dipertimbangkan, efisiensi perutean permintaan dan pembacaan data dalam tiga skenario berikut adalah sebagai berikut:

    • Koneksi penuh

      Satu sesi pengguna melalui PolarProxy membuat koneksi dengan keempat node database, dan pernyataan broadcast dirutekan ke keempat node tersebut.

    • Koneksi sesuai permintaan, sesi read-only

      Satu sesi pengguna melalui PolarProxy hanya membuat koneksi dengan satu node RO. Permintaan baca (termasuk broadcast) hanya dirutekan ke satu node RO ini, sehingga secara signifikan meningkatkan efisiensi pembacaan data.

    • Koneksi sesuai permintaan, sesi baca/tulis

      Satu sesi pengguna melalui PolarProxy hanya membuat koneksi dengan satu node RO dan satu node RW. Permintaan broadcast hanya dirutekan ke dua node database ini, yang juga secara signifikan meningkatkan efisiensi pembacaan data.

    Kasus penggunaan

    • Kluster dengan banyak node RO.

    • Koneksi singkat.

    • Skenario dengan banyak pernyataan broadcast (misalnya, dalam skenario koneksi singkat PHP, pernyataan pertama sesi sering kali mirip dengan set names utf8mb4).

    • Beban kerja dengan banyak kueri yang menggunakan pernyataan PREPARE singkat.

    Batasan

    • Diperlukan PolarProxy 2.8.34 atau lebih baru. Untuk petunjuk cara memeriksa versi PolarProxy kluster Anda, lihat Check the version number.

    • Ketika Anda menggunakan SHOW PROCESSLISTS untuk melihat jumlah koneksi database, hasilnya mungkin tidak menampilkan jumlah total koneksi ke semua database.

    • Ketika Anda menggunakan perintah KILL untuk menghentikan koneksi tertentu, perintah tersebut mungkin tidak menghentikan koneksi yang ditentukan di semua database.

    Uji kinerja

    Lingkungan uji

    • Node database: satu node baca/tulis (RW), tujuh node read-only (RO)

    • SQL yang digunakan untuk pengujian: SET NAMES utf8mb4, SELECT 1

    • Alat uji: Sysbench, dengan jumlah koneksi concurrent yang sama untuk setiap pengujian

    • Skenario uji: Pengujian mencakup tiga skenario: tanpa connection pool, dengan connection pool tingkat sesi, dan dengan connection pool tingkat transaksi. Setiap pengujian dibagi menjadi dua bagian: separuh pertama tanpa mengaktifkan koneksi sesuai permintaan, dan separuh kedua dengan koneksi sesuai permintaan diaktifkan.

    Hasil uji

    • Hasil uji kinerja untuk skenario tanpa connection pool:

      • Gambar di bawah menunjukkan konsumsi CPU node database. Setelah mengaktifkan koneksi sesuai permintaan, konsumsi CPU database turun lebih dari 60%:

        不打开连接池.png

      • Gambar di bawah menunjukkan perubahan jumlah total koneksi ke node database. Setelah mengaktifkan koneksi sesuai permintaan, jumlah total koneksi turun lebih dari 80%:

        总连接数.png

      • Gambar di bawah menunjukkan perubahan QPS keseluruhan. Setelah mengaktifkan koneksi sesuai permintaan, QPS keseluruhan meningkat 35%:

        QPS.png

    • Hasil uji kinerja untuk skenario connection pool tingkat sesi:

      • Gambar di bawah menunjukkan konsumsi CPU node database. Setelah mengaktifkan koneksi sesuai permintaan, konsumsi CPU database turun lebih dari 50% hingga 60%:

        会话级_CPU消耗.png

      • Gambar di bawah menunjukkan perubahan jumlah total koneksi ke node database. Setelah mengaktifkan koneksi sesuai permintaan, jumlah total koneksi turun 60%:

        会话级_总连接数.png

      • Gambar di bawah menunjukkan perubahan QPS keseluruhan. Setelah mengaktifkan koneksi sesuai permintaan, QPS meningkat 30%:

        会话级_QPS.png

    • Hasil uji kinerja untuk skenario connection pool tingkat transaksi:

      • Gambar di bawah menunjukkan konsumsi CPU node database. Setelah mengaktifkan koneksi sesuai permintaan, konsumsi CPU database turun 60%:

        事务级_CPU.png

      • Gambar di bawah menunjukkan perubahan jumlah total koneksi ke node database. Setelah mengaktifkan koneksi sesuai permintaan, jumlah total koneksi turun 50%:

        事务级_CPU.png

      • Gambar di bawah menunjukkan perubahan QPS keseluruhan. Setelah mengaktifkan koneksi sesuai permintaan, QPS meningkat 260%:

        事务级_QPS.png