Pada Bagian I, kami memperkenalkan kerangka kerja Ketersediaan Tinggi (HA) untuk hosting MySQL dan membahas berbagai komponen dan fungsinya. Sekarang di Bagian II, kita akan membahas detail replikasi semisinkron MySQL dan pengaturan konfigurasi terkait yang membantu kita memastikan redundansi dan konsistensi data dalam pengaturan HA kita. Pastikan untuk memeriksa kembali Bagian III di mana kami akan meninjau berbagai skenario kegagalan yang dapat muncul dan cara framework merespons dan pulih dari kondisi ini.
Apa itu Replikasi Semisinkron MySQL?
Sederhananya, dalam konfigurasi replikasi semisinkron MySQL, master melakukan transaksi ke mesin penyimpanan hanya setelah menerima pengakuan dari setidaknya salah satu budak. Budak akan memberikan pengakuan hanya setelah peristiwa diterima dan disalin ke log relai dan juga di-flush ke disk. Ini menjamin bahwa untuk semua transaksi yang dilakukan dan dikembalikan ke klien, data ada di setidaknya 2 node. Istilah 'semi' dalam semisinkron (replikasi) disebabkan oleh fakta bahwa master melakukan transaksi setelah peristiwa diterima dan di-flush ke relai log, tetapi tidak harus dikomit ke file data pada slave. Ini berbeda dengan replikasi yang sepenuhnya sinkron, di mana transaksi akan dilakukan pada slave dan master sebelum sesi kembali ke klien.
Replikasi semisinkron, yang secara bawaan tersedia di MySQL, membantu kerangka kerja HA untuk memastikan konsistensi dan redundansi data untuk transaksi yang dilakukan. Jika terjadi kegagalan master, semua transaksi yang dilakukan pada master akan direplikasi ke setidaknya salah satu budak (disimpan ke log relai). Akibatnya, failover ke slave tersebut akan menjadi lossless karena slave sudah diperbarui (setelah log relai dari slave sepenuhnya dikuras).
Replikasi dan Pengaturan Terkait Semisinkron
Mari kita bahas beberapa pengaturan utama MySQL yang digunakan untuk memastikan perilaku optimal untuk ketersediaan tinggi dan konsistensi data dalam kerangka kerja kita.
Mengelola Kecepatan Eksekusi Budak
Pertimbangan pertama adalah menangani perilaku 'semi' replikasi semisinkron yang hanya menjamin bahwa data telah diterima dan di-flush ke log relai oleh utas I/O dari budak, tetapi tidak harus dilakukan oleh utas SQL. Secara default, utas SQL di budak MySQL adalah utas tunggal dan tidak akan dapat mengimbangi master yang multi utas. Dampak nyata dari hal ini adalah jika terjadi kegagalan master, slave tidak akan diperbarui karena utas SQL-nya masih memproses peristiwa di log relai. Ini akan menunda proses failover karena kerangka kerja kami mengharapkan slave sepenuhnya mutakhir sebelum dapat dipromosikan. Hal ini diperlukan untuk menjaga konsistensi data. Untuk mengatasi masalah ini, kami mengaktifkan budak multi-utas dengan opsi slave_parallel_workers untuk mengatur jumlah utas SQL paralel untuk memproses peristiwa di log relai.
Selain itu, kami mengonfigurasi setelan di bawah ini yang memastikan bahwa slave tidak memasuki status apa pun di mana master tidak berada:
- tipe budak-paralel =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Ini memberi kami konsistensi data yang lebih kuat. Dengan pengaturan ini, kita akan bisa mendapatkan paralelisasi dan kecepatan yang lebih baik pada slave, tetapi jika ada terlalu banyak utas paralel, overhead yang terlibat dalam koordinasi antar utas juga akan meningkat dan sayangnya dapat mengimbangi manfaatnya.
Konfigurasi lain yang dapat kita gunakan untuk meningkatkan efisiensi eksekusi paralel pada slave adalah dengan menyetel binlog_group_commit_sync_delay pada master. Dengan mengatur ini pada master, entri log biner pada master dan karenanya entri log relai pada slave akan memiliki kumpulan transaksi yang dapat diproses secara paralel oleh utas SQL. Ini dijelaskan secara rinci di blog J-F Gagné di mana ia menyebut perilaku ini sebagai 'memperlambat master untuk mempercepat budak' .
Jika Anda mengelola penerapan MySQL melalui konsol ScaleGrid, Anda memiliki kemampuan untuk terus memantau dan menerima peringatan waktu nyata tentang jeda replikasi dari slave. Ini juga memungkinkan Anda untuk menyesuaikan parameter di atas secara dinamis untuk memastikan slave bekerja sama dengan master, oleh karena itu, meminimalkan waktu Anda terlibat dalam proses failover.
Penjelasan Kerangka Ketersediaan Tinggi MySQL - Bagian IIKlik Untuk Tweet
Opsi Replikasi Semisinkron Penting
Replikasi semisinkron MySQL, sesuai desain, dapat kembali ke mode asinkron berdasarkan setelan batas waktu pengakuan slave atau berdasarkan jumlah slave berkemampuan semisinkron yang tersedia kapan saja. Mode asinkron, menurut definisi, tidak memberikan jaminan bahwa transaksi yang dilakukan direplikasi ke budak dan karenanya kehilangan master akan menyebabkan hilangnya data yang belum direplikasi. Desain default kerangka kerja ScaleGrid HA adalah untuk menghindari jatuh kembali ke mode asinkron. Mari kita tinjau konfigurasi yang memengaruhi perilaku ini.
-
rpl_semi_sync_master_wait_for_slave_count
Opsi ini digunakan untuk mengkonfigurasi jumlah budak yang harus mengirim pengakuan sebelum master semisinkron dapat melakukan transaksi. Dalam konfigurasi master-slave 3-node, kami menyetelnya ke 1 sehingga kami selalu memiliki jaminan bahwa data tersedia di setidaknya satu slave sambil menghindari dampak kinerja apa pun yang terkait dengan menunggu pengakuan dari kedua slave.
-
rpl_semi_sync_master_timeout
Opsi ini digunakan untuk mengonfigurasi jumlah waktu yang dibutuhkan master semisinkron untuk menunggu pengakuan dari slave sebelum beralih kembali ke mode asinkron. Kami menyetel ini ke nilai batas waktu yang relatif tinggi sehingga tidak ada fallback ke mode asinkron.
Karena kami beroperasi dengan 2 budak dan rpl_semi_sync_master_wait_for_slave_count disetel ke 1, kami telah memperhatikan bahwa setidaknya salah satu budak tidak mengakui dalam waktu yang wajar dan master tidak beralih ke mode asinkron selama gangguan jaringan sementara.
-
rpl_semi_sync_master_wait_no_slave
Ini mengontrol apakah master menunggu periode waktu tunggu yang dikonfigurasi oleh rpl_semi_sync_master_timeout berakhir, bahkan jika jumlah budak turun menjadi kurang dari jumlah budak yang dikonfigurasi oleh rpl_semi_sync_master_wait_for_slave_count selama periode waktu tunggu. Kami mempertahankan nilai default ON sehingga master tidak kembali ke replikasi asinkron.
Dampak Kehilangan Semua Budak Semisinkron
Seperti yang kita lihat di atas, kerangka kerja kita mencegah master beralih ke replikasi asinkron jika semua slave down atau tidak dapat dijangkau dari master. Dampak langsung dari hal ini adalah penulisan terhenti pada master yang berdampak pada ketersediaan layanan. Ini pada dasarnya seperti yang dijelaskan oleh teorema CAP tentang keterbatasan sistem terdistribusi. Teorema menyatakan bahwa, dengan adanya partisi jaringan, kita harus memilih ketersediaan atau konsistensi, tetapi tidak keduanya. Partisi jaringan, dalam hal ini, dapat dianggap sebagai budak MySQL yang terputus dari master karena mereka sedang down atau tidak dapat dijangkau.
Tujuan konsistensi kami adalah untuk memastikan bahwa untuk semua transaksi yang dilakukan, data tersedia di setidaknya 2 node. Akibatnya dalam kasus seperti itu, kerangka kerja ScaleGrid HA lebih menyukai konsistensi daripada ketersediaan. Penulisan lebih lanjut tidak akan diterima dari klien meskipun master MySQL masih akan melayani permintaan baca. Ini adalah keputusan desain sadar yang telah kami buat sebagai perilaku default yang, tentu saja, dapat dikonfigurasi berdasarkan persyaratan aplikasi.
Pastikan untuk berlangganan blog ScaleGrid agar Anda tidak ketinggalan Bagian III di mana kita akan membahas lebih banyak skenario kegagalan dan kemampuan pemulihan kerangka kerja MySQL HA . Tetap disini!!
