Pedoman konfigurasi

Bagian ini menjelaskan pengaturan yang tersedia di RDS Proxy dan memberikan praktik terbaik untuk menyelaraskan konfigurasi di seluruh tumpukan aplikasi. Ini adalah panduan gabungan untuk menggunakan RDS Proxy dengan Amazon RDS dan Amazon Aurora. RDS-specific dan Aurora-specific catatan dipanggil jika berlaku.

Kecuali disebutkan lain, istilah “database” atau “target” mengacu pada cluster Aurora, cluster Amazon RDS Multi-AZ DB, atau instans Amazon RDS.

Pengaturan untuk RDS Proxy

MaxConnectionsPercent

Nilai minimum	Nilai maksimum	Nilai default
lebih rendah dari (1, MaxIdleConnectionsPercent)	100	100

Untuk informasi selengkapnya, lihat MaxConnectionsPercent.

Pengaturan ini membatasi jumlah koneksi yang dapat dibuat oleh RDS Proxy dengan basis data target, sebagai persentase dari jumlah maksimum koneksi yang diizinkan oleh database. Proxy membuka koneksi back-end sesuai kebutuhan, sehingga jumlah koneksi sebenarnya pada waktu tertentu mungkin lebih rendah dari maksimum yang dikonfigurasi.

Mengingat bahwa MaxConnectionsPercent pengaturan adalah persentase dari batas koneksi database, ukuran kumpulan koneksi proxy secara otomatis mengikuti konfigurasi database. Ini berarti Anda tidak perlu mengkonfigurasi ulang proxy Anda setiap kali Anda mengubah ukuran instance database Anda atau membuat perubahan konfigurasi. Ini juga berarti Anda perlu mengetahui skenario ketika pengaturan database mungkin berubah, baik secara implisit maupun eksplisit:

• Jika Anda tidak secara eksplisit menetapkan batas koneksi (seperti max_connections parameter) dalam grup parameter database Anda, Amazon RDS dan Aurora menghitungnya secara otomatis berdasarkan kelas instance database. Akibatnya, batas koneksi implisit dapat berubah saat Anda menskalakan instance database Anda, sehingga memengaruhi ukuran kumpulan maksimum dalam proxy. Untuk informasi selengkapnya, lihat Jumlah maksimum koneksi database di Panduan Pengguna Amazon RDS, Koneksi maksimum ke instans DB MySQL Aurora, dan Koneksi maksimum ke instans DB PostgreSQL Aurora di Panduan Pengguna Amazon Aurora.

• Instans database Aurora Serverless v2 menentukan batas koneksi mereka berdasarkan konfigurasi ACU maksimum database. Untuk detailnya, lihat Koneksi maksimum untuk Aurora Tanpa Server v2 di Panduan Pengguna Amazon Aurora.

Praktik terbaik:

• Pengaturan default 100 persen cocok untuk database yang menerima semua lalu lintas mereka melalui proxy dan tidak memerlukan ruang kepala untuk akses administratif atau klien lain.

• Kurangi pengaturan ini ketika database juga menerima lalu lintas langsung dari aplikasi (melewati proxy) dan Anda tidak ingin proxy menggunakan semua koneksi, atau ketika Anda ingin menyisihkan sejumlah koneksi untuk tujuan lain seperti akses langsung oleh administrator database.

• Saat menggunakan RDS Proxy dengan cluster Aurora Global Database dan Write Forwarding diaktifkan, kurangi nilai proxy Anda dengan kuota yang MaxConnectionsPercent dialokasikan untuk penerusan tulis. Untuk detailnya, lihat parameter konfigurasi untuk penerusan tulis di Aurora MySQL dan Aurora PostgreSQL di Panduan Pengguna Amazon Aurora. Rekomendasi ini berlaku apakah proxy melayani klaster di Wilayah primer atau sekunder dari database global. Cluster sekunder dapat dipromosikan ke peran utama, jadi ini adalah praktik yang baik untuk menjaga pengaturan proxy konsisten di seluruh topologi global. Anda dapat menggunakan pengaturan asimetris untuk proxy yang melayani wilayah primer versus sekunder, tetapi Anda harus menyesuaikan pengaturan tersebut setelah setiap failover atau peralihan global.

