Di bagian pertama dari seri ini, kami menunjukkan kepada Anda cara menerapkan pengaturan Replikasi MySQL dengan ProxySQL dengan WHM dan cPanel. Di bagian ini, kami akan menunjukkan beberapa operasi pasca penerapan untuk pemeliharaan, manajemen, failover, serta keuntungan dari penyiapan mandiri.
Manajemen Pengguna MySQL
Dengan integrasi ini diaktifkan, manajemen pengguna MySQL harus dilakukan dari WHM atau cPanel. Jika tidak, tabel mysql_users ProxySQL tidak akan disinkronkan dengan apa yang dikonfigurasi untuk master replikasi kami. Misalkan kita sudah membuat pengguna bernama somen_user1 (nama pengguna MySQL secara otomatis diawali oleh cPanel untuk memenuhi batasan MySQL), dan kami ingin menetapkan ke database somen_db1 seperti di bawah ini:
Di atas akan menghasilkan output tabel mysql_users berikut di ProxySQL:
Jika Anda ingin membuat sumber daya MySQL di luar cPanel, Anda dapat menggunakan ClusterControl -> Manage -> Schemas and Users fitur dan kemudian impor pengguna database ke ProxySQL dengan masuk ke ClusterControl -> Nodes -> pilih node ProxySQL -> Users -> Import Users .
Modul Proxysqlhook yang kami gunakan untuk menyinkronkan pengguna ProxySQL mengirimkan log debug ke /usr/local/cpanel/logs/error_log. Gunakan file ini untuk memeriksa dan memahami apa yang terjadi di balik layar. Baris berikut akan muncul di file log cPanel jika kita menginstal aplikasi web bernama Zikula menggunakan Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Anda akan melihat beberapa baris berulang seperti "Memeriksa apakah {DB user} ada" karena WHM membuat banyak pengguna/host MySQL untuk setiap permintaan pengguna basis data. Dalam contoh kita, WHM akan membuat 3 pengguna ini:
ProxySQL hanya membutuhkan nama pengguna, kata sandi, dan informasi grup host default saat menambahkan pengguna. Oleh karena itu, garis pemeriksaan ada untuk menghindari banyak sisipan dari pengguna yang sama persis.
Jika Anda ingin memodifikasi modul dan melakukan beberapa perbaikan, jangan lupa untuk melakukan registrasi ulang modul dengan menjalankan perintah berikut di server WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookPemantauan Kueri dan Caching
Dengan ProxySQL, Anda dapat memantau semua kueri yang berasal dari aplikasi yang telah atau sedang melewatinya. WHM standar tidak memberikan tingkat detail ini dalam pemantauan permintaan MySQL. Berikut ini menunjukkan semua query MySQL yang telah ditangkap oleh ProxySQL:
Dengan ClusterControl, Anda dapat dengan mudah mencari kueri yang paling sering diulang dan menyimpannya dalam cache melalui fitur cache kueri ProxySQL. Gunakan tarik-turun "Pesan Berdasarkan" untuk mengurutkan kueri menurut "Hitung Bintang", arahkan ke kueri yang ingin Anda tembolok dan klik tombol "Kueri Cache" di bawahnya. Dialog berikut akan muncul:
Kumpulan hasil kueri yang di-cache akan disimpan dan dilayani oleh ProxySQL itu sendiri, mengurangi jumlah klik ke backend yang akan menurunkan kluster replikasi MySQL Anda secara keseluruhan. Implementasi cache kueri proxySQL pada dasarnya berbeda dari cache kueri MySQL. Ini cache berbasis waktu dan akan kedaluwarsa setelah batas waktu yang disebut "Cache TTL". Dalam konfigurasi ini, kami ingin menyimpan kueri di atas selama 5 detik (5000 mdtk) agar tidak mengenai grup pembaca di mana grup host tujuan adalah 20.
Baca/Tulis Pemisahan dan Penyeimbangan
Dengan mendengarkan port default MySQL 3306, ProxySQL bertindak seperti server MySQL itu sendiri. Ini berbicara protokol MySQL di frontend dan backend. Aturan kueri yang ditentukan oleh ClusterControl saat menyiapkan ProxySQL akan secara otomatis membagi semua pembacaan (^SELECT .* dalam bahasa Regex) ke grup host 20 yang merupakan grup pembaca, dan sisanya akan diteruskan ke grup host penulis 10, seperti yang ditunjukkan pada bagian aturan kueri berikut:
Dengan arsitektur ini, Anda tidak perlu khawatir untuk membagi kueri baca/tulis karena ProxySQL akan melakukan pekerjaan untuk Anda. Pengguna memiliki sedikit atau tidak ada perubahan pada kode, memungkinkan pengguna hosting untuk menggunakan semua aplikasi dan fitur yang disediakan oleh WHM dan cPanel secara native, mirip dengan menghubungkan ke setup MySQL mandiri.
Dalam hal penyeimbangan koneksi, jika Anda memiliki lebih dari satu node aktif dalam grup host tertentu (seperti grup host pembaca 20 dalam contoh ini), ProxySQL akan secara otomatis menyebarkan beban di antara mereka berdasarkan sejumlah kriteria - bobot, jeda replikasi, koneksi yang digunakan , beban keseluruhan dan latensi. ProxySQL dikenal sangat baik di lingkungan konkurensi tinggi dengan menerapkan mekanisme penyatuan koneksi tingkat lanjut. Dikutip dari blog post ProxySQL, ProxySQL tidak hanya mengimplementasikan Persistent Connection, tetapi juga Connection Multiplexing. Faktanya, ProxySQL dapat menangani ratusan ribu klien, namun meneruskan semua lalu lintas mereka ke beberapa koneksi ke backend. Jadi ProxySQL dapat menangani N koneksi klien dan M koneksi backend , di mana N> M (bahkan N ribuan kali lebih besar dari M).
Kegagalan dan Pemulihan MySQL
Dengan ClusterControl mengelola cluster replikasi, failover dilakukan secara otomatis jika pemulihan otomatis diaktifkan. Jika terjadi kegagalan master:
- ClusterControl akan mendeteksi dan memverifikasi kegagalan master melalui klien MySQL, SSH, dan ping.
- ClusterControl akan menunggu selama 3 detik sebelum memulai prosedur failover.
- ClusterControl akan mempromosikan budak terbaru untuk menjadi master berikutnya.
- Jika master lama kembali online, master tersebut akan dimulai sebagai hanya-baca, tanpa berpartisipasi dalam replikasi aktif.
- Terserah pengguna untuk memutuskan apa yang akan terjadi pada master lama. Itu bisa diperkenalkan kembali ke rantai replikasi dengan menggunakan fungsionalitas "Build Ulang Budak Replikasi" di ClusterControl.
- ClusterControl hanya akan mencoba melakukan failover master satu kali. Jika gagal, intervensi pengguna diperlukan.
Anda dapat memantau seluruh proses failover di bawah ClusterControl -> Activity -> Jobs -> Failover ke master baru seperti yang ditunjukkan di bawah ini:
Selama failover, semua koneksi ke server database akan diantrekan di ProxySQL. Mereka tidak akan dihentikan sampai waktu habis, dikendalikan oleh mysql-default_query_timeout variabel yaitu 8640000 milidetik atau 24 jam. Aplikasi kemungkinan besar tidak akan melihat kesalahan atau kegagalan ke database pada saat ini, tetapi tradeoffnya adalah peningkatan latensi, dalam ambang yang dapat dikonfigurasi.
Pada titik ini, ClusterControl akan menampilkan topologi seperti di bawah ini:
Jika kita ingin mengizinkan master lama bergabung kembali ke dalam replikasi setelah selesai dan tersedia, kita perlu membangunnya kembali sebagai budak dengan membuka ClusterControl -> Nodes -> pilih master lama -> Rebuild Replication Budak -> pilih master baru -> Lanjutkan . Setelah pembangunan kembali selesai, Anda akan mendapatkan topologi berikut (perhatikan 192.168.0.32 adalah master sekarang):
Konsolidasi Server dan Penskalaan Basis Data
Dengan arsitektur ini, kami dapat mengkonsolidasikan banyak server MySQL yang berada di setiap server WHM menjadi satu pengaturan replikasi tunggal. Anda dapat menskalakan lebih banyak node database saat Anda tumbuh, atau memiliki beberapa kluster replikasi untuk mendukung semuanya dan dikelola oleh satu server ClusterControl. Diagram arsitektur berikut menggambarkan jika kita memiliki dua server WHM yang terhubung ke satu cluster replikasi MySQL tunggal melalui file soket ProxySQL:
Di atas memungkinkan kita untuk memisahkan dua tingkatan yang paling penting dalam sistem hosting kita - aplikasi (front-end) dan database (back-end). Seperti yang mungkin Anda ketahui, penempatan bersama MySQL di server WHM biasanya mengakibatkan kehabisan sumber daya karena MySQL membutuhkan alokasi RAM awal yang besar untuk memulai dan bekerja dengan baik (kebanyakan tergantung pada innodb_buffer_pool_size variabel). Mengingat ruang disk cukup, dengan pengaturan di atas, Anda dapat memiliki lebih banyak akun hosting yang dihosting per server, di mana semua sumber daya server dapat digunakan oleh aplikasi tingkat front-end.
Meningkatkan kluster replikasi MySQL akan jauh lebih sederhana dengan arsitektur tier terpisah. Jika katakanlah master memerlukan pemeliharaan peningkatan (memperbarui RAM, hard disk, RAID, NIC), kita dapat mengalihkan peran master ke budak lain (ClusterControl -> Nodes -> pick a slave -> Promote Slave ) dan kemudian melakukan tugas pemeliharaan tanpa mempengaruhi layanan MySQL secara keseluruhan. Untuk operasi scale out (menambahkan lebih banyak slave), Anda dapat melakukannya tanpa mempengaruhi master dengan melakukan staging langsung dari slave aktif mana pun. Dengan ClusterControl, Anda bahkan dapat menampilkan slave baru dari cadangan MySQL yang ada (hanya kompatibel dengan PITR):
Membangun kembali budak dari cadangan tidak akan membawa beban tambahan bagi master. ClusterControl akan menyalin file cadangan yang dipilih dari server ClusterControl ke node target dan melakukan pemulihan di sana. Setelah selesai, node akan terhubung ke master dan mulai mengambil semua transaksi yang hilang sejak waktu pemulihan dan mengejar master. Saat tertinggal, ProxySQL tidak akan menyertakan node dalam set penyeimbangan beban hingga jeda replikasi kurang dari 10 detik (dapat dikonfigurasi saat menambahkan tabel mysql_servers melalui antarmuka admin ProxySQL).
Pemikiran Akhir
ProxySQL memperluas kemampuan cPanel WHM dalam mengelola Replikasi MySQL. Dengan ClusterControl mengelola kluster replikasi Anda, semua tugas kompleks yang terlibat dalam mengelola kluster replikasi kini lebih mudah dari sebelumnya.
