Topik ini menjawab pertanyaan dan isu umum mengenai penggunaan proksi database untuk RDS for MySQL.
Daftar Isi
Apa perbedaan antara proksi tujuan umum dan proksi dedicated?
Apakah proksi database menggunakan QPS atau TPS dari instans primary?
Apakah titik akhir proksi database sama dengan titik akhir instans biasa?
Apakah jenis jaringan internal proksi database sama dengan instans primary?
Arsitektur apa yang digunakan oleh proksi database? Apakah failover didukung?
Apa hubungan antara spesifikasi proksi dan spesifikasi node proksi?
Apa hubungan antara jumlah node proksi dan spesifikasi proksi?
Apakah ada hubungan antara jumlah node proksi dan jumlah titik akhir proksi?
Apakah kinerja proksi database meningkat jika saya menambahkan lebih banyak titik akhir proksi?
Dapatkah saya memodifikasi titik akhir proksi database (titik akhir pemisahan baca/tulis)?
Mengapa beban pada setiap node tidak sesuai dengan bobot baca yang dikonfigurasi?
Setelah saya mengaktifkan proksi database, bagaimana cara memverifikasi pemisahan baca/tulis?
Apakah operasi DDL secara otomatis disinkronkan dari instans primary ke instans secondary?
Dapatkah saya mengubah zona ketersediaan saat memodifikasi konfigurasi proksi?
Apa itu proksi database?
Proksi database adalah layanan proksi jaringan yang berada di antara database dan server aplikasi Anda. Layanan ini meneruskan semua permintaan dari aplikasi Anda ke database dan menyediakan fitur-fitur lanjutan seperti pemisahan baca/tulis otomatis, pemisahan transaksi, kolam koneksi, dan persistensi koneksi. Proksi database dirancang untuk ketersediaan tinggi, kinerja tinggi, serta kemudahan penggunaan dan pemeliharaan.
Apa perbedaan antara proksi tujuan umum dan proksi dedicated?
Tujuan umum: Berbagi sumber daya CPU fisik, sehingga menjadi opsi yang hemat biaya. Spesifikasi proksi maksimum adalah 16 core CPU (8 node proksi), dan tipe ini gratis.
Dedicated: Menggunakan sumber daya CPU fisik eksklusif, memberikan stabilitas kinerja yang lebih baik. Spesifikasi proksi maksimum adalah 64 core CPU (32 node proksi), dan tipe ini ditagih berdasarkan skema pay-as-you-go.
Untuk informasi lebih lanjut, lihat Proksi tujuan umum dan dedicated, Hubungan antara jumlah node proksi dan spesifikasi proksi, dan Biaya proksi database.
Apakah proksi database menggunakan QPS atau TPS dari instans primary?
Tidak.
Apakah titik akhir proksi database sama dengan titik akhir instans biasa?
Tidak.
Titik akhir instans biasa mengarahkan semua permintaan ke instans tertentu tersebut.
Titik akhir proksi database secara otomatis mengidentifikasi permintaan baca dan tulis berdasarkan pernyataan SQL Anda. Permintaan tulis diteruskan ke instans primary, sedangkan permintaan baca diteruskan ke instans hanya baca. Proses ini memungkinkan pemisahan baca/tulis dan mengurangi beban pada instans primary.
Setelah saya mengaktifkan proksi database, apakah titik akhir asli dari instans primary dan instans hanya baca ditarik kembali?
Tidak.
Apakah jenis jaringan internal proksi database sama dengan instans primary?
Jaringan internal untuk proksi database selalu berupa VPC.
Arsitektur apa yang digunakan oleh proksi database? Apakah failover didukung?
Proksi database menggunakan arsitektur dual-primary-node yang sangat tersedia. Trafik didistribusikan antara kedua node dengan rasio 1:1. Jika salah satu node gagal, node lainnya mengambil alih seluruh trafik. Sebuah tugas secara otomatis dipicu untuk membangun ulang node yang gagal guna mempertahankan ketersediaan tinggi.
Untuk informasi lebih lanjut mengenai arsitektur penerapan, lihat Arsitektur penerapan proksi.
Hubungan antara spesifikasi proksi dan spesifikasi node
spesifikasi proksi = Jumlah dari semua spesifikasi node proksi
Sebagai contoh, proksi dedicated diterapkan dalam penerapan dua zona (Zona Ketersediaan A dan Zona Ketersediaan B). Di Zona Ketersediaan A, terdapat dua node proksi dengan spesifikasi masing-masing 1 core CPU. Di Zona Ketersediaan B, terdapat dua node proksi dengan spesifikasi masing-masing 2 core CPU. Total spesifikasi proksi dihitung sebagai berikut: (1 core CPU × 2) + (2 core CPU × 2) = 2 core CPU + 4 core CPU = 6 core CPU.
Hubungan antara node proksi dan spesifikasi
jumlah node proksi = spesifikasi proksi / Spesifikasi per Unit, di mana spesifikasi per unit tetap sebesar 2 core CPU.
Sebagai contoh, jika spesifikasi proksi adalah 6 core CPU, jumlah node proksi adalah 3 (6 / 2).
Batasan spesifikasi node proksi
Spesifikasi satu node proksi berkisar antara 1 hingga 8 core CPU untuk tipe tujuan umum dan 1 hingga 16 core CPU untuk tipe dedicated.
Semua node proksi dalam zona ketersediaan yang sama harus memiliki spesifikasi yang sama.
Dalam penerapan dua zona dengan dua node, kedua node harus memiliki spesifikasi yang sama.
Node proksi di zona ketersediaan yang berbeda dapat memiliki spesifikasi berbeda. Untuk proksi tujuan umum, kami merekomendasikan agar node proksi di zona ketersediaan berbeda menggunakan spesifikasi yang sama.
Hubungan antara node proksi dan titik akhir
Tidak.
Setelah Anda mengaktifkan proksi database untuk instans RDS, Anda dapat membuat satu hingga tujuh titik akhir proksi. Untuk setiap titik akhir proksi, Anda dapat membuat satu titik akhir internal dan satu titik akhir publik. Untuk informasi lebih lanjut, lihat Menambahkan titik akhir proksi.
Apakah penambahan titik akhir proksi meningkatkan kinerja?
Tidak.
Kinerja proksi database bergantung pada jumlah instans hanya baca dan jumlah node proksi (spesifikasi proksi) untuk instans RDS Edisi Ketersediaan Tinggi. Untuk instans RDS Edisi Kluster, kinerja bergantung pada jumlah instans secondary dan jumlah node proksi (spesifikasi proksi).
Menambah jumlah instans hanya baca (untuk Edisi Ketersediaan Tinggi) atau instans secondary (untuk Edisi Kluster) meningkatkan kapasitas pemrosesan baca proksi database.
Menambah jumlah node proksi (spesifikasi proksi) meningkatkan kinerja keseluruhan proksi database.
Batasan koneksi proksi database
Proksi database tidak membatasi jumlah maksimum koneksi. Batas ini ditentukan oleh spesifikasi node komputasi database Anda.
Menangani error timeout koneksi
Tingkatkan nilai parameter wait_timeout dan coba sambungkan kembali. Untuk informasi lebih lanjut tentang cara memodifikasi parameter instans, lihat Mengatur parameter instans ApsaraDB RDS for MySQL.
Memodifikasi titik akhir proksi
Ya.
Anda dapat memodifikasi titik akhir proksi database (titik akhir pemisahan baca/tulis). Untuk informasi lebih lanjut, lihat Memodifikasi titik akhir proksi.
Mengirim permintaan baca ke instans primary
Ya.
Anda dapat memberikan bobot baca ke instans primary saat mengonfigurasi distribusi bobot baca. Untuk informasi lebih lanjut tentang cara memberikan bobot baca ke instans primary, lihat Mengaktifkan fitur proksi database untuk instans ApsaraDB RDS for MySQL.
Dukungan hint untuk pemisahan baca/tulis
Ya. Anda dapat menggunakan hint untuk memaksa permintaan dieksekusi di instans primary. Untuk informasi lebih lanjut tentang format hint yang didukung oleh pemisahan baca/tulis RDS, lihat bagian "Gunakan hint untuk menentukan apakah pernyataan SQL dikirim ke instans primary atau instans hanya baca" dalam Aturan alokasi bobot baca default.
Bobot baca yang dimodifikasi tidak berlaku
Setelah Anda memodifikasi bobot baca, hanya koneksi baru yang didistribusikan berdasarkan bobot baru tersebut. Koneksi yang sudah ada tidak terpengaruh.
Ketidakseimbangan beban dengan bobot baca
Jika distribusi beban di seluruh node tidak sesuai dengan bobot baca yang dikonfigurasi, periksa hal berikut:
Periksa apakah permintaan Anda merupakan bagian dari transaksi. Semua permintaan dalam transaksi diarahkan ke instans primary. Anda dapat mengaktifkan pemisahan transaksi untuk mengurangi beban pada instans primary.
Pastikan Anda hanya terhubung melalui titik akhir proksi database. Koneksi yang dilakukan menggunakan titik akhir instans primary atau instans hanya baca melewati distribusi bobot baca.
Mengonfigurasi bobot baca tanpa proksi database
Jika proksi database dinonaktifkan, Anda tidak dapat mengonfigurasi bobot baca untuk instans hanya baca. Namun, Anda tetap dapat mencapai pemisahan baca/tulis dan penyeimbangan beban dengan menggunakan titik akhir terpisah untuk instans primary dan instans hanya baca dalam kode aplikasi Anda.
Failover koneksi untuk instans hanya baca yang tidak tersedia
Tidak, koneksi yang sudah ada ke instans gagal tersebut tidak secara otomatis melakukan failover. Koneksi baru ke instans sehat hanya dibuat setelah koneksi yang gagal mengalami timeout.
Bagaimana cara memverifikasi pemisahan baca/tulis setelah Anda mengaktifkan layanan proksi database?
Sinkronisasi data otomatis ke instans hanya baca baru
Ya. Saat Anda mengaktifkan proksi database untuk pemisahan baca/tulis, data historis secara otomatis disinkronkan dari instans primary ke instans hanya baca. Tidak diperlukan intervensi manual.
Kolam koneksi proksi vs. kolam koneksi aplikasi
Proksi database menyediakan kolam koneksi tingkat proksi yang independen dari kolam tingkat client aplikasi Anda. Jika aplikasi Anda sudah menggunakan kolam koneksi, penggunaan kolam koneksi proksi tidak diperlukan. Untuk informasi lebih lanjut tentang kolam koneksi proksi database, lihat Mengonfigurasi kolam koneksi.
Menangani karakter acak pada hasil kueri
Jalankan perintah berikut untuk memeriksa apakah set karakter yang digunakan oleh instans primary dan instans hanya baca konsisten:
select
@@global.character_set_results,
@@global.character_set_client,
@@global.character_set_connection,
@@global.character_set_server;Jika set karakter tidak konsisten, karakter acak dapat muncul. Anda dapat memodifikasi set karakter instans primary atau instans hanya baca untuk memastikan konsistensi. Untuk informasi lebih lanjut tentang cara memodifikasi set karakter instans, lihat Set karakter instans ApsaraDB RDS for MySQL.
Sinkronisasi DDL otomatis
Ya. Semua operasi DDL, seperti membuat atau menghapus database dan tabel, mengubah struktur tabel, serta memodifikasi izin, secara otomatis disinkronkan dari instans primary ke instans secondary-nya.
Menampilkan VPC dan ID vSwitch
Pada halaman Database proxy instans Anda, buka bagian Connection information. Untuk melihat informasi tersebut, arahkan pointer ke ikon di sebelah kanan Port, seperti yang ditunjukkan pada gambar berikut.
Dampak migrasi lintas zona terhadap instans primary
Migrasi node proksi lintas zona ketersediaan hanya memengaruhi workload yang menggunakan titik akhir proksi database. Koneksi yang dilakukan melalui titik akhir instans primary, titik akhir instans hanya baca, titik akhir baca/tulis kluster, titik akhir hanya-baca kluster, atau titik akhir tingkat node tidak terpengaruh. Untuk meminimalkan dampak, alihkan workload Anda ke titik akhir yang tidak terpengaruh dan lakukan migrasi selama jam sepi.
Dampak migrasi proksi lintas zona
Saat Anda memigrasikan proksi lintas zona ketersediaan, koneksi yang menggunakan proksi database mungkin mengalami pemutusan sementara yang berlangsung sekitar 30 detik. Durasi aktual gangguan bergantung pada workload Anda. Untuk meminimalkan dampak, alihkan workload Anda ke titik akhir yang tidak terpengaruh dan lakukan migrasi selama jam sepi. Untuk informasi lebih lanjut, lihat Migrasi proksi database lintas zona.
Dampak migrasi lintas zona terhadap akses terdekat
Mungkin menjadi tidak tersedia.
Migrasi lintas zona dapat membuat konfigurasi akses terdekat tidak valid. Setelah migrasi, zona baru dapat diakses secara default; zona asli tidak lagi dapat diakses. Jika zona titik akhir proksi berbeda dari zona default baru, akses terdekat ke zona tersebut gagal.
| Skenario | Zona node proksi asli | Titik akhir proksi | Akses terdekat asli | Zona node proksi baru | Zona default baru | Zona titik akhir proksi baru | Akses terdekat baru |
|---|---|---|---|---|---|---|---|
Skenario 1: Zona A+Zona B → Zona A+Zona C |
Zona A | Titik akhir proksi a | Zona A | Zona A | Zona A | Zona A | Zona A |
| Zona C | Tidak valid | ||||||
| Zona B | Titik akhir proksi b | Zona B | Zona C | Zona C | Zona C | Zona C | |
| Zona D | Tidak valid | ||||||
Skenario 2: Zona A+Zona B → Zona C+Zona D |
Zona A | Titik akhir proksi a | Zona A | Zona C | Zona C | Zona C | Zona C |
| Zona E | Tidak valid | ||||||
| Zona B | Titik akhir proksi b | Zona B | Zona D | Zona D | Zona D | Zona D | |
| Zona E | Tidak valid |
Mengubah zona ketersediaan selama konfigurasi
Tidak.
Jika Anda perlu memigrasikan ke zona ketersediaan yang berbeda, lihat Migrasi proksi database lintas zona.
Menyelesaikan error vSwitchId dalam penerapan satu zona
Saat mengubah dari penerapan dua zona (misalnya, di Zona Ketersediaan 1 dan Zona Ketersediaan 2) ke penerapan satu zona (misalnya, di Zona Ketersediaan 1), Anda harus terlebih dahulu menghapus titik akhir proksi database di Zona Ketersediaan 2. Untuk informasi lebih lanjut, lihat Memodifikasi titik akhir proksi.
Apakah alamat IP proksi yang diselesaikan bersifat tetap?
Tidak. Selalu gunakan titik akhir proksi database (misalnya, d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com) untuk terhubung, bukan alamat IP yang diselesaikan.
Memverifikasi koneksi melalui titik akhir proksi
Anda dapat mengidentifikasi metode koneksi berdasarkan ID session. ID session kurang dari 16777215 menunjukkan koneksi melalui titik akhir instans. ID yang lebih tinggi menunjukkan koneksi melalui titik akhir proksi database.
ID session terlihat di Manajemen session.
Data tidak langsung terlihat setelah operasi write
Penyebab umum: Hal ini terjadi ketika proksi mengarahkan permintaan baca Anda ke instans hanya baca yang tertinggal dari instans primary karena latensi replikasi.
Solusi:
Gunakan hint: Untuk kueri yang memerlukan konsistensi baca kuat, gunakan hint
/*FORCE_MASTER*/untuk mengarahkan permintaan ke instans primary.Nonaktifkan pemisahan transaksi dan bungkus kueri yang memerlukan konsistensi baca kuat dalam sebuah transaksi.
Atur tingkat konsistensi ke konsistensi global.
Masing-masing solusi ini mengarahkan lebih banyak kueri ke instans primary, yang dapat meningkatkan bebannya. Evaluasi kapasitas instans primary Anda sebelum melakukan perubahan. Kami merekomendasikan penggunaan hint sebagai metode utama untuk mengarahkan hanya permintaan baca ber-konsistensi tinggi tertentu ke instans primary.