Memilih Topologi HA Anda
Ada berbagai cara untuk mempertahankan ketersediaan tinggi dengan database. Anda dapat menggunakan IP Virtual (VRRP) untuk mengelola ketersediaan host, Anda dapat menggunakan pengelola sumber daya seperti Zookeeper dan Etcd untuk (kembali) mengonfigurasi aplikasi Anda atau menggunakan penyeimbang/proksi beban untuk mendistribusikan beban kerja ke semua host yang tersedia.
IP Virtual memerlukan aplikasi untuk mengelolanya (MHA, Orchestrator), beberapa skrip (Keepalived, Pacemaker/Corosync) atau insinyur untuk gagal secara manual dan pengambilan keputusan dalam proses dapat menjadi rumit. Failover IP Virtual adalah proses yang mudah dan sederhana dengan menghapus alamat IP dari satu host, menugaskannya ke host lain, dan menggunakan arping untuk mengirim respons ARP secara cuma-cuma. Secara teori, IP Virtual dapat dipindahkan dalam hitungan detik tetapi akan memakan waktu beberapa detik sebelum aplikasi manajemen failover yakin host telah gagal dan bertindak sesuai dengan itu. Pada kenyataannya ini harus antara 10 dan 30 detik. Keterbatasan lain dari IP Virtual adalah bahwa beberapa penyedia cloud tidak mengizinkan Anda untuk mengelola IP Virtual Anda sendiri atau menetapkannya sama sekali. Misalnya, Google tidak mengizinkan Anda melakukannya di node komputasi mereka.
Manajer sumber daya seperti Zookeeper dan Etcd dapat memantau database Anda dan (kembali) mengonfigurasi aplikasi Anda setelah host gagal atau budak dipromosikan menjadi master. Secara umum, ini adalah ide yang bagus, tetapi menerapkan pemeriksaan Anda dengan Zookeeper and Etcd adalah tugas yang rumit.
Penyeimbang beban atau proxy akan berada di antara aplikasi dan host basis data dan bekerja secara transparan seolah-olah klien akan terhubung ke host basis data secara langsung. Sama seperti dengan IP Virtual dan manajer sumber daya, penyeimbang beban dan proxy juga perlu memantau host dan mengarahkan lalu lintas jika salah satu host sedang down. ClusterControl mendukung dua proxy:HAProxy dan ProxySQL dan keduanya didukung untuk replikasi master-slave MySQL dan cluster Galera. HAProxy dan ProxySQL keduanya memiliki kasus penggunaannya sendiri, kami juga akan menjelaskannya di postingan ini.
Mengapa Anda Membutuhkan Penyeimbang Beban?
Secara teori Anda tidak memerlukan penyeimbang beban tetapi dalam praktiknya Anda akan lebih memilihnya. Kami akan menjelaskan alasannya.
Jika Anda memiliki pengaturan IP virtual, yang harus Anda lakukan adalah mengarahkan aplikasi Anda ke alamat IP (virtual) yang benar dan semuanya harus terhubung dengan baik. Tetapi misalkan Anda telah mengurangi jumlah replika baca, Anda mungkin ingin memberikan IP virtual untuk masing-masing replika baca tersebut juga karena alasan pemeliharaan atau ketersediaan. Ini mungkin menjadi kumpulan IP virtual yang sangat besar yang harus Anda kelola. Jika salah satu dari replika baca tersebut gagal, Anda perlu menetapkan ulang IP virtual ke host lain atau aplikasi Anda akan terhubung ke salah satu host yang sedang down atau dalam kasus terburuk, server yang tertinggal dengan data basi. Oleh karena itu, menjaga status replikasi ke aplikasi yang mengelola IP virtual diperlukan.
Juga untuk Galera ada tantangan serupa:Anda secara teori dapat menambahkan host sebanyak yang Anda inginkan ke konfigurasi aplikasi Anda dan memilih satu secara acak. Masalah yang sama muncul ketika host ini sedang down:Anda mungkin akan terhubung ke host yang tidak tersedia. Juga menggunakan semua host untuk membaca dan menulis juga dapat menyebabkan kemunduran karena penguncian optimis di Galera. Jika dua koneksi mencoba menulis ke baris yang sama pada saat yang sama, salah satunya akan menerima roll back. Jika beban kerja Anda memiliki pembaruan bersamaan, disarankan untuk hanya menggunakan satu node di Galera untuk menulis. Oleh karena itu, Anda menginginkan manajer yang melacak status internal cluster database Anda.
Baik HAProxy dan ProxySQL akan menawarkan Anda fungsionalitas untuk memantau host database MySQL/MariaDB dan menjaga status cluster Anda dan topologinya. Untuk pengaturan replikasi, jika replika budak tidak berfungsi, HAProxy dan ProxySQL dapat mendistribusikan ulang koneksi ke host lain. Tetapi jika master replikasi sedang down, HAProxy akan menolak koneksi dan ProxySQL akan mengembalikan kesalahan yang tepat kepada klien. Untuk penyiapan Galera, kedua penyeimbang beban dapat memilih node master dari kluster Galera dan hanya mengirim operasi tulis ke node tertentu.
Di permukaan, HAProxy dan ProxySQL mungkin tampak seperti solusi yang serupa, tetapi mereka sangat berbeda dalam fitur dan cara mereka mendistribusikan koneksi dan kueri. HAProxy mendukung sejumlah algoritma penyeimbangan seperti koneksi paling sedikit, sumber, acak, dan round-robin sementara ProxySQL mendistribusikan koneksi menggunakan algoritma round-robin berbasis bobot (bobot yang sama berarti distribusi yang sama). Karena ProxySQL adalah proxy yang cerdas, ini adalah basis data yang sadar dan juga mampu menganalisis kueri Anda. ProxySQL dapat melakukan pemisahan baca/tulis berdasarkan aturan kueri di mana Anda dapat meneruskan kueri ke budak atau master yang ditunjuk di cluster Anda. ProxySQL menyertakan fungsionalitas tambahan seperti penulisan ulang kueri, caching, dan firewall kueri dengan pembuatan statistik mendalam dan real-time tentang beban kerja.
Itu akan menjadi informasi latar belakang yang cukup tentang topik ini, jadi mari kita lihat bagaimana Anda dapat menerapkan kedua penyeimbang beban untuk replikasi MySQL dan topologi Galera.
Menerapkan HAProxy
Menggunakan ClusterControl untuk menerapkan HAProxy pada kluster Galera itu mudah:buka kluster yang relevan dan pilih “Tambahkan Penyeimbang Beban”:
Dan Anda akan dapat menerapkan instance HAProxy dengan menambahkan alamat host dan memilih instance server yang ingin Anda sertakan dalam konfigurasi:
Secara default, instans HAProxy akan dikonfigurasi untuk mengirim koneksi ke instans server yang menerima jumlah koneksi paling sedikit, tetapi Anda dapat mengubah kebijakan itu ke round robin atau sumber.
Di bawah pengaturan lanjutan, Anda dapat menyetel batas waktu, jumlah koneksi maksimum, dan bahkan mengamankan proxy dengan memasukkan daftar putih rentang IP untuk koneksi.
Di bawah tab node dari cluster itu, node HAProxy akan muncul:
Sekarang cluster Galera Anda juga tersedia melalui node HAProxy yang baru digunakan pada port 3307. Jangan lupa untuk MEMBERIKAN akses aplikasi Anda dari IP HAProxy, karena sekarang lalu lintas akan masuk dari proxy, bukan dari host aplikasi. Juga, ingatlah untuk mengarahkan koneksi aplikasi Anda ke node HAProxy.
Sekarang misalkan satu server instance akan down, HAProxy akan melihat ini dalam beberapa detik dan berhenti mengirimkan lalu lintas ke instance ini:
Dua node lainnya masih baik-baik saja dan akan terus menerima lalu lintas. Ini membuat cluster tetap tersedia tanpa klien menyadari perbedaannya.
Menerapkan Node HAProxy Sekunder
Sekarang kita telah memindahkan tanggung jawab untuk mempertahankan ketersediaan tinggi melalui koneksi database dari klien ke HAProxy, bagaimana jika node proxy mati? Jawabannya adalah membuat instance HAProxy lain dan menggunakan IP virtual yang dikendalikan oleh Keepalive seperti yang ditunjukkan pada diagram ini:
Manfaat dibandingkan dengan menggunakan IP virtual pada node database adalah bahwa logika MySQL berada di tingkat proxy dan failover untuk proxy sederhana.
Jadi mari kita gunakan node HAProxy sekunder:
Setelah kita men-deploy node HAProxy sekunder, kita perlu menambahkan Keepalive:
Dan setelah Keepalive ditambahkan, gambaran node Anda akan terlihat seperti ini:
Jadi sekarang, alih-alih mengarahkan koneksi aplikasi Anda ke node HAProxy secara langsung, Anda harus mengarahkannya ke IP virtual.
Dalam contoh di sini, kami menggunakan host terpisah untuk menjalankan HAProxy, tetapi Anda juga dapat dengan mudah menambahkannya ke instance server yang ada. HAProxy tidak membawa banyak overhead, meskipun Anda harus ingat bahwa jika terjadi kegagalan server, Anda akan kehilangan node database dan proxy.
Menyebarkan ProxySQL
Menyebarkan ProxySQL ke kluster Anda dilakukan dengan cara yang mirip dengan HAProxy:"Tambahkan Penyeimbang Beban" di daftar kluster di bawah tab ProxySQL.
Di wizard penyebaran, tentukan di mana ProxySQL akan diinstal, pengguna/sandi administrasi, pengguna/sandi pemantauan untuk terhubung ke backend MySQL. Dari ClusterControl, Anda dapat membuat pengguna baru untuk digunakan oleh aplikasi (pengguna akan dibuat di MySQL dan ProxySQL) atau menggunakan pengguna database yang ada (pengguna hanya akan dibuat di ProxySQL). Setel apakah Anda menggunakan transaksi implisit atau tidak. Pada dasarnya, jika Anda tidak menggunakan SET autocommit=0 untuk membuat transaksi baru, ClusterControl akan mengonfigurasi pemisahan baca/tulis.
Setelah ProxySQL di-deploy, itu akan tersedia di bawah tab Nodes:
Membuka ikhtisar node ProxySQL akan menampilkan antarmuka pemantauan dan manajemen ProxySQL, jadi tidak ada alasan untuk masuk ke ProxySQL di node lagi. ClusterControl mencakup sebagian besar statistik penting ProxySQL seperti penggunaan memori, cache kueri, prosesor kueri, dan sebagainya, serta metrik lain seperti grup host, server backend, hit aturan kueri, kueri teratas, dan variabel ProxySQL. Dalam aspek manajemen ProxySQL, Anda dapat mengelola aturan kueri, server backend, pengguna, konfigurasi, dan penjadwal langsung dari UI.
Lihat halaman tutorial ProxySQL kami yang membahas secara ekstensif tentang cara melakukan Load Balancing database untuk MySQL dan MariaDB dengan ProxySQL.
Menyebarkan Garbd
Galera mengimplementasikan algoritme berbasis kuorum untuk memilih komponen utama yang digunakan untuk menegakkan konsistensi. Komponen utama harus memiliki suara mayoritas (50% + 1 node), sehingga dalam sistem 2 node, tidak akan ada mayoritas yang mengakibatkan split brain. Untungnya, dimungkinkan untuk menambahkan garbd (Galera Arbitrator Daemon), yang merupakan daemon stateless ringan yang dapat bertindak sebagai simpul ganjil. Manfaat tambahan dengan menambahkan Arbiter Galera adalah Anda sekarang dapat melakukannya hanya dengan dua node di cluster Anda.
Jika ClusterControl mendeteksi bahwa cluster Galera Anda terdiri dari jumlah node yang genap, Anda akan diberi peringatan/saran oleh ClusterControl untuk memperluas cluster ke jumlah node yang ganjil:
Pilih dengan bijak host untuk menyebarkan garbd, karena ia akan menerima semua data yang direplikasi. Pastikan jaringan dapat menangani lalu lintas dan cukup aman. Anda dapat memilih salah satu host HAProxy atau ProxySQL untuk menerapkan garbd, seperti pada contoh di bawah ini:
Perhatikan bahwa mulai dari ClusterControl 1.5.1, garbd tidak dapat diinstal pada host yang sama dengan ClusterControl karena risiko konflik paket.
Setelah menginstal garbd, Anda akan melihatnya muncul di sebelah dua node Galera Anda:
Pemikiran Terakhir
Kami menunjukkan kepada Anda cara membuat penyiapan kluster master-slave dan Galera MySQL Anda lebih kuat dan mempertahankan ketersediaan tinggi menggunakan HAProxy dan ProxySQL. Garbd juga merupakan daemon bagus yang dapat menyimpan simpul ketiga tambahan di kluster Galera Anda.
Ini menyelesaikan sisi penerapan ClusterControl. Di blog kami berikutnya, kami akan menunjukkan cara mengintegrasikan ClusterControl dalam organisasi Anda dengan menggunakan grup dan menetapkan peran tertentu kepada pengguna.