• Jika target melayani beberapa proxy, nilai gabungan dari MaxConnectionsPercent semua proxy tersebut tidak boleh melebihi 100 sehingga database tidak menjadi oversubscribed. Sebaiknya gunakan satu proxy per target untuk menyederhanakan konfigurasi dan manajemen. Secara khusus, Anda tidak perlu menggunakan beberapa proxy per database untuk redundansi. Untuk informasi selengkapnya, lihat Menggunakan beberapa proxy dengan satu target.

Baik Anda menggunakan MaxConnectionsPercent pengaturan default atau nilai khusus, pertahankan setidaknya 30% ruang kepala antara jumlah koneksi yang diizinkan dan jumlah maksimum koneksi klien yang diharapkan selama periode puncak. Contoh:

• Jika Anda yakin proxy akan membutuhkan hingga 50% dari batas koneksi yang dikonfigurasi untuk database, gunakan MaxConnectionsPercent pengaturan setidaknya1.3 * 50% = 65%.

• Saat menggunakan MaxConnectionsPercent pengaturan default 100, pastikan batas database itu sendiri menyediakan ruang kepala yang cukup.

Ruang kepala tambahan ini meningkatkan pengalaman klien selama lonjakan beban kerja yang tidak terduga dan membantu RDS Proxy mendistribusikan kembali koneksi di seluruh infrastruktur internalnya untuk manajemen panas dan tujuan lainnya.

Meskipun Anda dapat mengatur MaxConnectionsPercent ke nilai serendah 1, kami merekomendasikan minimum berikut berdasarkan jenis instans:

• db.t3.small: 100

• db.t3.medium: 55

• db.t3.large: 35

• db.r3.large atau lebih: 20

MaxIdleConnectionsPercent

Nilai minimum	Nilai maksimum	Nilai default (SQL Server)	Nilai default (mesin lain)
(nol)	MaxConnectionsPercent	5% dari MaxConnectionsPercent	50% dari MaxConnectionsPercent

Untuk informasi selengkapnya, lihat MaxIdleConnectionsPercent.

Pengaturan ini membatasi jumlah koneksi database idle yang disimpan RDS Proxy dalam kumpulan koneksi, sebagai persentase dari jumlah maksimum koneksi yang diizinkan oleh database. Koneksi database (back-end) dianggap idle ketika tidak ada aktivitas pada koneksi selama lima menit. Pengaturan ini berlaku untuk koneksi antara proxy dan database back-end.

Perhatikan hal-hal berikut:

• Pengaturan ini membatasi jumlah koneksi idle di pool, tetapi tidak memaksa proxy untuk mempertahankan sejumlah koneksi idle tertentu. Jika aktivitas klien sangat rendah, jumlah sebenarnya koneksi basis data back-end bisa lebih rendah dari. MaxIdleConnectionsPercent

• Koneksi dihitung sebagai idle saat tersedia untuk digunakan kembali di kumpulan koneksi proxy. Koneksi yang disematkan tidak tersedia untuk digunakan kembali oleh klien lain, dan oleh karena itu tidak dihitung sebagai idle untuk tujuan penegakan. MaxIdleConnectionsPercent Untuk informasi selengkapnya tentang menyematkan, lihatMenghindari menyematkan Proxy RDS.

• Jumlah koneksi idle yang dilaporkan oleh metadata database biasanya lebih tinggi daripada jumlah koneksi idle yang direkam oleh metrik Proxy RDS. Hal ini dapat disebabkan oleh koneksi klien langsung yang melewati proxy serta koneksi internal yang digunakan oleh Amazon RDS dan otomatisasi Aurora.

catatan

Waktu idle koneksi yang diamati dan diterapkan pada lapisan proxy mungkin berbeda dari waktu idle yang dilaporkan oleh alat database seperti daftar proses MySQL atau tabel statistik aktivitas di PostgreSQL. RDS Proxy melakukan ping koneksi back-end sesekali, yang mengatur ulang pengatur waktu idle database meskipun koneksi tetap menganggur dalam hal aktivitas klien.

