Dokumen ini menjelaskan beberapa arsitektur yang menyediakan ketersediaan tinggi (HA) untuk deployment MySQL di Google Cloud. HA adalah ukuran ketahanan sistem sebagai respons terhadap kegagalan infrastruktur yang mendasarinya. Dalam dokumen ini, HA memenuhi ketersediaan cluster MySQL dalam satu region cloud.
Dokumen ini ditujukan untuk administrator database, arsitek cloud, dan enginee DevOps, yang ingin mempelajari cara meningkatkan keandalan tingkat data MySQL dengan meningkatkan waktu beroperasi sistem secara keseluruhan. Dokumen ini ditujukan untuk Anda jika Anda menjalankan MySQL di Compute Engine. Jika Anda menggunakan Cloud SQL untuk MySQL, dokumen ini tidak ditujukan untuk Anda.
Untuk sistem atau aplikasi yang memerlukan status persisten untuk menangani permintaan atau transaksi, lapisan persistensi data harus tersedia agar berhasi menangani permintaan untuk kueri atau mutasi data. Jika aplikasi harus berinteraksi dengan tingkat data untuk permintaan layanan, periode nonaktif dalam tingkat data akan mencegah aplikasi melakukan tugas yang diperlukan.
Bergantung pada tujuan tingkat layanan sistem (SLO) sistem, Anda mungkin memerlukan topologi arsitektur yang memberikan tingkat ketersediaan lebih tinggi. Ada lebih dari satu cara untuk mencapai HA, tetapi secara umum Anda menyediakan infrastruktur redundan yang dapat diakses dengan cepat oleh aplikasi Anda.
Dokumen ini membahas topik berikut:
- Definisikan istilah untuk membantu Anda memahami konsep database (HA).
- Membantu Anda memahami beberapa opsi untuk topologi MySQL (HA).
- Berikan informasi kontekstual untuk membantu Anda memahami hal-hal yang harus dipertimbangkan dalam setiap opsi.
Terminologi
Ada beberapa istilah dan konsep yang merupakan standar industri dan berguna untuk memahami tujuan di luar cakupan dokumen ini.
Replikasi Proses yang digunakan untuk mencatat transaksi tulis (INSERT, UPDATE, atau
DELETE) secara andal dicatat, lalu diterapkan secara serial ke semua node database dalam topologi.
Node sumber. Semua penulisan database harus diarahkan ke node sumber. Node sumber menyediakan pembacaan dengan status terbaru dari data yang disimpan.
Node replika. Salinan online node database sumber. Perubahan direplikasi secara sinkron dari node sumber ke node replika. Anda dapat membaca dari node replika dengan pemahaman bahwa data mungkin sedikit tertunda karena jeda replika.
Jeda replikasi. Pengukuran waktu yang mengekspresikan perbedaan antara saat transaksi diterapkan ke replika dibandingkan dengan saat transaksi diterapkan ke node sumber.
Waktu beroperasi. Persentase waktu resource bekerja dan mampu mengirim respons atas permintaan.
Deteksi kegagalan. Proses mengidentifikasi bahwa telah terjadi kegagalan infrastruktur.
Failover. Proses untuk mempromosikan infrastruktur pencadangan atau standby (dalam hal ini, node replika) untuk menjadi infrastruktur utama. Dengan kata lain, selama failover, node replika menjadi node sumber.
Batas Waktu Pemulihan (RTO): Durasi, dalam elapsed real time, dapat diterima, dari perspektif bisnis, untuk penyelesaian proses failover tingkat data.
Fallback. Proses untuk mengaktifkan kembali node sumber sebelumnya setelah terjadi failover.
Penyembuhan diri sendiri. Kemampuan sistem untuk menyelesaikan masalah tanpa tindakan eksternal oleh operator manusia.
Partisi jaringan. Kondisi saat dua node dalam topologi, misalnya node sumber dan replika, tidak dapat berkomunikasi satu sama lain melalui jaringan.
Otak terbelah. Kondisi yang terjadi ketika dua node secara bersamaan percaya bahwa keduanya adalah node sumber.
Grup node. Tetapkan tugas resource komputasi yang menyediakan layanan. Untuk dokumen ini, layanan tersebut adalah tingkat persistensi data.
Saksi atau simpul kuorum. Resource komputasi terpisah yang membantu grup node menentukan tindakan yang harus dilakukan saat kondisi split-brain terjadi.
Pemilihan sumber atau pemimpin. Proses yang digunakan sekelompok node sadar termasuk node saksi, menentukan node mana yang harus menjadi node sumber.
Grup node. Tetapkan tugas resource komputasi yang menyediakan layanan. Untuk dokumen ini, layanan tersebut adalah tingkat persistensi data.
Hot standby. Node yang mewakili salinan dekat node sumber lain dan dapat menjadi node sumber baru dengan downtime minimal.
Kapan harus mempertimbangkan arsitektur dengan ketersediaan tinggi (HA)
Arsitektur dengan ketersediaan tinggi (HA) memberikan perlindungan terhadap tingkat data periode nonaktif. Memahami toleransi periode nonaktif dan konsekuensi masing-masing dari berbagai arsitektur, sangatlah penting dalam memilih opsi yang tepat untuk kasus penggunaan bisnis Anda.
Gunakan topologi HA jika Anda ingin menyediakan peningkatan waktu beroperasi tingkat data untuk memenuhi persyaratan keandalan untuk beban kerja dan layanan Anda. Untuk lingkungan yang dapat menoleransi sejumlah periode nonaktif, topologi HA akan menimbulkan biaya dan kompleksitas yang tidak perlu. Misalnya, lingkungan pengembangan atau pengujian jarang memerlukan ketersediaan tingkat database yang tinggi.
Pertimbangkan persyaratan Anda untuk ketersediaan tinggi (HA)
Biaya adalah pertimbangan penting, karena Anda akan mendapati biaya infrastruktur dan penyimpanan komputasi setidaknya dua kali lipat, untuk memenuhi HA. Saat Anda menilai kemungkinan opsi HA MySQL, pertimbangkan pertanyaan berikut:
- Layanan atau pelanggan apa yang mengandalkan tingkat data Anda?
- Berapa anggaran operasional Anda?
- Berapa biaya yang dikenakan pada bisnis Anda jika terjadi periode nonaktif di tingkat persistensi data?
- Seberapa otomatis proses yang dibutuhkan?
- Tingkat ketersediaan apa yang Anda harapkan untuk mencapai, 99,5%, 99,9%, atau 99,99%?
- Seberapa cepat yang Anda butuhkan untuk failover? Apa RTO Anda?
Hal berikut berkontribusi pada waktu pemulihan dan harus dipertimbangkan saat menetapkan RTO Anda:
- Mendeteksi pemadaman layanan
- Kesiapan instance mesin virtual (VM) sekunder
- Failover penyimpanan
- Waktu pemulihan database
- Waktu pemulihan aplikasi
Arsitektur HA MySQL
Pada tingkat yang paling dasar, HA di tingkat data terdiri dari hal-hal berikut:
- Mekanisme untuk mengidentifikasi bahwa kegagalan node sumber telah terjadi.
- Proses untuk melakukan failover saat node replika dipromosikan menjadi node sumber.
- Proses untuk mengubah perutean kueri sehingga permintaan aplikasi mencapai node sumber yang baru.
- Secara opsional, metode untuk kembali ke topologi asli menggunakan node sumber dan replika.
Dokumen ini membahas tiga arsitektur dengan ketersediaan tinggi (HA) berikut:
Selain kegagalan infrastruktur, setiap arsitektur berikut dapat membantu meminimalkan periode nonaktif jika terjadi pemadaman layanan di zona tertentu. Anda menggunakan arsitektur ini dengan perubahan Domain Name System (DNS) untuk menyediakan HA multi-region guna melindungi gangguan layanan regional, tetapi topik ini berada di luar cakupan dokumen ini.
HA dengan Persistent Disk regional
HA di tingkat data selalu bergantung pada beberapa jenis replikasi data. Replikasi paling sederhana adalah salah satu yang tidak perlu Anda kelola.
Dengan opsi penyimpanan Persistent Disk regional dari Compute Engine, Anda dapat menyediakan perangkat block storage yang memberikan replikasi data sinkron antara dua zona dalam satu region. Persistent Disk Regional memberikan elemen penyusun dasar yang kuat untuk mengimplementasikan layanan HA di Compute Engine.
Diagram berikut mengilustrasikan arsitektur HA dengan Persistent Disk regional.
Jika instance VM node sumber Anda tidak tersedia karena kegagalan infrastruktur atau pemadaman zona, Anda dapat memaksa Persistent Disk regional untuk dipasang ke instance VM di zona pencadangan Anda di region yang sama.
Untuk melakukan tugas ini, Anda harus melakukan salah satu hal berikut:
- Mulai instance VM lain di zona pencadangan tempat ketersediaan akses Persistent Disk regional bersama.
- Mempertahankan instance VM mode hot standby di zona pencadangan. Instance VM mode hot standby adalah instance VM yang berjalan dan identik dengan instance yang Anda gunakan. Setelah Anda memasang Persistent Disk regional, Anda dapat memulai mesin database.
Jika pemadaman layanan data segera diidentifikasi, operasi pemasangan paksa biasanya selesai dalam waktu kurang dari satu menit, yang berarti bahwa RTO yang diukur dalam menit dapat dicapai.
Jika bisnis Anda dapat menoleransi periode nonaktif tambahan yang diperlukan untuk mendeteksi dan mengomunikasikan pemadaman layanan, dan Anda dapat melakukan failover secara manual, maka tidak perlu mengotomatiskan prosesnya.
Jika toleransi RTO lebih rendah, Anda dapat mengotomatiskan proses deteksi dan failover. Jika Anda mengotomatiskan arsitektur ini, sistem akan menjadi lebih rumit karena ada beberapa kasus edge dalam proses failover dan fallback yang perlu Anda pertimbangkan. Untuk mengetahui informasi selengkapnya tentang implementasi arsitektur yang sepenuhnya otomatis, lihat Konfigurasi ketersediaan tinggi Cloud SQL.
Kelebihan
Ada beberapa keuntungan dalam mencapai HA dengan menggunakan Persistent Disk regional karena fitur berikut:
Arsitektur ini memberikan perlindungan simultan terhadap beberapa mode kegagalan: kegagalan infrastruktur server zona primer, degradasi penyimpanan blok zona tunggal, atau pemadaman layanan zona penuh.
Replikasi lapisan aplikasi atau database tidak diperlukan karena Persistent Disk regional menyediakan replikasi data tingkat blok berkelanjutan dan sinkron, yang dikelola sepenuhnya oleh Google Cloud. Persistent Disk regional secara otomatis mendeteksi error dan kelambatan, mengganti mode replikasi, dan melakukan pengambilan data yang direplikasi hanya ke satu zona.
Jika terjadi masalah penyimpanan di zona utama, Persistent Disk regional otomatis melakukan pembacaan dari zona sekunder. Operasi ini dapat menyebabkan peningkatan latensi baca, tetapi aplikasi Anda dapat terus beroperasi tanpa tindakan manual.
Pertimbangan
Keterbatasan arsitektur ini berkaitan dengan sifat region tunggal dari topologi ini dan beberapa batasan inheren berikut dari Persistent Disk regional:
- Persistent Disk regional hanya dapat dipasang ke satu database. Meskipun instance VM database mode standby sedang berjalan, instance tersebut tidak dapat digunakan untuk menyajikan pembacaan database.
- Teknologi dasar di balik arsitektur ini hanya memungkinkan replikasi antar-zona di region yang sama. Akibatnya, failover regional bukan sebuah opsi saat menggunakan arsitektur ini.
- Throughput write Persistent Disk regional dibagi menjadi dua bagian dibandingkan dengan Persistent Disk zonal. Pastikan batas throughput tidak melebihi toleransi yang Anda perlukan.
- Latensi write Persistent Disk regional sedikit lebih tinggi daripada Persistent Disk zonal. Sebaiknya uji workload Anda untuk memverifikasi bahwa performa write dapat diterima untuk persyaratan Anda.
- Selama peristiwa kegagalan dan menghasilkan migrasi sistem, Anda perlu memaksa Persistent Disk regional untuk dipasang ke VM zona standby. Operasi force-attach biasanya dijalankan dalam waktu kurang dari satu menit, sehingga Anda harus mempertimbangkan waktu ini saat menilai RTO Anda.
- Estimasi RTO harus memperhitungkan waktu yang diperlukan untuk lampiran paksa Persistent Disk regional dan deteksi sistem file VM dari hot-attached disk.
HA dengan mode hot standby dan node saksi
Jika Anda menginginkan failover otomatis, arsitektur yang berbeda diperlukan. Salah satu opsinya adalah men-deploy grup yang terdiri dari setidaknya dua node database, mengonfigurasi replikasi asinkron database, dan meluncurkan node saksi untuk membantu memastikan kuorum dapat dicapai selama pemilihan node sumber.
Node database sumber memproses transaksi tulis dan menyalurkan kueri baca. Proses replikasi database mengirimkan perubahan ke node replika mode hot standby online.
Karena node saksi dapat berupa mesin virtual kecil, node saksi menyediakan mekanisme berbiaya rendah untuk memastikan bahwa mayoritas kelompok tersedia untuk pemilihan node sumber.
Node grup terus menilai status node grup lainnya. Sinyal yang dipakai oleh pemeriksaan status ini setiap beberapa detik disebut detak jantung karena digunakan untuk menilai kesehatan node grup lainnya. Penilaian tepat waktu terhadap kondisi node database penting karena node database sumber yang tidak responsif harus diidentifikasi dengan cepat, sehingga failover mode hot standby dapat dimulai.
Kuorum grup node ditentukan oleh jumlah elemen pemungutan suara yang harus menjadi bagian dari keanggotaan cluster aktif agar cluster tersebut dapat dimulai dengan benar atau terus berjalan. Agar grup node mencapai kuorum dalam pemilihan node database sumber, sebagian besar node dalam grup tersebut harus berpartisipasi. Untuk melindungi dari kondisi split-brain, persyaratan mayoritas memastikan bahwa dalam peristiwa partisi jaringan, dua grup pemungutan suara tidak memiliki cukup node untuk memberikan suara.
Mayoritas grup terdiri dari (n+1)/2 node, dimana n adalah jumlah total node dalam grup. Misalnya, jika ada tiga node dalam grup, setidaknya dua node harus beroperasi untuk pemilihan node sumber. Jika ada lima node dalam satu grup, minimal diperlukan tiga node.
Grup berukuran ganjil dengan sejumlah node dalam kasus jika terdapat partisi jaringan yang mencegah komunikasi antara subgrup dari node grup. Jika grupnya genap, terdapat kemungkinan lebih besar bahwa kedua subgrup dapat memiliki mayoritas yang kurang. Jika ukuran grup ganjil, kemungkinan besar salah satu subgrup dapat memperoleh mayoritas atau tidak ada grup yang memperoleh mayoritas.
Diagram berikut membandingkan grup node yang responsif dengan grup node yang menurun.
Diagram ini menunjukkan dua grup node—grup node fungsional dan grup node yang menurun. Grup node yang berfungsi penuh dan responsif memiliki tiga anggota grup. Dalam status ini, node database sumber dan replika menyediakan tujuan yang diharapkan. Kuorum yang diperlukan untuk grup ini adalah dua node.
Grup node yang menurun menunjukkan status saat detak jantung node sumber tidak lagi dikirim karena kegagalan infrastruktur. Status ini mungkin hasil dari kegagalan instance node database sumber, atau node sumber mungkin masih berjalan. Atau, partisi jaringan mungkin mencegah komunikasi antara node sumber dan node lain dalam grup.
Apa pun penyebabnya, hasilnya adalah kedua replika dan saksi yang menentukan bahwa node sumber tidak lagi responsif. Pada tahap ini, sebagian besar grup akan melakukan pemilihan node sumber, menentukan bahwa node mode hot standby harus menjadi node sumber, dan memulai failover.
Diagram berikut menunjukkan transaksi database, replikasi, dan alur heartbeat dalam arsitektur node saksi.
Dalam diagram sebelumnya, arsitektur HA ini mengandalkan node replika mode hot standby untuk mulai memproses penulisan produksi dengan cepat setelah failover. Mekanisme failover—misalnya, promosi node sumber—dilakukan oleh node database dalam grup.
Untuk menerapkan arsitektur ini, pertimbangkan dua project berikut:
- Replikasi Grup MySQL adalah plugin open source untuk MySQL yang memfasilitasi pembuatan topologi dengan ketersediaan tinggi (HA).
- Cluster Galera dan Cluster Percona XtraDB adalah opsi open source lainnya yang dapat memberikan ketersediaan tinggi.
Kelebihan
Arsitektur mode hot standby memiliki sedikit bagian yang bergerak, langsung untuk di-deploy, dan memberikan beberapa keuntungan:
- Dengan hanya satu node saksi tambahan berbiaya rendah, failover yang sepenuhnya otomatis disediakan.
- Arsitektur ini dapat mengatasi kegagalan infrastruktur jangka panjang semudah kegagalan yang sementara (misalnya, karena reboot sistem).
- Dengan beberapa latensi replikasi terkait, HA multi-region disediakan.
Pertimbangan
Failover bersifat otomatis, tetapi tugas operasional berikut tetap ada:
- Anda mengelola replikasi antara node sumber dan node replika.
- Anda yang mengelola node saksi.
- Anda harus men-deploy dan mengelola pemilihan rute koneksi menggunakan load balancer.
- Tanpa perubahan pada logika aplikasi Anda, yang berada di luar cakupan dokumen ini, Anda tidak dapat mengarahkan operasi baca ke node replika.
HA dengan Orkestrator dan ProxySQL
Jika Anda menggabungkan komponen open source, Orchestrator dan ProxySQL, Anda memiliki arsitektur yang dapat mendeteksi pemadaman layanan dan secara otomatis melakukan failover traffic dari node sumber yang terpengaruh ke replika responsif yang baru dipromosikan.
Selain itu, Anda dapat merutekan kueri secara transparan ke node baca atau baca dan tulis yang sesuai untuk meningkatkan performa tingkat data dalam kondisi stabil.
Orchestrator adalah pengelola topologi replikasi MySQL open source dan solusi failover. Software ini memungkinkan Anda mendeteksi, membuat kueri, dan memfaktorkan ulang topologi replikasi yang kompleks, serta menyediakan deteksi kegagalan yang andal, pemulihan cerdas, dan promosi.
ProxySQL adalah proxy sadar protokol database yang bersifat open source, berperforma tinggi, dan sangat tersedia untuk MySQL. ProxySQL meningkatkan skala hingga jutaan koneksi di berbagai ratusan ribu server backend.
Diagram berikut menunjukkan gabungan arsitektur Orchestrator dan ProxySQ.
Dalam arsitektur ini, seperti yang diilustrasikan oleh diagram sebelumnya, traffic yang terikat database dirutekan oleh load balancer internal ke instance ProxySQL yang redundan. Instance ini mengarahkan traffic kepada yang mampu menulis atau membaca berdasarkan konfigurasi ProxySQL.
Orchestrator menyediakan langkah deteksi dan pemulihan kegagalan berikut:
- Orchestrator menentukan bahwa node database sumber tidak tersedia.
- Semua node replika dikueri untuk memberikan pendapat kedua tentang status node sumber.
- Jika replika memberikan penilaian yang konsisten bahwa sumber tidak tersedia, failover akan dilanjutkan.
- Seperti yang ditetapkan oleh topologi, node yang dipromosikan akan menjadi node sumber baru selama failover.
- Saat failover selesai, Orchestrator membantu memastikan bahwa jumlah node replikasi baru yang benar disediakan sesuai dengan topologi.
Replikasi yang sedang berlangsung antara database sumber di zona A dan replika database di zona alternatif membuat replika selalu terbaru dengan penulisan apa pun yang dirutekan ke sumber. Orchestrator memeriksa kondisi database sumber dan replika dengan terus mengirim heartbeats. Status aplikasi Orchestrator dipertahankan di database Cloud SQL secara terpisah. Jika diperlukan perubahan pada topologi, Orchestrator juga dapat mengirimkan perintah ke database.
ProxySQL mengarahkan traffic dengan tepat ke node sumber dan replika yang baru saat failover selesai. Layanan terus menangani alamat tingkat data menggunakan alamat IP load balancer. Alamat IP virtual dialihkan dengan lancar dari node sumber sebelumnya ke node sumber baru.
Kelebihan
Komponen arsitektur dan otomatisasi memberikan keuntungan berikut:
- Software yang digunakan dalam arsitektur ini menyediakan berbagai fitur kemampuan observasi, termasuk grafik topologi replikasi, dan visibilitas traffic kueri.
- ProxySQL dan Orchestrator berkoordinasi untuk menyediakan promosi dan failover replika otomatis.
- Kebijakan promosi replika dapat dikonfigurasi sepenuhnya. Tidak seperti konfigurasi HA lainnya, Anda dapat memilih untuk mempromosikan node replika yang spesifik menjadi sumber jika terjadi failover.
- Setelah failover, replika baru akan disediakan secara deklaratif sesuai dengan topologi.
- ProxySQL memberikan manfaat load balancing tambahan karena proxySQL secara transparan merutekan permintaan baca dan tulis ke replika dan node sumber yang sesuai berdasarkan kebijakan yang dikonfigurasi.
Pertimbangan
Arsitektur ini meningkatkan tanggung jawab operasional dan menimbulkan biaya hosting tambahan karena pertimbangan berikut:
- Orchestrator dan ProxySQL harus di-deploy dan dikelola.
- Orchestrator memerlukan database secara terpisah untuk mempertahankan status.
- Orchestrator dan ProxySQL perlu disiapkan untuk HA, sehingga terdapat kompleksitas deployment dan konfigurasi tambahan.
Selain itu, Orchestrator tidak mendukung replikasi multi-sumber, tidak mendukung semua jenis replikasi paralel, dan tidak dapat digabungkan dengan software pengelompokan seperti Galera atau Percona XtraDB. Untuk mengetahui informasi selengkapnya tentang batasan saat ini, lihat FAQ Orchestrator.
Langkah berikutnya
- Baca konfigurasi ketersediaan tinggi Cloud SQL.
- Pelajari lebih lanjut Opsi ketersediaan tinggi menggunakan persistent disk regional.
- Tinjau dokumentasi Replikasi Grup MySQL.
- Pelajari Cluster Galera atau terkait dengan Cluster Percona XtraDB.
- Tinjau dokumentasi Orchestrator.
- Pelajari lebih lanjut tentang ProxySQL.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.