Lapisan proxy antara aplikasi dan database biasanya terdiri dari beberapa node proxy untuk ketersediaan tinggi. Ini tidak berbeda untuk ProxySQL. ProxySQL, sama seperti proxy modern lainnya, dapat digunakan untuk membangun logika kompleks untuk kueri perutean. Anda dapat menambahkan aturan kueri untuk mengirim kueri ke host tertentu, Anda dapat membuat cache kueri, Anda dapat menambah dan menghapus server backend, atau mengelola pengguna yang diizinkan untuk terhubung ke ProxySQL dan MySQL. Namun, banyak node ProxySQL di lapisan proxy menimbulkan masalah lain - sinkronisasi di seluruh instance terdistribusi. Aturan atau logika lain apa pun perlu disinkronkan di seluruh instance, untuk memastikan mereka berperilaku dengan cara yang sama. Meskipun tidak semua proxy menangani lalu lintas, mereka masih berfungsi sebagai siaga. Jika mereka perlu mengambil alih pekerjaan, Anda tidak ingin ada kejutan jika instance yang digunakan tidak memiliki perubahan konfigurasi terbaru.
Cukup rumit untuk memastikan ini secara manual - untuk membuat perubahan dengan tangan di semua node. Anda dapat menggunakan alat seperti Ansible, Chef, atau Puppet untuk mengelola konfigurasi, tetapi proses sinkronisasi harus dikodekan dan diuji. ClusterControl dapat membantu Anda di sini melalui opsi untuk menyinkronkan konfigurasi antara instance ProxySQL, tetapi juga dapat mengatur dan mengelola komponen lain yang diperlukan untuk ketersediaan tinggi, misalnya, Virtual IP. Tetapi mulai dari versi 1.4.2, ProxySQL menawarkan mekanisme pengelompokan dan sinkronisasi konfigurasi asli. Dalam posting blog ini, kita akan membahas cara menyiapkannya dengan campuran tindakan yang dilakukan di antarmuka admin baris perintah ClusterControl dan ProxySQL.
Pertama-tama, mari kita lihat lingkungan replikasi khas yang diterapkan oleh ClusterControl.
Seperti yang Anda lihat dari tangkapan layar, ini adalah pengaturan replikasi MySQL dengan tiga instance ProxySQL. Ketersediaan tinggi ProxySQL diimplementasikan melalui Keepalive dan IP Virtual yang selalu ditetapkan ke salah satu node ProxySQL. Ada beberapa langkah yang harus kita ambil untuk mengonfigurasi pengelompokan ProxySQL. Pertama, kita harus menentukan pengguna mana yang harus digunakan ProxySQL untuk bertukar informasi antar node. Mari kita tentukan yang baru di atas pengguna administratif yang ada:
Selanjutnya, kita perlu mendefinisikan pengguna tersebut di pengaturan admin-cluster_password dan admin-cluster_username.
Ini telah dilakukan hanya pada salah satu node (10.0.0.126). Mari sinkronkan perubahan konfigurasi ini ke node ProxySQL yang tersisa.
Seperti yang kami nyatakan, ClusterControl memungkinkan Anda untuk menyinkronkan konfigurasi antara node ProxySQL hanya dengan beberapa langkah. Saat tugas selesai menyinkronkan 10.0.0.127 dengan 10.0.0.126, hanya ada node terakhir yang perlu kita sinkronkan.
Setelah ini, kita perlu membuat perubahan kecil pada antarmuka baris perintah administratif ProxySQL, yang biasanya dapat dijangkau pada port 6032. Kita harus membuat entri di tabel 'proxysql_servers' yang akan menentukan node dalam cluster ProxySQL kita.
mysql> INSERT INTO proxysql_servers (hostname) VALUES ('10.0.0.126'), ('10.0.0.127'), ('10.0.0.128');
Query OK, 3 rows affected (0.00 sec)mysql> LOAD PROXYSQL SERVERS TO RUNTIME;
Query OK, 0 rows affected (0.01 sec)mysql> SAVE PROXYSQL SERVERS TO DISK;
Query OK, 0 rows affected (0.01 sec)Setelah memuat perubahan ke runtime, ProxySQL harus mulai menyinkronkan node. Ada beberapa tempat di mana Anda dapat melacak status cluster.
mysql> SELECT * FROM stats_proxysql_servers_checksums;
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| hostname | port | name | version | epoch | checksum | changed_at | updated_at | diff_check |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
| 10.0.0.128 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_query_rules | 2 | 1539772933 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_servers | 4 | 1539772933 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_users | 2 | 1539772933 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.128 | 6032 | proxysql_servers | 2 | 1539773835 | 0x8EB13E2B48C3FDB0 | 1539773835 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_query_rules | 3 | 1539773719 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_servers | 5 | 1539773719 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_users | 3 | 1539773719 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.127 | 6032 | proxysql_servers | 2 | 1539773812 | 0x8EB13E2B48C3FDB0 | 1539773813 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | admin_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_query_rules | 1 | 1539770578 | 0x3FEC69A5C9D96848 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_servers | 3 | 1539771053 | 0x3659DCF3E53498A0 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_users | 1 | 1539770578 | 0xDD5F0BB01235E930 | 1539773546 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | mysql_variables | 0 | 0 | | 0 | 1539773916 | 0 |
| 10.0.0.126 | 6032 | proxysql_servers | 2 | 1539773546 | 0x8EB13E2B48C3FDB0 | 1539773546 | 1539773916 | 0 |
+------------+------+-------------------+---------+------------+--------------------+------------+------------+------------+
18 rows in set (0.00 sec)Tabel stats_proxysql_servers_checksums berisi, antara lain, daftar node dalam cluster, tabel yang disinkronkan, versi dan checksum tabel. Jika checksum tidak sesuai, ProxySQL akan mencoba untuk mendapatkan versi terbaru dari rekan cluster. Informasi lebih rinci tentang isi tabel ini dapat ditemukan di dokumentasi ProxySQL.
Sumber informasi lain tentang proses ini adalah log ProxySQL (secara default terletak di /var/lib/proxysql/proxysql.log).
2018-10-17 11:00:25 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer 10.0.0.126:6032, version 2, epoch 1539774025, checksum 0xD615D5416F61AA72 . Not syncing yet …
2018-10-17 11:00:27 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 3. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected a peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025, diff_check 4. Own version: 2, epoch: 1539772933. Proceeding with remote sync
2018-10-17 11:00:28 [INFO] Cluster: detected peer 10.0.0.126:6032 with mysql_query_rules version 2, epoch 1539774025
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 started
2018-10-17 11:00:28 [INFO] Cluster: Fetching MySQL Query Rules from peer 10.0.0.126:6032 completed
2018-10-17 11:00:28 [INFO] Cluster: Loading to runtime MySQL Query Rules from peer 10.0.0.126:6032
2018-10-17 11:00:28 [INFO] Cluster: Saving to disk MySQL Query Rules from peer 10.0.0.126:6032Seperti yang Anda lihat, kami memiliki informasi di sini bahwa checksum baru telah terdeteksi dan proses sinkronisasi telah dilakukan.
Mari kita berhenti sejenak di sini dan membahas bagaimana ProxySQL menangani pembaruan konfigurasi dari berbagai sumber. Pertama-tama, ProxySQL melacak checksum untuk mendeteksi ketika konfigurasi telah berubah. Itu juga menyimpan ketika itu terjadi - data ini disimpan sebagai stempel waktu, sehingga memiliki resolusi satu detik. ProxySQL memiliki dua variabel yang juga memengaruhi cara perubahan disinkronkan.
Cluster_check_interval_ms - menentukan seberapa sering ProxySQL harus memeriksa perubahan konfigurasi. Secara default adalah 1000ms.
Cluster_mysql_servers_diffs_before_sync - ini memberi tahu kita berapa kali pemeriksaan harus mendeteksi perubahan konfigurasi sebelum disinkronkan. Pengaturan default adalah 3.
Artinya, meskipun Anda akan membuat perubahan konfigurasi pada host yang sama, jika Anda membuatnya kurang dari 4 detik, node ProxySQL yang tersisa mungkin tidak dapat menyinkronkannya karena perubahan baru akan muncul sebelum yang sebelumnya disinkronkan. Ini juga berarti bahwa jika Anda membuat perubahan konfigurasi pada beberapa instance ProxySQL, Anda harus membuatnya dengan jeda setidaknya 4 detik di antara mereka karena jika tidak, beberapa perubahan akan hilang dan, akibatnya, konfigurasi akan berbeda. Misalnya, Anda menambahkan Server1 pada Proxy1 , dan setelah 2 detik Anda menambahkan Server2 pada Proxy2 . Semua proxy lain akan menolak perubahan pada Proxy1 karena mereka akan mendeteksi bahwa Proxy2 memiliki konfigurasi yang lebih baru. 4 detik setelah perubahan pada Proxy2, semua proxy (termasuk Proxy1) akan menarik konfigurasi dari Proxy2.
Karena komunikasi intra-cluster tidak sinkron dan jika node ProxySQL yang Anda buat perubahannya gagal, perubahan mungkin tidak direplikasi tepat waktu. Pendekatan terbaik adalah membuat perubahan yang sama pada dua node ProxySQL. Dengan cara ini, kecuali keduanya gagal pada saat yang sama, salah satu dari mereka akan dapat menyebarkan konfigurasi baru.
Juga perlu diperhatikan adalah bahwa topologi cluster ProxySQL bisa sangat fleksibel. Dalam kasus kami, kami memiliki tiga node, semuanya memiliki tiga entri dalam tabel proxysql_servers. Node tersebut membentuk cluster di mana Anda dapat menulis ke node mana pun dan perubahan akan disebarkan. Selain itu, dimungkinkan untuk menambahkan node eksternal yang akan bekerja dalam mode "hanya-baca", yang berarti bahwa mereka hanya akan menyinkronkan perubahan yang dibuat ke cluster "inti" tetapi mereka tidak akan menyebarkan perubahan yang dilakukan secara langsung pada diri mereka sendiri. Yang Anda butuhkan pada node baru hanyalah memiliki node cluster "inti" yang dikonfigurasi di proxysql_servers dan, sebagai hasilnya, node tersebut akan terhubung ke node tersebut dan mendapatkan perubahan data, tetapi tidak akan ditanyakan oleh cluster lainnya untuk perubahan konfigurasinya. Penyiapan ini dapat digunakan untuk membuat sumber kebenaran dengan beberapa node dalam cluster, dan node ProxySQL lainnya, yang hanya mendapatkan konfigurasi dari cluster "inti" utama.
Selain semua itu, cluster ProxySQL mendukung penggabungan kembali node secara otomatis - mereka akan menyinkronkan konfigurasinya saat memulai. Itu juga dapat dengan mudah diperkecil dengan menambahkan lebih banyak node.
Kami berharap posting blog ini memberi Anda wawasan tentang bagaimana cluster ProxySQL dapat dikonfigurasi. Cluster ProxySQL akan transparan untuk ClusterControl dan tidak akan memengaruhi operasi apa pun yang mungkin ingin Anda jalankan dari UI ClusterControl.