Praktik terbaik:

Pengaturan default 50 cocok dan direkomendasikan untuk sebagian besar beban kerja. Mengubah pengaturan memiliki efek sebagai berikut:

• Ketika Anda meningkatkanMaxIdleConnectionsPercent, database mengamati sejumlah besar koneksi idle yang dapat meningkatkan konsumsi sumber daya database di luar jam sibuk. Di sisi lain, lonjakan koneksi yang ditangani melalui proxy mengalami latensi pinjaman yang lebih rendah karena ada lebih banyak koneksi yang tersedia di kolam.

• Ketika Anda menurunkanMaxIdleConnectionsPercent, proxy menutup koneksi idle lebih agresif, berpotensi mengurangi pertikaian dan konsumsi sumber daya yang disebabkan oleh koneksi tersebut. Namun, lonjakan koneksi yang melewati proxy mungkin mengalami waktu pinjaman yang lebih lama. Karena ada lebih sedikit koneksi yang tersedia di kolam, proxy perlu menghabiskan waktu tambahan untuk membuka koneksi back-end baru selama lonjakan.

Konsumsi sumber daya oleh koneksi idle mungkin tidak menjadi perhatian material dalam database yang menggunakan tipe instans yang disediakan, tetapi database Aurora yang menggunakan tipe instans v2 Tanpa Server mungkin lebih suka mengoptimalkan konsumsi sumber daya idle untuk mengurangi biaya.

IdleClientTimeout

Nilai minimum	Nilai maksimum	Nilai default
1 menit	8 jam	30 menit

Untuk informasi selengkapnya, lihat IdleClientTimeout.

Pengaturan ini menentukan berapa lama koneksi klien dapat tetap diam sebelum proxy menutupnya. Perhatikan bahwa RDS Proxy memberlakukan masa pakai koneksi maksimum 24 jam, terlepas dari apakah koneksi tidak digunakan. Misalnya, jika Anda mengonfigurasi IdleClientTimeout hingga 30 menit (default) dan melakukan ping ke database setiap menit, koneksi tidak akan pernah melebihi batas waktu idle, tetapi tidak tetap terbuka tanpa batas waktu. RDS Proxy menutup koneksi setelah 24 jam meskipun tidak memenuhi syarat sebagai idle.

IdleClientTimeoutPengaturan ini berlaku untuk koneksi antara klien (aplikasi atau pengguna interaktif) dan RDS Proxy. Untuk memahami perilaku menganggur koneksi back-end antara RDS Proxy dan database, lihat. MaxIdleConnectionsPercent

Praktik terbaik:

• Batas waktu idle harus cukup lama untuk mengakomodasi jeda normal dalam aktivitas SQL di dalam koneksi atau transaksi klien. Tidak boleh selama memungkinkan klien untuk mempertahankan sumber daya yang tidak lagi dibutuhkan, tetapi itu mungkin dibutuhkan oleh klien lain. Ini sangat penting jika Anda mengamati penyematan koneksi karena koneksi yang disematkan oleh satu klien tidak dapat digunakan kembali oleh klien lain.

• Agar Proxy RDS dapat menerapkan batas waktu dengan benar, koneksi klien harus benar-benar menganggur tanpa mengirim kueri apa pun (bahkan pemeriksaan kesehatan sederhana sepertiSELECT 1;) atau ping protokol (seperti di MySQL). COM_PING Jika Anda mengamati koneksi tidak ditutup meskipun melebihi batas waktu, periksa logika koneksi driver aplikasi Anda. Application-level kolam koneksi sangat mungkin untuk melakukan pemeriksaan keaktifan mereka sendiri yang mengganggu. IdleClientTimeout

ConnectionBorrowTimeout

Nilai minimum	Nilai maksimum	Nilai default
(nol)	5 menit	2 menit

Untuk informasi selengkapnya, lihat ConnectionBorrowTimeout.

