Baru-baru ini kami menulis beberapa blog yang membahas bagaimana penyedia cloud yang berbeda menangani failover basis data. Kami membandingkan kinerja failover di Amazon Aurora, Amazon RDS dan ClusterControl, menguji perilaku failover di Amazon RDS, dan juga di Google Cloud Platform. Meskipun layanan tersebut menyediakan opsi hebat dalam hal failover, layanan tersebut mungkin tidak tepat untuk setiap aplikasi.
Dalam posting blog ini kita akan menghabiskan sedikit waktu untuk menganalisis pro dan kontra dari penggunaan solusi DBaaS dibandingkan dengan merancang lingkungan secara manual atau dengan menggunakan platform manajemen database, seperti ClusterControl.
Menerapkan Basis Data Ketersediaan Tinggi dengan Solusi Terkelola
Alasan utama untuk menggunakan solusi yang ada adalah kemudahan penggunaan. Anda dapat menerapkan solusi yang sangat tersedia dengan failover otomatis hanya dalam beberapa klik. Tidak perlu menggabungkan alat yang berbeda bersama-sama, mengelola database dengan tangan, menggunakan alat, menulis skrip, merancang pemantauan, atau operasi manajemen database lainnya. Semuanya sudah ada di tempatnya. Ini dapat secara serius mengurangi kurva pembelajaran dan membutuhkan lebih sedikit pengalaman untuk menyiapkan lingkungan yang sangat tersedia untuk database; pada dasarnya memungkinkan semua orang untuk menerapkan penyiapan seperti itu.
Dalam sebagian besar kasus dengan solusi ini, proses failover dijalankan dalam waktu yang wajar. Ini mungkin sangat cepat seperti dengan Amazon Aurora atau agak lebih lambat seperti dengan node SQL Google Cloud Platform. Untuk sebagian besar kasus, jenis hasil ini dapat diterima.
Intinya. Jika Anda dapat menerima waktu henti selama 30 - 60 detik, Anda seharusnya tidak masalah menggunakan platform DBaaS mana pun.
Kelemahan Menggunakan Solusi Terkelola untuk HA
Meskipun solusi DBaaS mudah digunakan, mereka juga memiliki beberapa kelemahan serius. Sebagai permulaan, selalu ada komponen penguncian vendor yang perlu dipertimbangkan. Setelah Anda menerapkan klaster di Amazon Web Services, cukup sulit untuk bermigrasi keluar dari penyedia itu. Tidak ada metode mudah untuk mengunduh kumpulan data lengkap melalui cadangan fisik. Dengan sebagian besar penyedia, hanya cadangan logis yang dieksekusi secara manual yang tersedia. Tentu, selalu ada opsi untuk mencapai hal ini, tetapi biasanya ini merupakan proses yang rumit dan memakan waktu, yang mungkin masih memerlukan waktu henti.
Menggunakan penyedia seperti Amazon RDS juga memiliki keterbatasan. Beberapa tindakan tidak dapat dilakukan dengan mudah yang akan sangat mudah dilakukan pada lingkungan yang diterapkan dengan cara yang sepenuhnya dikontrol pengguna (mis. AWS EC2). Beberapa batasan ini telah dibahas di blog lain, tetapi untuk meringkasnya adalah bahwa tidak ada layanan DBaaS yang memberi Anda tingkat fleksibilitas yang sama seperti replikasi berbasis MySQL GTID biasa. Anda dapat mempromosikan budak apa pun, Anda dapat memperbudak kembali setiap simpul dari yang lain ... hampir setiap tindakan dimungkinkan. Dengan alat seperti RDS, Anda menghadapi batasan akibat desain yang tidak dapat Anda lewati.
Masalahnya juga terletak pada kemampuan untuk memahami detail kinerja. Saat Anda merancang pengaturan Anda sendiri yang sangat tersedia, Anda menjadi berpengetahuan tentang potensi masalah kinerja yang mungkin muncul. Di sisi lain, RDS dan lingkungan serupa cukup banyak "kotak hitam." Ya, kami telah mempelajari bahwa Amazon RDS menggunakan DRBD untuk membuat salinan bayangan master, kami tahu bahwa Aurora menggunakan penyimpanan bersama yang direplikasi untuk menerapkan failover yang sangat cepat. Itu hanya pengetahuan umum. Kami tidak dapat mengetahui apa implikasi kinerja dari solusi tersebut selain dari apa yang mungkin kami perhatikan dengan santai. Apa masalah umum yang terkait dengan mereka? Seberapa stabil solusi tersebut? Hanya pengembang di balik solusi yang tahu pasti.
Apa Alternatif untuk Solusi DBaaS?
Anda mungkin bertanya-tanya, apakah ada alternatif selain DBaaS? Lagi pula, sangat nyaman untuk menjalankan layanan terkelola di mana Anda dapat mengakses sebagian besar tindakan biasa melalui UI. Anda dapat membuat dan memulihkan cadangan, failover ditangani secara otomatis untuk Anda. Lingkungannya mudah digunakan yang dapat menarik bagi perusahaan yang tidak memiliki staf yang berdedikasi dan berpengalaman untuk menangani database.
ClusterControl menyediakan alternatif yang bagus untuk layanan DBaaS berbasis cloud. Ini memberi Anda antarmuka pengguna grafis, yang dapat digunakan untuk menyebarkan, mengelola, dan memantau database sumber terbuka.
Dalam beberapa klik, Anda dapat dengan mudah menerapkan cluster database yang sangat tersedia, dengan failover otomatis (lebih cepat daripada sebagian besar penawaran DBaaS), manajemen pencadangan, pemantauan lanjutan, dan fitur lain seperti integrasi dengan alat eksternal (mis. Slack atau PagerDuty) atau manajemen pemutakhiran. Semua ini sambil sepenuhnya menghindari penguncian vendor.
ClusterControl tidak peduli di mana database Anda berada selama dapat terhubung dengan mereka menggunakan SSH. Anda dapat memiliki pengaturan di cloud, lokal, atau di lingkungan campuran dari beberapa penyedia cloud. Selama konektivitas ada, ClusterControl akan dapat mengelola lingkungan. Memanfaatkan solusi yang Anda inginkan (dan bukan solusi yang tidak Anda kenal atau sadari) memungkinkan Anda untuk mengambil kendali penuh atas lingkungan kapan saja.
Apa pun penyiapan yang Anda terapkan dengan ClusterControl, Anda dapat dengan mudah mengelolanya dengan cara yang lebih tradisional, manual, atau dengan skrip. ClusterControl bahkan memberi Anda antarmuka baris perintah, yang memungkinkan Anda menggabungkan tugas yang dijalankan oleh ClusterControl ke dalam skrip shell Anda. Anda memiliki semua kontrol yang Anda inginkan - tidak ada kotak hitam, setiap bagian dari lingkungan akan dibangun menggunakan solusi open source yang digabungkan bersama dan disebarkan oleh ClusterControl.
Mari kita lihat betapa mudahnya Anda dapat menerapkan cluster Replikasi MySQL menggunakan ClusterControl. Mari kita asumsikan Anda telah menyiapkan lingkungan dengan ClusterControl yang diinstal pada satu instance dan semua node lain dapat diakses melalui SSH dari host ClusterControl.
Kita akan mulai dengan memilih wizard “Deploy”.
Pada langkah pertama kita harus mendefinisikan bagaimana ClusterControl harus terhubung ke node database mana yang akan digunakan. Akses root atau sudo (dengan atau tanpa kata sandi) didukung.
Kemudian, kami ingin memilih vendor, versi dan memasukkan kata sandi untuk pengguna administratif di database MySQL kami.
Terakhir, kami ingin mendefinisikan topologi untuk cluster baru kami. Seperti yang Anda lihat, ini adalah penyiapan yang cukup rumit, tidak seperti sesuatu yang dapat Anda terapkan menggunakan AWS RDS atau node SQL GCP.
Yang harus kita lakukan sekarang adalah menunggu prosesnya selesai. ClusterControl akan melakukan yang terbaik untuk memahami lingkungan yang digunakannya dan menginstal kumpulan paket yang diperlukan, termasuk database itu sendiri.
Setelah cluster aktif dan berjalan, Anda dapat melanjutkan penerapan lapisan proxy (yang akan memberi aplikasi Anda satu titik masuk ke lapisan database). Kurang lebih inilah yang terjadi di balik layar dengan DBaaS, di mana Anda juga memiliki titik akhir untuk terhubung ke cluster database. Sangat umum menggunakan satu titik akhir untuk penulisan dan beberapa titik akhir untuk mencapai replika tertentu.
Di sini kita akan menggunakan ProxySQL, yang akan melakukan pekerjaan kotor untuk kita - itu akan memahami topologi, hanya mengirim tulisan ke master dan memuat kueri read-only balance di semua replika yang kita miliki.
Untuk men-deploy ProxySQL kita akan pergi ke Manage -> Load Balancers.
Kita harus mengisi semua bidang yang diperlukan:host yang akan digunakan, kredensial untuk pengguna administratif dan pemantauan, kami dapat mengimpor pengguna yang ada dari MySQL ke ProxySQL atau membuat yang baru. Semua detail tentang ProxySQL dapat dengan mudah ditemukan di beberapa blog di bagian blog kami.
Kami ingin setidaknya dua node ProxySQL di-deploy untuk memastikan ketersediaan yang tinggi. Kemudian, setelah mereka di-deploy, kami akan men-deploy Keepalive di atas ProxySQL. Ini akan memastikan bahwa IP Virtual akan dikonfigurasi dan mengarah ke salah satu instance ProxySQL, selama setidaknya ada satu node yang sehat.
Inilah satu-satunya masalah potensial jika Anda menggunakan lingkungan cloud tempat perutean berfungsi sedemikian rupa sehingga Anda tidak dapat dengan mudah membuka antarmuka jaringan. Dalam kasus seperti itu, Anda harus memodifikasi konfigurasi Keepalive, memperkenalkan skrip 'notify_master' dan menggunakan skrip, yang akan membuat perubahan IP yang diperlukan - dalam kasus EC2 ia harus melepaskan IP Elastis dari satu host dan melampirkannya ke tuan rumah lainnya.
Ada banyak petunjuk tentang cara melakukannya menggunakan perangkat lunak sumber terbuka yang telah teruji secara luas dalam penyiapan yang diterapkan oleh ClusterControl. Anda dapat dengan mudah menemukan informasi tambahan, kiat, dan petunjuk yang relevan dengan lingkungan khusus Anda.
Kesimpulan
Kami harap Anda menemukan posting blog ini berwawasan. Jika Anda ingin menguji ClusterControl, ia hadir dengan uji coba perusahaan 30 hari di mana Anda telah menyediakan semua fitur. Anda dapat mengunduhnya secara gratis dan menguji apakah cocok dengan lingkungan Anda.
