All Products
Search

This Product

    PolarDB:Kolam koneksi tingkat transaksi

    Document Center

    PolarDB:Kolam koneksi tingkat transaksi

    Last Updated:Aug 28, 2026

    Saat aplikasi Anda mempertahankan ribuan koneksi bersamaan atau membuat koneksi dengan frekuensi tinggi, PolarDB for PostgreSQL (Compatible with Oracle) mengalami tekanan: setiap koneksi memerlukan proses backend khusus, dan overhead proses tersebut menurunkan performa. Fitur pooling koneksi tingkat transaksi mengarahkan seluruh lalu lintas klien melalui PolarProxy, sehingga beberapa koneksi frontend dapat berbagi satu koneksi backend. Hal ini secara signifikan mengurangi jumlah proses backend dan meningkatkan throughput database.

    Prasyarat

    Sebelum memulai, pastikan Anda telah memiliki:

    • PolarProxy V2.3.46 atau yang lebih baru

    Cara kerja

    PolarProxy berada di antara aplikasi Anda dan database backend. Alih-alih membuat koneksi backend untuk setiap koneksi klien, PolarProxy mempertahankan kolam koneksi backend dan menggunakannya kembali di berbagai transaksi:

    1. Klien terhubung ke PolarProxy.

    2. PolarProxy memeriksa kolam untuk mencari koneksi backend idle yang sesuai dengan pengaturan user, dbname, dan variabel sistem dari permintaan tersebut.

    3. Jika ditemukan koneksi idle yang cocok, PolarProxy menggunakannya kembali. Jika tidak, PolarProxy membuka koneksi backend baru.

    4. Setelah transaksi di-commit, koneksi dikembalikan ke kolam dan tersedia untuk permintaan berikutnya.

    Multiplexing ini memungkinkan Anda mempertahankan ribuan koneksi dari klien ke PolarProxy, sementara PolarProxy hanya membuka puluhan hingga ratusan koneksi ke database backend.

    PolarProxy tidak membatasi jumlah koneksi klien. Jumlah maksimum koneksi ke titik akhir kluster PolarDB bergantung pada spesifikasi node komputasi database backend. Saat pooling koneksi tingkat transaksi dinonaktifkan, sistem membuat koneksi khusus pada node primary dan setiap node read-only untuk setiap permintaan klien.

    Kapan menggunakan pooling koneksi tingkat transaksi

    Skenario

    Gunakan connection pooling?

    Alasan

    Puluhan ribu koneksi bersamaan

    Yes

    Pooling secara signifikan mengurangi jumlah koneksi backend

    Workload serverless yang diskalakan secara horizontal

    Yes

    Jumlah koneksi bertambah sebanding dengan skala server; pooling menyerap peningkatan tersebut

    Jumlah koneksi kecil, sebagian besar merupakan koneksi panjang

    No

    Koneksi panjang sudah mendistribusikan overhead koneksi; pooling tidak memberikan manfaat tambahan

    Aplikasi sudah menggunakan connection pool sendiri

    No

    Pool sisi klien yang mapan sudah mencapai efek yang sama

    Untuk skenario "Yes" di atas, aktifkan pooling koneksi tingkat transaksi hanya jika layanan Anda tidak berjalan dalam skenario yang dijelaskan di bagian Connection pinning di bawah.

    Aktifkan pooling koneksi tingkat transaksi

    1. Login ke Konsol PolarDB.

    2. Klik Clusters di panel navigasi kiri. Di pojok kiri atas halaman Clusters, pilih wilayah tempat kluster berada.

    3. Temukan kluster dan klik ID kluster tersebut.

    4. Di bagian URL, klik Configuration.

    5. Di bagian Connection Pool, atur Connection Pool menjadi Transaction-level.

    6. Klik OK.

    Nonaktifkan pooling koneksi tingkat transaksi

    1. Login ke Konsol PolarDB.

    2. Klik Clusters di panel navigasi kiri. Di pojok kiri atas halaman Clusters, pilih wilayah tempat kluster berada.

    3. Temukan kluster dan klik ID kluster tersebut.

    4. Di bagian URL, klik Configuration.

    5. Di bagian Connection Pool, atur Connection Pool menjadi Disable.

    6. Klik OK.

    Connection pinning

    Beberapa operasi menyebabkan koneksi backend menjadi pinned — terkunci ke sesi klien saat ini hingga sesi tersebut ditutup. Koneksi yang dipinned tidak dikembalikan ke kolam dan tidak dapat digunakan kembali oleh klien lain.

    Jika workload Anda sering memicu pinning, kolam tidak dapat melakukan multiplexing koneksi secara efektif. Tinjau operasi di bawah ini dan pertimbangkan untuk menggunakan koneksi langsung sebagai gantinya.

    Operasi

    Mengapa ini menyebabkan pinning

    Menjalankan pernyataan PREPARE

    Pernyataan yang dipersiapkan (prepared statement) terikat ke proses backend tertentu

    Memproses paket yang lebih besar dari 16 MB

    Penanganan paket besar memerlukan status koneksi khusus

    Masuk ke mode copy

    COPY mengalirkan data secara kontinu; koneksi tidak dapat dilepas di tengah aliran

    Masuk ke mode flush

    Mode flush memerlukan status koneksi persisten antar pemanggilan

    Membuat tabel temporary, sequence, atau view

    Objek-objek ini terikat ke sesi backend tertentu

    Menggunakan transaksi

    Transaksi yang terbuka mempertahankan koneksi hingga COMMIT atau ROLLBACK

    Mendeklarasikan cursor

    Set hasil cursor berada di proses backend yang membukanya

    Menentukan parameter koneksi options saat membuat koneksi

    Parameter options tidak kompatibel dengan penggunaan ulang koneksi backend, sehingga koneksi tersebut dipinned

    Karena koneksi backend dibagikan antar klien, pid yang dikembalikan oleh SELECT pg_backend_pid() dapat berubah antar transaksi. Demikian pula, alamat IP dan port klien yang ditampilkan di pg_stat_activity dan SQL Explorer mungkin berbeda dari alamat klien sebenarnya.