Ketika klien terhubung ke RDS Proxy, proxy harus meminjam koneksi yang tersedia dari pool atau membuka koneksi database baru. Pengaturan ini menentukan berapa lama Proxy RDS menunggu koneksi dipinjam atau dibuka sebelum mengembalikan kesalahan.

Perhatikan hal-hal berikut:

• A ConnectionBorrowTimeout nol menghasilkan kesalahan batas waktu ketika kumpulan koneksi belum berisi koneksi yang tersedia. Ini benar bahkan jika kolam di bawah kapasitas maksimum dan dapat membuka koneksi back-end baru.

• Bahkan dengan MaxIdleConnectionsPercent sama denganMaxConnectionsPercent, jumlah koneksi aktual di kolam bisa lebih rendah dari maksimum yang dikonfigurasi. Dengan kata lain, MaxIdleConnectionsPercent membatasi jumlah koneksi idle tetapi tidak memaksa koneksi untuk tetap terbuka.

Adalah normal untuk kolam koneksi berjalan di bawah kapasitas maksimum. Dalam situasi ini, menggunakan ConnectionBorrowTimeout pengaturan nol dapat mencegah kolam tumbuh karena kolam tidak diizinkan menunggu koneksi baru dibuka. Akibatnya, Anda harus menggunakan ConnectionBorrowTimeout nilai bukan nol untuk semua beban kerja kecuali perilaku yang dijelaskan sebelumnya lebih disukai.

catatan

Pengaturan ini juga berlaku ketika database tidak siap menerima koneksi, seperti selama operasi pemeliharaan offline dan kegagalan. Logika untuk menegakkan ConnectionBorrowTimeout adalah sama apakah database naik atau turun.

Kueri inisialisasi dan filter penyematan

RDS Proxy mendukung fitur tambahan yang dapat mengurangi pin koneksi dan meningkatkan efisiensi multiplexing sebagai hasilnya.

Kueri inisialisasi adalah satu atau lebih pernyataan yang dijalankan setiap kali proxy menyiapkan koneksi database back-end baru. Jika klien Anda menggunakan pernyataan identik untuk mengatur parameter sesi, Anda dapat memindahkan pernyataan tersebut ke kueri inisialisasi proxy. Ini membantu mengurangi kemungkinan penyematan dan juga meningkatkan efisiensi: koneksi database back-end tertentu menjalankan kueri inisialisasi sekali selama pengaturan tetapi mungkin digunakan kembali nanti oleh banyak klien. Perlu diingat bahwa menempatkan pernyataan SQL dalam kueri inisialisasi tidak memfilternya dari lalu lintas klien. Anda masih perlu menghapus pernyataan tersebut dari kode aplikasi sehingga tidak mengganggu multiplexing.

Filter penyematan sesi adalah properti konfigurasi yang mencegah proxy menyematkan status sesi tertentu. Satu-satunya opsi filter yang tersedia saat ini,EXCLUDE_VARIABLE_SETS, menginstruksikan proxy untuk mengabaikan semua SET pernyataan saat menentukan apakah sesi harus disematkan. SETPernyataan masih diteruskan ke database dan dapat memengaruhi status sesi, yang berarti opsi ini hanya aman dalam situasi berikut:

1. SETPernyataannya adalah no-ops, seperti mengatur variabel sistem ke nilai yang identik dengan default server.

2. SETPernyataan dan kueri berikutnya adalah bagian dari transaksi yang sama, dan setiap transaksi menetapkan statusnya sendiri sepenuhnya secara independen sehingga tidak terpengaruh oleh variabel yang ditetapkan oleh transaksi lain.

catatan

Filter EXCLUDE_VARIABLE_SETS penyematan adalah pengaturan semua-atau-tidak sama sekali dan Anda tidak dapat memilih pernyataan mana yang SET akan diabaikan secara selektif. Jangan gunakan filter ini sebagai solusi selimut untuk menyematkan kecuali kasus penggunaan Anda termasuk dalam salah satu kategori yang dibahas dalam daftar sebelumnya.

