All Products
Search

This Product

    ApsaraDB RDS:Konfigurasikan connection pooling

    Document Center

    ApsaraDB RDS:Konfigurasikan connection pooling

    Last Updated:Jun 21, 2026

    Jika aplikasi Anda sering membuat koneksi singkat atau jumlah koneksi tinggi dan mendekati batas database MySQL, gunakan fitur connection pooling dari proksi database ApsaraDB RDS for MySQL. Fitur ini mengurangi frekuensi pembuatan koneksi baru, sehingga meminimalkan beban pada thread utama database dan menurunkan jumlah total koneksi.

    Pilih tipe connection pooling

    Proksi database ApsaraDB RDS for MySQL menyediakan connection pooling tingkat transaksi dan tingkat sesi. Anda dapat memutuskan apakah akan menggunakan connection pooling dan memilih tipe berdasarkan kasus penggunaan Anda.

    Tipe connection pool

    Kasus penggunaan

    Transaction-level connection pooling (direkomendasikan)

    Skenario dengan koneksi singkat, pembuatan koneksi yang sering, dan jumlah koneksi yang mendekati batas database MySQL.

    Bisnis Anda tidak terpengaruh oleh keterbatasan transaction-level connection pooling.

    Session-level connection pooling

    Skenario dengan koneksi singkat dan pembuatan koneksi yang sering, tetapi aplikasi terpengaruh oleh keterbatasan transaction-level connection pooling.

    Jangan gunakan connection pooling

    Skenario dengan koneksi persisten, jumlah koneksi kecil, atau connection pool di sisi aplikasi seperti Druid, DBCP, C3P0, atau HikariCP.

    Tipe connection pool

    Transaction-level connection pooling (direkomendasikan)

    Kasus penggunaan

    • Aplikasi Anda sebagian besar menggunakan koneksi singkat.

    • Koneksi dibuat secara sering.

    • Jumlah koneksi besar dan mendekati batas koneksi database MySQL.

    Manfaat

    • Mengurangi frekuensi pembentukan koneksi antara aplikasi dan database, sehingga menurunkan beban pada thread utama database MySQL.

    • Mengurangi jumlah total koneksi ke database.

    Cara kerja

    Setelah Anda mengaktifkan transaction-level connection pooling, ketika klien menginisiasi permintaan sesi, proksi database membentuk koneksi frontend dengan klien tetapi tidak langsung membuat koneksi backend ke database. Saat permintaan perlu diproses, proksi memeriksa connection pool tingkat transaksi untuk mencari koneksi backend yang tersedia.

    Catatan

    Koneksi backend dianggap tersedia jika parameter user dan dbname-nya serta beberapa nilai variabel sistem konsisten dengan permintaan tersebut.

    • Jika terdapat koneksi yang tersedia, proksi menggunakannya kembali. Setelah transaksi selesai, proksi mengembalikan koneksi tersebut ke connection pool tingkat transaksi.

    • Jika tidak ada koneksi yang tersedia, proksi membuat koneksi backend baru ke database.

    Beberapa sesi dapat berbagi satu koneksi backend. Sesi dengan transaksi aktif menempati koneksi backend, sedangkan sesi dengan transaksi tidak aktif tidak menempatinya, seperti yang ditunjukkan pada gambar berikut.

    Dengan memungkinkan satu koneksi backend menangani permintaan transaksi dari beberapa sesi secara bergantian, model ini memberikan keuntungan berikut:

    • Frekuensi koneksi berkurang: Backend mempertahankan koneksi persisten ke database, mengurangi kebutuhan untuk sering membuat koneksi baru dan menurunkan beban pada thread utama database.

    • Jumlah total koneksi lebih rendah: Beberapa sesi berbagi koneksi backend yang sama, mencegah koneksi idle mengonsumsi sumber daya dan mengurangi jumlah total koneksi ke database.

    Catatan

    Proksi database itu sendiri tidak memberlakukan batas maksimum koneksi; batas ini ditentukan oleh spesifikasi database backend.

    Keterbatasan

    • Operasi berikut mengunci koneksi hingga koneksi tersebut ditutup. Koneksi yang terkunci tidak dikembalikan ke connection pool untuk digunakan kembali.

      • Menjalankan pernyataan atau perintah PREPARE.

      • Membuat tabel temporary.

      • Memodifikasi variabel pengguna.

      • Memproses paket besar (misalnya, 16 MB atau lebih).

      • Menggunakan LOCK TABLE.

      • Menjalankan kueri multi-pernyataan.

      • Memanggil prosedur tersimpan.

    • Fungsi FOUND_ROWS, ROW_COUNT, dan LAST_INSERT_ID tidak didukung. Anda dapat memanggil fungsi-fungsi ini, tetapi hasilnya tidak dijamin benar.

      • Jika versi proksi 1.13.11 atau lebih baru, Anda dapat menggunakan perintah SELECT FOUND_ROWS() segera setelah pernyataan SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *. Namun, MySQL tidak lagi merekomendasikan penggunaan ini. Kami menyarankan Anda mengganti SELECT FOUND_ROWS() dengan SELECT COUNT(*) FROM tb1. Untuk informasi lebih lanjut, lihat FOUND_ROWS().

      • Jika versi proksi 1.13.11 atau lebih baru, Anda dapat menggunakan pernyataan SELECT LAST_INSERT_ID() segera setelah pernyataan INSERT untuk memastikan hasil kueri yang benar.

    Catatan penggunaan

    • Untuk koneksi yang memiliki pengaturan wait_timeout, pengaturan wait_timeout mungkin tidak berlaku di sisi klien karena setiap permintaan mengambil koneksi dari connection pool. Ketika periode wait_timeout berakhir, hanya koneksi backend dalam connection pool yang diputus, dan hal ini tidak menyebabkan koneksi klien terputus.

    • Kecuali untuk variabel sql_mode, character_set_server, collation_server, dan time_zone, jika aplikasi Anda bergantung pada variabel sistem tingkat sesi lainnya, klien harus secara eksplisit menjalankan pernyataan SET setelah membentuk koneksi. Jika tidak, connection pool mungkin menggunakan kembali koneksi yang variabel sistemnya telah dimodifikasi.

    • Karena koneksi mungkin digunakan kembali, Anda dapat menjalankan select connection_id() untuk menanyakan ID thread dari koneksi saat ini.

    • Karena koneksi mungkin digunakan kembali, alamat IP dan port yang ditampilkan oleh show processlist atau SQL Explorer and Audit mungkin tidak sesuai dengan alamat IP dan port aktual klien.

    • Proksi database menggabungkan hasil show processlist dari semua node dan mengembalikannya. ID thread koneksi frontend dan backend tidak dapat dipetakan. Hal ini dapat menyebabkan perintah KILL melaporkan error meskipun perintah tersebut berhasil dijalankan.

    Session-level connection pooling

    Kasus penggunaan

    • Aplikasi Anda sebagian besar menggunakan koneksi singkat.

    • Koneksi dibuat secara sering.

    Manfaat

    Mengurangi frekuensi pembentukan koneksi antara aplikasi dan database, sehingga menurunkan beban pada thread utama database MySQL.

    Cara kerja

    Koneksi frontend dan backend

    Saat klien, seperti aplikasi, membentuk koneksi dengan database, proksi database bertindak sebagai perantara. Proksi tersebut membagi koneksi menjadi koneksi frontend antara klien dan proksi database, serta koneksi backend antara proksi database dan database, seperti yang ditunjukkan pada gambar berikut.

    Proses koneksi saat connection pooling dinonaktifkan

    Jika connection pooling dinonaktifkan, proksi membuat koneksi frontend dan backend baru untuk setiap sesi.

    Cara kerja session-level connection pooling

    Saat sesi dibentuk, session-level connection pooling pertama-tama membuat koneksi frontend. Kemudian, proksi memeriksa connection pool untuk mencari koneksi backend yang tersedia.

    Catatan

    Koneksi dianggap tersedia jika parameter user, clientip, dan dbname-nya sesuai dengan permintaan tersebut.

    • Jika terdapat koneksi yang tersedia, koneksi tersebut digunakan kembali.

    • Jika tidak ada koneksi yang tersedia, koneksi backend baru dibentuk dengan database.

    Saat sesi berakhir, proksi memutus koneksi frontend dan mengembalikan koneksi backend ke pool. Hal ini memungkinkan koneksi backend digunakan kembali oleh sesi baru, sehingga mengurangi beban pada thread utama database.

    Dengan session-level connection pooling, satu sesi menempati satu koneksi backend hingga sesi tersebut berakhir. Baru setelah itu koneksi backend dilepaskan ke pool, seperti yang ditunjukkan pada gambar berikut.

    Keterbatasan

    Tidak ada.

    Catatan penggunaan

    Sebelum sesi berakhir, koneksi backend-nya tidak dapat digunakan oleh sesi lain, bahkan jika koneksi tersebut idle dan tidak memiliki transaksi untuk diproses. Oleh karena itu, session-level connection pooling tidak mengurangi jumlah total koneksi database.

    Konfigurasikan connection pooling

    Prasyarat

    Proksi database diaktifkan.

    Catatan penggunaan

    • Fitur connection pooling tidak mendukung pemberian izin berbeda untuk akun yang sama berdasarkan alamat IP yang berbeda. Jika Anda mengonfigurasi izin database atau tabel berbeda untuk akun yang sama pada alamat IP berbeda (misalnya, user@192.xx.xx.1 memiliki izin untuk database_a, tetapi user@192.xx.xx.2 tidak), mengaktifkan connection pooling dapat menyebabkan error izin saat koneksi digunakan kembali.

    • Jika aplikasi Anda sudah menggunakan connection pool di sisi klien, Anda tidak perlu mengaktifkan connection pooling proksi database.

    • Connection pooling tidak dapat mengatasi penumpukan koneksi yang disebabkan oleh banyak kueri SQL lambat. Kami menyarankan Anda mengoptimalkan kueri SQL atau mencari penyebab kelambatan pada instans MySQL.

    • Jika versi proksi lebih awal dari 2.9.1, Anda tidak dapat mengonfigurasi connection pooling untuk titik akhir proksi read-only. Jika versi proksi 2.9.1 atau lebih baru, Anda dapat mengonfigurasi connection pooling untuk titik akhir proksi baik read/write maupun read-only.

    Prosedur

    1. Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS tersebut dan klik ID-nya.

    2. Di panel navigasi kiri, klik Database Proxy.

    3. Di bagian Connection Information, aktifkan connection pooling dengan salah satu metode berikut:

      Catatan

      • Connection pooling dinonaktifkan secara default.

      • Setelah Anda mengubah tipe connection pool, perubahan tersebut hanya berlaku untuk koneksi baru.

      • Metode 1: Arahkan kursor ke ikon image.png di sebelah kanan ID titik akhir proksi. Di kotak dialog yang muncul, klik Enable Transaction-level Connection Pooling atau Enable Session-level Connection Pooling, lalu klik OK di kotak dialog konfirmasi.

      • Metode 2: Di kolom Actions untuk titik akhir proksi yang dituju, klik Modify Configuration. Di kotak dialog yang muncul, pilih tipe connection pool yang diinginkan di samping Connection Pooling untuk mengaktifkannya.

        Catatan

        Jika tipe connection pool sudah diaktifkan, Anda dapat memilih tipe berbeda untuk mengubahnya.

        Di kotak dialog ini, Anda juga dapat mengonfigurasi Read/write attribute (opsi: Read/write (read/write splitting) atau Read-only), Latency threshold (rentang: 0 hingga 3.600 detik), Transaction splitting (diaktifkan atau dinonaktifkan), dan Read weight allocation (opsi: System-assigned atau bobot kustom).

    Referensi API

    API

    Deskripsi

    DescribeDBProxy

    Menanyakan detail proksi database untuk instans RDS.

    DescribeDBProxyEndpoint

    Menanyakan informasi mengenai titik akhir proksi instans RDS.

    ModifyDBProxyEndpoint

    Memodifikasi konfigurasi titik akhir proksi untuk instans RDS.

    Konsep penting

    • short-lived connection: Koneksi yang hanya dipertahankan dalam waktu singkat. Misalnya, aplikasi PHP menutup koneksi setelah menjalankan kueri sederhana. Pendekatan ini menghindari pendudukan koneksi dalam waktu lama tetapi memerlukan pembentukan koneksi baru untuk setiap permintaan, sehingga meningkatkan beban pada thread utama database.

    • persistent connection: Koneksi yang dipertahankan dalam waktu lama. Misalnya, server web atau server aplikasi membuka banyak koneksi ke server MySQL dan mempertahankannya hingga klien berhenti. Hal ini mengurangi beban thread utama dengan meminimalkan permintaan koneksi baru, tetapi menduduki saluran koneksi dalam waktu lama.

    FAQ

    Q: Pada jumlah koneksi berapa saya harus mengaktifkan connection pooling?

    A: Kami menyarankan mengaktifkan transaction-level connection pooling saat jumlah koneksi mendekati batas MySQL.

    Q: Berapa lama koneksi disimpan dalam connection pool?

    A: 10 detik.

    Q: Apakah penggunaan connection pooling memengaruhi performa instans?

    A: Pada skenario dengan koneksi singkat, mengaktifkan connection pooling dapat meningkatkan performa instans sekitar 10%.

    Q: Apa perbedaan fungsional antara transaction-level dan session-level connection pooling?

    A: Transaction-level connection pooling mengurangi beban thread utama dan jumlah total koneksi. Session-level connection pooling hanya mengurangi beban thread utama.

    Q: Bagaimana perbedaan cara kerja antara transaction-level dan session-level connection pooling?

    A:

    Tipe kumpulan koneksi

    Session sharing

    Waktu pengambilan

    Waktu pengembalian

    Pemetaan koneksi

    Transaction-level

    Ya

    Saat transaksi diproses

    Setelah transaksi diproses (sesi mungkin masih aktif)

    N:1

    Session-level

    Tidak

    Saat sesi dibentuk

    Saat sesi berakhir

    N:N

    Q: Koneksi proksi database terputus. Apakah ini karena aplikasi dan proksi database sama-sama menggunakan connection pooling?

    A: Koneksi dapat terputus karena berbagai alasan, tidak selalu karena aplikasi dan proksi sama-sama menggunakan connection pooling. Penyebab utamanya tergantung pada workload dan konfigurasi spesifik Anda.