Replikasi semisinkron MySQL memberikan peningkatan integritas data karena ketika komit berhasil kembali, diketahui bahwa data ada di setidaknya dua tempat – master dan slave. Dalam posting blog ini, kami meninjau beberapa konfigurasi hosting MySQL yang memengaruhi integritas data dan aspek kinerja replikasi semisinkron. Kami akan menggunakan mesin penyimpanan InnoDB dan replikasi berbasis GTID dalam set replika 3-node (master dan 2 slave), yang akan memastikan ada redundansi pada slave. Artinya, jika ada masalah dengan satu budak, kita bisa mundur di yang lain.
Konfigurasi yang Berlaku untuk Node Master dan Slave
- innodb_flust_log_at_trx_commit =1
- sync_binlog =1
Konfigurasi ini menjamin daya tahan tinggi dan pengaturan konsistensi untuk data. Artinya, setiap transaksi yang dilakukan dijamin akan ada dalam log biner dan juga log tersebut di-flush ke disk. Oleh karena itu, jika terjadi kegagalan daya atau sistem operasi crash, konsistensi data MySQL selalu terjaga.
Konfigurasi pada Master Node.
- 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 set replika 3-simpul, sebaiknya setel ini ke 1, sehingga kami selalu memiliki jaminan bahwa data tersedia di setidaknya satu slave sambil menghindari dampak kinerja apa pun yang terlibat dalam menunggu pengakuan dari kedua slave.
- rpl_semi_sync_master_timeout:
Opsi ini digunakan untuk mengonfigurasi jumlah waktu yang dibutuhkan master semisinkron untuk menunggu pengakuan slave sebelum beralih kembali ke mode asinkron. Kami merekomendasikan pengaturan ini ke jumlah besar sehingga tidak ada fallback ke mode asinkron yang kemudian mengalahkan tujuan integritas data kami. Karena kami beroperasi dengan 2 slave dan rpl_semi_sync_master_wait_for_slave_count disetel ke 1, kami dapat mengasumsikan bahwa setidaknya salah satu slave mengakui dalam jangka waktu yang wajar, sehingga meminimalkan dampak kinerja setelan ini.
Tutorial #MySQL:Integritas Data dan Pertimbangan Kinerja dalam Replikasi SemisinkronKlik Untuk TweetKonfigurasi pada Node Budak
Di slave, selalu penting untuk melacak dua posisi dengan sangat akurat:posisi utas SQL yang dijalankan saat ini di log relai, dan posisi utas IO saat ini yang menunjukkan seberapa jauh file biner mater dibaca dan disalin ke slave. Konsekuensi dari tidak mempertahankan posisi ini cukup jelas. Jika ada slave crash dan restart, utas SQL dapat mulai memproses transaksi dari offset yang salah atau utas IO dapat mulai menarik data dari posisi yang salah di log biner master. Kedua kasus ini akan menyebabkan korupsi data.
penting untuk memastikan keamanan crash dari slave melalui konfigurasi berikut:
- relay_log_info_repository =TABEL
- relay_log_recovery =AKTIF
Menyetel relai_log_info_repository ke TABLE akan memastikan posisi utas SQL diperbarui bersama dengan setiap transaksi yang dilakukan pada slave. Namun, sulit untuk mempertahankan posisi yang tepat dari IO thread dan flush ke disk. Ini karena membaca log biner master dan menulis ke log relai budak tidak didasarkan pada transaksi. Dampak pada kinerja sangat tinggi jika posisi thread IO harus diperbarui dan di-flush ke disk setelah setiap menulis ke log relai slave. Solusi yang lebih elegan adalah dengan menyetel relai_log_recovery =AKTIF, dalam hal ini, jika MySQL memulai ulang, log relai saat ini akan dianggap rusak dan baru akan ditarik dari master berdasarkan posisi utas SQL.
Terakhir namun tidak kalah pentingnya, penting untuk dicatat bahwa replikasi semisinkron memastikan bahwa data baru saja 'mencapai' salah satu budak sebelum master melakukan transaksi, dan tidak berarti bahwa transaksi dilakukan pada budak. Oleh karena itu, akan baik untuk memastikan bahwa utas SQL bekerja dengan kinerja yang baik. Dalam kasus yang ideal, utas SQL bergerak seiring dengan utas IO sehingga kami dapat memperoleh manfaat dari budak tidak hanya menerima transaksi, tetapi juga melakukan mereka. Disarankan untuk menggunakan konfigurasi slave multi-utas sehingga kita bisa mendapatkan peningkatan kinerja utas SQL budak. Konfigurasi penting untuk slave multi-utas adalah:
- slave_parallel_workers : Setel ini ke> 1 untuk mengaktifkan beberapa pekerja utas SQL budak. Berdasarkan jumlah thread yang ditulis pada master, kita dapat menentukan jumlah yang optimal untuk ini agar slave tidak lag.
- tipe budak-paralel =LOGICAL_CLOCK
- slave-preserve-commit-order =1
Konfigurasi di atas akan menjanjikan paralelisme pada slave, sementara pada saat yang sama, mempertahankan urutan transaksi seperti yang terlihat pada master.
Ringkasnya, dengan menggunakan konfigurasi di atas pada kumpulan replika MySQL kami, kami dapat mempertahankan integritas data yang tinggi bersama dengan kinerja yang optimal.
Seperti biasa, jika Anda memiliki pertanyaan, tinggalkan komentar, hubungi kami di @scalegridio di Twitter, atau kirim email kepada kami di support @scalegrid.io.