Untuk hasil terbaik, hapus pernyataan yang tidak perlu dari kode aplikasi jika memungkinkan, dan hanya menggunakan filter jika modifikasi aplikasi tidak memungkinkan. Ini mempromosikan lingkungan client-server yang kurang bising dan lebih dapat diprediksi dibandingkan dengan menerapkan perlakuan khusus pada pernyataan yang tidak diperlukan sejak awal.

penting

Baik kueri inisialisasi maupun filter penyematan tidak menyebabkan RDS Proxy mengubah lalu lintas kueri client-server. Pernyataan yang datang dari klien masih diteruskan ke database terlepas dari kueri init atau konfigurasi filter penyematan.

Untuk informasi lebih lanjut, lihat:

• Membuat proxy dan Memodifikasi proxy untuk Amazon RDS.

• Membuat proxy dan Memodifikasi proxy untuk Amazon Aurora.

Untuk koneksi PostgreSQL, Anda juga dapat menempatkan parameter koneksi yang didukung dalam pesan startup yang dipertukarkan antara driver klien dan proxy. Ini menghindari pengiriman SET perintah terpisah, baik mengurangi perjalanan pulang pergi dan menghindari pin koneksi yang disebabkan oleh pernyataan eksplisit. SET Untuk informasi selengkapnya, lihat Pertimbangan untuk menghubungkan ke PostgreSQL.

Menyelaraskan konfigurasi aplikasi, proxy, dan database

Seperti yang dibahas di bagian sebelumnya, RDS Proxy mendukung berbagai parameter untuk membantu Anda menyelaraskan perilaku proxy dengan kebutuhan aplikasi Anda. Namun, memilih nilai konfigurasi yang tepat adalah tugas yang memotong semua lapisan tumpukan: aplikasi, proxy, dan database itu sendiri. Pengaturan semua komponen tersebut harus selaras dengan tujuan berikut dalam pikiran:

1. Memberikan tingkat kinerja dan skalabilitas yang diharapkan selama operasi normal.

2. Mempromosikan kejelasan dan kemudahan pemecahan masalah selama masalah beban kerja.

3. Bantu tumpukan menangani kejadian tak terduga (seperti lonjakan beban kerja) dengan dampak minimal pada aplikasi.

Saat memilih dan menyetel pengaturan di lingkungan berlapis-lapis, cobalah untuk menyelaraskan nilai konfigurasi sedemikian rupa sehingga batas dan batas waktu pada lapisan bawah sama dengan atau lebih tinggi dari batas dan batas waktu yang sesuai pada lapisan yang lebih tinggi. Dengan kata lain, perlakukan pengaturan dari satu lapisan sebagai amplop yang cocok dengan amplop konfigurasi berikutnya lebih jauh ke bawah tumpukan.

Misalnya, asumsikan bahwa aplikasi Anda adalah lapisan atas, proxy adalah lapisan tengah, dan database adalah lapisan bawah. Jika batas waktu dan batas pada tingkat proxy lebih rendah dari batas di tingkat aplikasi, proxy membatasi batas aplikasi preempt. Aplikasi tidak dapat menjalankan pengaturannya dan mengalami perilaku yang tidak dapat dijelaskan oleh konfigurasinya sendiri.

Pertimbangkan pengaturan IdleClientTimeout proxy sebagai contoh. Jika driver aplikasi atau kumpulan klien menerapkan batas waktu idle mereka sendiri, batas waktu idle proxy adalah jaring pengaman di atas pengaturan aplikasi. Ini berarti minimal IdleClientTimeout harus sama dengan batas waktu idle tingkat aplikasi apa pun untuk mencegah kebingungan:

• Ketika batas waktu idle aplikasi lebih rendah dari batas waktu proxy, Anda mengharapkan aplikasi menutup koneksinya seperti yang dikonfigurasi. Jika aplikasi gagal menutup koneksi idle tepat waktu, proxy bertindak sebagai backstop.

• Ketika batas waktu idle aplikasi lebih lama dari batas waktu proxy, aplikasi mungkin mengalami penutupan koneksi yang dianggap prematur. Hal ini dapat menyebabkan kebingungan di sisi aplikasi.

