Menjalankan database di infrastruktur cloud semakin populer akhir-akhir ini. Meskipun VM cloud mungkin tidak dapat diandalkan seperti server tingkat perusahaan, penyedia cloud utama menawarkan berbagai alat untuk meningkatkan ketersediaan layanan. Dalam posting blog ini, kami akan menunjukkan cara merancang database MySQL atau MariaDB Anda untuk ketersediaan tinggi, di cloud. Kami akan melihat secara khusus di Amazon Web Services dan Google Cloud Platform, tetapi sebagian besar tips juga dapat digunakan dengan penyedia cloud lainnya.
Baik AWS dan Google menawarkan layanan database di cloud mereka, dan layanan ini dapat dikonfigurasi untuk ketersediaan tinggi. Dimungkinkan untuk memiliki salinan di zona ketersediaan yang berbeda (atau zona di GCP), untuk meningkatkan peluang Anda untuk bertahan dari kegagalan sebagian layanan dalam suatu wilayah. Meskipun layanan yang dihosting adalah cara yang sangat nyaman untuk menjalankan database, perhatikan bahwa layanan ini dirancang untuk berperilaku dengan cara tertentu dan yang mungkin atau mungkin tidak sesuai dengan kebutuhan Anda. Jadi misalnya, AWS RDS untuk MySQL memiliki daftar opsi yang cukup terbatas dalam hal penanganan failover. Penerapan multi-AZ hadir dengan waktu failover 60-120 detik sesuai dengan dokumentasi. Faktanya, mengingat instance MySQL "bayangan" harus dimulai dari kumpulan data yang "rusak", ini mungkin memakan waktu lebih lama karena lebih banyak pekerjaan mungkin diperlukan untuk menerapkan atau memutar kembali transaksi dari log redo InnoDB. Ada opsi untuk mempromosikan budak menjadi master, tetapi itu tidak mungkin karena Anda tidak dapat melepaskan budak yang ada dari master baru. Dalam kasus layanan terkelola, secara intrinsik juga lebih kompleks dan lebih sulit untuk melacak masalah kinerja. Wawasan lebih lanjut tentang RDS untuk MySQL dan keterbatasannya ada di entri blog ini.
Di sisi lain, jika Anda memutuskan untuk mengelola database, Anda berada di dunia kemungkinan yang berbeda. Beberapa hal yang dapat Anda lakukan pada bare metal juga dimungkinkan pada instans EC2 atau Compute Engine. Anda tidak memiliki overhead untuk mengelola perangkat keras yang mendasarinya, namun tetap memegang kendali tentang cara merancang sistem. Ada dua opsi utama saat merancang ketersediaan MySQL - replikasi MySQL dan Galera Cluster. Mari kita diskusikan.
Replikasi MySQL
Replikasi MySQL adalah cara umum untuk menskalakan MySQL dengan banyak salinan data. Asynchronous atau semi-synchronous, memungkinkan untuk menyebarkan perubahan yang dieksekusi pada satu penulis, master, ke replika/slave - yang masing-masing akan berisi kumpulan data lengkap dan dapat dipromosikan menjadi master baru. Replikasi juga dapat digunakan untuk menskalakan pembacaan, dengan mengarahkan lalu lintas baca ke replika dan membongkar master dengan cara ini. Keuntungan utama dari replikasi adalah kemudahan penggunaan - sangat dikenal luas dan populer (juga mudah dikonfigurasi) sehingga ada banyak sumber daya dan alat untuk membantu Anda mengelola dan mengonfigurasinya. ClusterControl kami sendiri adalah salah satunya - Anda dapat menggunakannya untuk menerapkan pengaturan replikasi MySQL dengan penyeimbang beban terintegrasi dengan mudah, mengelola perubahan topologi, failover/pemulihan, dan sebagainya.
Salah satu masalah utama dengan replikasi MySQL adalah tidak dirancang untuk menangani pemisahan jaringan atau kegagalan master. Jika master turun, Anda harus mempromosikan salah satu replika. Ini adalah proses manual, meskipun dapat diotomatisasi dengan alat eksternal (misalnya ClusterControl). Juga tidak ada mekanisme kuorum dan tidak ada dukungan untuk memagari instans master yang gagal dalam replikasi MySQL. Sayangnya, hal ini dapat menyebabkan masalah serius di lingkungan terdistribusi - jika Anda mempromosikan master baru sementara master lama Anda kembali online, Anda mungkin berakhir menulis ke dua node, membuat penyimpangan data dan menyebabkan masalah konsistensi data yang serius.
Kami akan melihat beberapa contoh nanti dalam posting ini, yang menunjukkan kepada Anda cara mendeteksi pemisahan jaringan dan menerapkan STONITH atau mekanisme pagar lainnya untuk pengaturan replikasi MySQL Anda.
Kluster Galera
Kami melihat di bagian sebelumnya bahwa replikasi MySQL tidak memiliki dukungan pagar dan kuorum - di sinilah Galera Cluster bersinar. Ini memiliki dukungan kuorum bawaan, ia juga memiliki mekanisme pagar yang mencegah node yang dipartisi menerima penulisan. Ini membuat Galera Cluster lebih cocok daripada replikasi dalam pengaturan multi-pusat data. Galera Cluster juga mendukung banyak penulis, dan mampu menyelesaikan konflik penulisan. Oleh karena itu Anda tidak terbatas pada seorang penulis tunggal dalam pengaturan multi-pusat data, dimungkinkan untuk memiliki seorang penulis di setiap pusat data yang mengurangi latensi antara aplikasi Anda dan tingkat basis data. Ini tidak mempercepat penulisan karena setiap penulisan masih harus dikirim ke setiap node Galera untuk sertifikasi, tetapi masih lebih mudah daripada mengirim penulisan dari semua server aplikasi di WAN ke satu master jarak jauh.
Sebagus apa pun Galera, itu tidak selalu merupakan pilihan terbaik untuk semua beban kerja. Galera bukan pengganti drop-in untuk MySQL/InnoDB. Ini berbagi fitur umum dengan MySQL "normal" - menggunakan InnoDB sebagai mesin penyimpanan, berisi seluruh kumpulan data di setiap node, yang membuat BERGABUNG menjadi layak. Namun, beberapa karakteristik kinerja Galera (seperti kinerja penulisan yang dipengaruhi oleh latensi jaringan) berbeda dari yang Anda harapkan dari penyiapan replikasi. Pemeliharaan juga terlihat berbeda:penanganan perubahan skema bekerja sedikit berbeda. Beberapa desain skema tidak optimal:jika Anda memiliki hotspot di tabel Anda, seperti penghitung yang sering diperbarui, ini dapat menyebabkan masalah kinerja. Ada juga perbedaan dalam praktik terbaik yang terkait dengan pemrosesan batch - alih-alih mengeksekusi kueri dalam transaksi besar, Anda ingin transaksi Anda kecil.
Tingkat proxy
Sangat sulit dan tidak praktis untuk membangun setup yang sangat tersedia tanpa proxy. Tentu, Anda dapat menulis kode di aplikasi Anda untuk melacak instance database, memasukkan yang tidak sehat ke daftar hitam, melacak master yang dapat ditulisi, dan sebagainya. Tapi ini jauh lebih kompleks daripada hanya mengirim lalu lintas ke satu titik akhir - yang merupakan tempat masuknya proxy. ClusterControl memungkinkan Anda untuk menerapkan ProxySQL, HAProxy, dan MaxScale. Kami akan memberikan beberapa contoh menggunakan ProxySQL, karena memberikan kami fleksibilitas yang baik dalam mengontrol lalu lintas basis data.
ProxySQL dapat digunakan dalam beberapa cara. Sebagai permulaan, ini dapat digunakan pada host terpisah dan Keepalive dapat digunakan untuk menyediakan IP Virtual. IP Virtual akan dipindahkan jika salah satu instance ProxySQL gagal. Di cloud, pengaturan ini bisa menjadi masalah karena menambahkan IP ke antarmuka biasanya tidak cukup. Anda harus memodifikasi konfigurasi dan skrip Keepalive agar berfungsi dengan IP elastis (atau statis -namun mungkin dipanggil oleh penyedia cloud Anda). Kemudian seseorang akan menggunakan cloud API atau CLI untuk memindahkan alamat IP ini ke host lain. Untuk alasan ini, kami menyarankan untuk menempatkan ProxySQL dengan aplikasi. Setiap server aplikasi akan dikonfigurasi untuk terhubung ke ProxySQL lokal, menggunakan soket Unix. Karena ProxySQL menggunakan proses malaikat, kerusakan ProxySQL dapat dideteksi/di-restart dalam satu detik. Dalam kasus kerusakan perangkat keras, server aplikasi tertentu akan turun bersama dengan ProxySQL. Server aplikasi yang tersisa masih dapat mengakses instans ProxySQL lokal masing-masing. Pengaturan khusus ini memiliki fitur tambahan. Keamanan - ProxySQL, pada versi 1.4.8, tidak memiliki dukungan untuk SSL sisi klien. Itu hanya dapat mengatur koneksi SSL antara ProxySQL dan backend. Mengumpulkan ProxySQL pada host aplikasi dan menggunakan soket Unix adalah solusi yang baik. ProxySQL juga memiliki kemampuan untuk meng-cache kueri dan jika Anda akan menggunakan fitur ini, masuk akal untuk menyimpannya sedekat mungkin dengan aplikasi untuk mengurangi latensi. Kami menyarankan untuk menggunakan pola ini untuk menerapkan ProxySQL.
Penyiapan biasa
Mari kita lihat contoh penyiapan yang sangat tersedia.
Pusat data tunggal, replikasi MySQL
Asumsinya di sini adalah bahwa ada dua zona terpisah di dalam pusat data. Setiap zona memiliki daya, jaringan, dan konektivitas yang redundan dan terpisah untuk mengurangi kemungkinan dua zona gagal secara bersamaan. Dimungkinkan untuk menyiapkan topologi replikasi yang mencakup kedua zona.
Di sini kita menggunakan ClusterControl untuk mengelola failover. Untuk memecahkan skenario split-brain antara zona ketersediaan, kami menempatkan ClusterControl aktif dengan master. Kami juga membuat daftar hitam slave di zona ketersediaan lain untuk memastikan bahwa failover otomatis tidak akan menghasilkan dua master yang tersedia.
Beberapa pusat data, replikasi MySQL
Dalam contoh ini kami menggunakan tiga pusat data dan Orchestrator/Raft untuk perhitungan kuorum. Anda mungkin harus menulis skrip Anda sendiri untuk mengimplementasikan STONITH jika master berada di segmen infrastruktur yang dipartisi. ClusterControl digunakan untuk pemulihan node dan fungsi manajemen.
Beberapa pusat data, Galera Cluster
Dalam hal ini kami menggunakan tiga pusat data dengan arbiter Galera di yang ketiga - ini memungkinkan untuk menangani kegagalan seluruh pusat data dan mengurangi risiko pemartisian jaringan karena pusat data ketiga dapat digunakan sebagai relai.
Untuk bacaan lebih lanjut, lihat buku putih “Cara Mendesain Lingkungan Basis Data Sumber Terbuka yang Sangat Tersedia” dan tonton tayangan ulang webinar “Merancang Basis Data Sumber Terbuka untuk Ketersediaan Tinggi”.
