Memiliki penyeimbang beban atau proxy terbalik di depan server MySQL atau MariaDB Anda memang menambah sedikit kerumitan pada pengaturan basis data Anda, yang mungkin menyebabkan beberapa hal berperilaku berbeda. Secara teoritis, penyeimbang beban yang berada di depan server MySQL (misalnya HAProxy di depan Galera Cluster) seharusnya hanya bertindak seperti manajer koneksi dan mendistribusikan koneksi ke server backend sesuai dengan beberapa algoritma penyeimbangan. MySQL, di sisi lain, memiliki caranya sendiri dalam mengelola koneksi klien. Idealnya, kita perlu mengonfigurasi kedua komponen ini bersama-sama untuk menghindari perilaku yang tidak diharapkan, dan mempersempit permukaan pemecahan masalah saat men-debug masalah.
Jika Anda memiliki pengaturan seperti itu, penting untuk memahami komponen ini karena mereka dapat memengaruhi kinerja keseluruhan layanan database Anda. Dalam posting blog ini, kita akan mempelajari max_connections MySQL MySQL dan HAProxy maxconn pilihan masing-masing. Perhatikan bahwa batas waktu adalah parameter penting lainnya yang harus kita ketahui, tetapi kita akan membahasnya di postingan terpisah.
Koneksi Maks MySQL
Referensi terkait MySQL Load Balancing dengan HAProxy - Tutorial Webinar Replay dan T&J:cara menerapkan dan mengelola ProxySQL, HAProxy, dan MaxScale Webinar Replay &Slides:Cara membangun infrastruktur database yang skalabel dengan MariaDB &HAProxyJumlah koneksi yang diizinkan ke server MySQL dikendalikan oleh max_connections variabel sistem. Nilai defaultnya adalah 151 (MySQL 5.7).
Untuk menentukan angka yang baik untuk koneksi_maks , rumus dasarnya adalah:
Dimana,
**Variabel innodb_additional_mem_pool_size dihapus di MySQL 5.7.4+. Jika Anda menjalankan dalam versi yang lebih lama, pertimbangkan variabel ini.
Dan,
Dengan menggunakan rumus di atas, kita dapat menghitung koneksi_maks yang sesuai nilai untuk server MySQL khusus ini. Untuk memulai proses, hentikan semua koneksi dari klien dan mulai ulang server MySQL. Pastikan Anda hanya memiliki jumlah minimum proses yang berjalan pada saat itu. Anda dapat menggunakan 'mysqladmin' atau 'SHOW PROCESSLIST' untuk tujuan ini:
$ mysqladmin -uroot -p processlist
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
| 232172 | root | localhost | NULL | Query | 0 | NULL | show processlist | 0.000 |
+--------+------+-----------+------+---------+------+-------+------------------+----------+
1 row in set (0.00 sec)Dari output di atas, kita dapat mengetahui bahwa hanya satu pengguna yang terhubung ke server MySQL yaitu root. Kemudian, ambil RAM yang tersedia (dalam MB) dari host (lihat di bawah kolom 'tersedia'):
$ free -m
total used free shared buff/cache available
Mem: 3778 1427 508 148 1842 1928
Swap: 2047 4 2043Sekadar info, kolom 'available' memberikan perkiraan berapa banyak memori yang tersedia untuk memulai aplikasi baru, tanpa bertukar (hanya tersedia di kernel 3.14+).
Kemudian, tentukan memori yang tersedia, 1928 MB dalam pernyataan berikut:
mysql> SELECT ROUND((1928 - (ROUND((@@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@query_cache_size + @@tmp_table_size + @@key_buffer_size) / 1024 / 1024))) / (ROUND(@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@thread_stack + @@join_buffer_size + @@binlog_cache_size) / 1024 / 1024)) AS 'Possible Max Connections';
+--------------------------+
| Possible Max Connections |
+--------------------------+
| 265 |
+--------------------------+**Variabel innodb_additional_mem_pool_size dihapus di MySQL 5.7.4+. Jika Anda menjalankan dalam versi yang lebih lama, pertimbangkan variabel ini.
Dari contoh ini, kita dapat memiliki hingga 265 koneksi MySQL secara bersamaan sesuai dengan RAM yang tersedia yang dimiliki host. Tidak masuk akal untuk mengonfigurasi nilai yang lebih tinggi dari itu. Kemudian, tambahkan baris berikut di dalam file konfigurasi MySQL, di bawah direktif [mysqld]:
max_connections = 265Mulai ulang layanan MySQL untuk menerapkan perubahan. Ketika total koneksi simultan mencapai 265, Anda akan mendapatkan kesalahan "Terlalu banyak koneksi" saat mencoba terhubung ke server mysqld. Ini berarti bahwa semua koneksi yang tersedia sedang digunakan oleh klien lain. MySQL sebenarnya mengizinkan max_connections +1 klien untuk terhubung. Koneksi ekstra dicadangkan untuk digunakan oleh akun yang memiliki hak istimewa SUPER. Jadi jika Anda menghadapi kesalahan ini, Anda harus mencoba mengakses server sebagai pengguna root (atau pengguna SUPER lainnya) dan melihat daftar proses untuk memulai pemecahan masalah.
Koneksi Maks HAProxy
HAProxy memiliki 3 jenis koneksi maksimal (maxconn) - global, default/listen dan default-server. Asumsikan instance HAProxy dikonfigurasi dengan dua pendengar, satu untuk mendengarkan multi-penulis pada port 3307 (koneksi didistribusikan ke semua server MySQL backend) dan satu lagi adalah penulis tunggal pada port 3308 (koneksi diteruskan ke satu server MySQL):
global
...
maxconn 2000 #[a]
...
defaults
...
maxconn 3 #[b]
...
listen mysql_3307
...
maxconn 8 #[c]
balance leastconn
default-server port 9200 maxqueue 10 weight 10 maxconn 4 #[d]
server db1 192.168.55.171 check
server db2 192.168.55.172 check
server db3 192.168.55.173 check
listen mysql_3308
...
default-server port 9200 maxqueue 10 weight 10 maxconn 5 #[e]
server db1 192.168.55.171 check
server db2 192.168.55.172 check backup #[f]Mari kita lihat arti dari beberapa baris konfigurasi:
global.maxconn [a]
Jumlah total koneksi bersamaan yang diizinkan untuk terhubung ke instans HAProxy ini. Biasanya, nilai ini adalah nilai tertinggi dari semuanya. Dalam hal ini, HAProxy akan menerima maksimum 2000 koneksi sekaligus dan mendistribusikannya ke semua pendengar yang ditentukan dalam proses HAProxy, atau pekerja (Anda dapat menjalankan beberapa proses HAProxy menggunakan nbproc pilihan).
HAProxy akan berhenti menerima koneksi ketika batas ini tercapai. Parameter "ulimit-n" secara otomatis disesuaikan dengan nilai ini. Karena soket dianggap setara dengan file dari perspektif sistem, batas deskriptor file default agak kecil. Anda mungkin ingin menaikkan batas default dengan menyetel kernel untuk deskriptor file.
defaults.maxconn [b]
Nilai koneksi maksimum default untuk semua pendengar. Tidak masuk akal jika nilai ini lebih tinggi dari global.maxconn .
Jika baris "maxconn" tidak ada di bawah bait "listen" (listen.maxconn ), pendengar akan mematuhi nilai ini. Dalam hal ini, pendengar mysql_3308 akan mendapatkan maksimal 3 koneksi sekaligus. Agar aman, tetapkan nilai ini sama dengan global.maxconn , dibagi dengan jumlah pendengar. Namun, jika Anda ingin memprioritaskan pendengar lain untuk memiliki lebih banyak koneksi, gunakan listen.maxconn sebagai gantinya.
dengarkan.maxconn [c]
Koneksi maksimum yang diizinkan untuk pendengar yang sesuai. Listener lebih diutamakan daripada defaults.maxconn jika ditentukan. Tidak masuk akal jika nilai ini lebih tinggi dari global.maxconn .
Untuk distribusi koneksi yang adil ke server backend seperti dalam kasus pendengar multi-penulis (mysql_3307), tetapkan nilai ini sebagai listen.default-server.maxconn kalikan dengan jumlah server backend. Dalam contoh ini, nilai yang lebih baik seharusnya 12 daripada 8 [c]. Jika kita memilih untuk tetap menggunakan konfigurasi ini, db1 dan db2 diharapkan masing-masing menerima maksimal 3 koneksi, sedangkan db3 akan menerima maksimal 2 koneksi (karena keseimbangan koneksi terkecil), yang berjumlah total 8 koneksi. Itu tidak akan mencapai batas seperti yang ditentukan dalam [d].
Untuk pendengar penulis tunggal (mysql_3308) di mana koneksi harus dialokasikan ke satu dan hanya satu server backend pada satu waktu, setel nilai ini agar sama atau lebih tinggi dari listen.default-server.maxconn .
listen.default-server.maxconn [d][e]
Ini adalah jumlah maksimum koneksi yang dapat diterima oleh setiap server backend dalam satu waktu. Tidak masuk akal jika nilai ini lebih tinggi dari listen.maxconn atau defaults.maxconn . Nilai ini harus lebih rendah atau sama dengan max_connections MySQL variabel. Jika tidak, Anda berisiko menghabiskan koneksi ke server MySQL backend, terutama ketika variabel batas waktu MySQL dikonfigurasi lebih rendah daripada batas waktu HAProxy.
Dalam contoh ini, kami telah menetapkan setiap server MySQL untuk hanya mendapatkan maksimal 4 koneksi sekaligus untuk node Galera multi-penulis [d]. Sedangkan node Galera single-writer akan mendapatkan maksimal 3 koneksi sekaligus, karena batasan yang berlaku dari [b]. Karena kami menetapkan "cadangan" [f] ke node lain, node aktif akan segera mendapatkan semua 3 koneksi yang dialokasikan ke listener ini.
Penjelasan di atas dapat digambarkan dalam diagram berikut:
Untuk meringkas distribusi koneksi, db1 diharapkan mendapatkan jumlah maksimum 6 koneksi (3 dari 3307 + 3 dari 3308). db2 akan mendapatkan 3 koneksi (kecuali jika db1 turun, di mana ia akan mendapatkan tambahan 3) dan db3 akan menempel pada 2 koneksi terlepas dari perubahan topologi di cluster.
Pemantauan Koneksi dengan ClusterControl
Dengan ClusterControl, Anda dapat memantau penggunaan koneksi MySQL dan HAProxy dari UI. Tangkapan layar berikut memberikan ringkasan penasihat koneksi MySQL (ClusterControl -> Performance -> Advisors) di mana ia memantau koneksi MySQL saat ini dan yang pernah digunakan untuk setiap server di cluster:
Untuk HAProxy, ClusterControl terintegrasi dengan halaman statistik HAProxy untuk mengumpulkan metrik. Ini disajikan di bawah tab Node:
Dari tangkapan layar di atas, kita dapat mengetahui bahwa setiap server backend pada pendengar multi-penulis mendapat maksimum 8 koneksi. 4 sesi bersamaan sedang berjalan. Ini disorot di kotak merah atas, sementara pendengar penulis tunggal melayani 2 koneksi dan meneruskannya ke satu node masing-masing.
Kesimpulan
Mengonfigurasi koneksi maksimum untuk HAProxy dan server MySQL penting untuk memastikan distribusi beban yang baik ke server database kami, dan melindungi server MySQL dari kelebihan beban atau menguras koneksinya.