Logika yang sama berlaku untuk pengaturan lain seperti batas koneksi: pengaturan setiap lapisan harus sesuai di dalam amplop yang ditentukan oleh konfigurasi lapisan berikutnya.

Untuk hasil terbaik, pengaturan konfigurasi harus menyertakan beberapa padding antara satu lapisan dan lapisan berikutnya. Misalnya, Anda dapat membuat batas waktu proxy beberapa detik lebih lama dari batas waktu aplikasi untuk menghindari kesalahan sporadis karena penyimpangan client/server jam, atau jika klien memerlukan waktu tambahan untuk menutup koneksi dengan anggun.

Dengan kata lain, sejajarkan pengaturan Anda seperti ini:

client timeout < proxy timeout < database timeout

Alih-alih melakukan ini:

client timeout = proxy timeout = database timeout

Dan hindari ini:

client timeout > proxy timeout > database timeout

Konfigurasi basis data

Batas koneksi

RDS Proxy menggunakan MaxConnectionsPercent pengaturan untuk menentukan ukuran maksimum kumpulan koneksinya, yang berarti ukuran kumpulan koneksi proxy relatif terhadap batas koneksi database. Ketika Anda mengubah batas koneksi database, ukuran pool proxy mengikuti secara otomatis. Jika Anda ingin database mencadangkan sebagian dari batas koneksi untuk pengguna non-proxy, Anda harus melakukannya dengan menurunkan MaxConnectionsPercent pengaturan di proxy daripada dengan meningkatkan batas database.

RDS Proxy tidak menghilangkan kebutuhan untuk konfigurasi batas koneksi database yang tepat. Koneksi proxy tunggal tidak secara inheren lebih ringan daripada koneksi klien langsung tunggal, jadi jangan meningkatkan batas basis data hanya karena Anda menggunakan proxy. Proxy tidak mengurangi jumlah pekerjaan yang harus dilakukan database untuk menangani kueri, tetapi membantu database menangani beban kerja yang sama menggunakan koneksi yang lebih sedikit.

Batas waktu idle

Database dapat menerapkan batas waktu idle mereka sendiri, misalnya, menggunakan dan wait_timeout pengaturan interactive_timeout di MySQL atau pengaturan dan di PostgreSQL. transaction_timeout idle_in_transaction_session_timeout Nilai default untuk pengaturan tersebut tidak mungkin mengganggu konfigurasi proxy, tetapi jika Anda menggunakan batas waktu tingkat basis data khusus, pastikan setidaknya selama batas waktu proxy yang sesuai atau proxy mengalami kesalahan koneksi karena batas waktu prematur.

Logika yang sama berlaku untuk lingkungan database menggunakan pembunuh koneksi, yang merupakan skrip atau proses yang memantau status sesi dan secara aktif menghentikan koneksi berdasarkan kriteria tertentu. Jika lingkungan Anda menggunakan teknik seperti itu, pastikan logika penghentian koneksi selaras dengan pengaturan proxy.

Database yang menangani semua beban kerja mereka melalui proxy biasanya dapat bergantung pada konfigurasi proxy untuk batas waktu idle, dan membiarkan pengaturan tingkat database pada nilai defaultnya.

Konfigurasi aplikasi

Mengelola status sesi

Banyak driver database, kerangka kerja aplikasi, dan alat pemetaan relasional objek (ORM) menggunakan variabel sesi atau SET pernyataan untuk mengatur koneksi sebelum mengirim lalu lintas kueri. Penggunaan koneksi dan pernyataan inisialisasi transaksi mungkin tidak jelas ketika melihat kode aplikasi saja, dan mungkin ada beberapa lapisan abstraksi antara database itu sendiri dan pernyataan SQL dan logika aplikasi. Anda dapat menggunakan fitur logging yang disempurnakan Proxy RDS untuk mencatat alasan penyematan koneksi, dan log kueri database dapat memberikan informasi lebih lanjut tentang semua pernyataan yang dikirim melalui koneksi database Anda.

Pertimbangkan praktik terbaik berikut:

1. Tetapkan parameter koneksi hanya ketika mereka berbeda dari default database dan sesi klien harus menyimpang dari default tersebut. Menghapus pernyataan inisialisasi yang tidak perlu tidak hanya membantu multiplexing, tetapi juga mengurangi jumlah perjalanan pulang-pergi klien-server untuk setiap koneksi database baru.

2. Atur variabel dan pengaturan konfigurasi secara konsisten di semua koneksi.

3. Hindari konfigurasi sesi yang juga dapat diterapkan pada waktu proses kueri. Misalnya, jika klien yang berbeda perlu melihat data di zona waktu yang berbeda, pertimbangkan untuk menggunakan fungsi konversi zona waktu pada tingkat kueri alih-alih mengatur zona waktu pada tingkat sesi.

4. Jika memungkinkan, pindahkan pernyataan konfigurasi sesi ke lapisan proxy menggunakan fitur kueri inisialisasi. Untuk detail selengkapnya, lihat Kueri inisialisasi dan filter penyematan.

Pemeriksaan keaktifan

Jika aplikasi Anda menggunakan penggabungan koneksi atau driver lanjutan, cari konfigurasi yang terkait dengan pemeriksaan keaktifan seperti ping protokol, pernyataan pemeriksaan kesehatan, atau kueri keep-alive. RDS Proxy memperlakukan semua permintaan klien secara setara, jadi meskipun SELECT 1; kueri atau COM_PING permintaan adalah no-op dari perspektif aplikasi, ini mencegah proxy menerapkan batas waktu klien yang tidak aktif dan mengelola ukuran kumpulan koneksi sesuai dengan. MaxIdleConnectionsPercent

catatan

Proxy RDS memberlakukan masa pakai koneksi maksimum 24 jam terlepas dari aktivitas pada koneksi.

Dalam kebanyakan kasus, mungkin tepat untuk menonaktifkan pemeriksaan keaktifan sisi klien untuk mengurangi kebisingan protokol dan membantu RDS Proxy mengelola koneksi idle. Ada kasus tepi ketika Anda mungkin ingin menjalankan pemeriksaan kesehatan tersebut terlepas dari:

• Anda sengaja ingin mencegah koneksi tertentu dari timing out di lapisan proxy.

• Anda ingin mengizinkan driver aplikasi atau kumpulan untuk secara proaktif mendeteksi ketika koneksi dijatuhkan oleh proxy. Misalnya, koneksi back-end yang disematkan mungkin ditutup karena restart basis data dan koneksi klien mungkin melebihi masa pakai maksimum 24 jam.

Pertimbangkan untuk menonaktifkan pemeriksaan keaktifan di sisi aplikasi, atau hanya lakukan untuk koneksi tertentu yang ingin Anda pertahankan dari waktu habis.

Pelacakan status sesi

Beberapa driver database MySQL, seperti driver MariaDB, session_track_* menggunakan variabel untuk mengaktifkan pelacakan status sesi. Dengan fitur ini diaktifkan, setiap kali klien membuat perubahan status sesi yang dapat dilacak server, server menyertakan informasi perubahan status dalam paket responsnya. Hal ini memungkinkan driver untuk diberitahu tentang status sesi oleh server.

Cara pelacakan status sesi ini dapat bermakna ketika klien berinteraksi dengan server secara langsung dan mengimplementasikan fitur manajemen sesi sendiri, seperti migrasi sesi di lingkungan multi-server. RDS Proxy mengimplementasikan mekanisme pelacakan statusnya sendiri dan tidak menggunakan informasi yang diaktifkan oleh session_track_* variabel, namun menyetel variabel tersebut menyebabkan penyematan sesi.

Jika driver database Anda menetapkan variabel-variabel tersebut, Anda dapat mencari cara untuk menonaktifkan fungsionalitas pelacakan di driver, beralih ke driver lain, atau menggunakan filter penyematan sesi untuk mengabaikan pernyataan jika aman untuk melakukannya. Untuk detail selengkapnya, lihat Kueri inisialisasi dan filter penyematan.