Replikasi di MySQL telah ada sejak lama, dan terus meningkat selama bertahun-tahun. Itu lebih seperti evolusi daripada revolusi. Hal ini sangat dapat dimengerti, karena replikasi adalah fitur penting yang menjadi sandaran banyak orang - ia harus berfungsi.
Dalam versi MySQL terakhir, kami telah melihat peningkatan kinerja replikasi melalui dukungan untuk menerapkan transaksi secara paralel. Di MySQL 5.6, paralelisasi dilakukan pada level skema - semua transaksi yang telah dieksekusi dalam skema terpisah dapat dieksekusi sekaligus. Ini adalah peningkatan yang bagus untuk beban kerja yang memiliki banyak skema pada satu server, dan beban didistribusikan kurang lebih secara merata di seluruh skema.
Di MySQL 5.7, metode paralelisasi lain ditambahkan, yang disebut "jam logis". Itu memungkinkan untuk mendapatkan beberapa tingkat konkurensi pada budak, bahkan jika semua data Anda telah disimpan dalam satu skema. Singkatnya, itu didasarkan pada kenyataan bahwa beberapa transaksi akan dilakukan bersama karena latensi yang ditambahkan oleh perangkat keras. Anda bahkan dapat menambahkan latensi tersebut secara manual, untuk mencapai paralelisasi yang lebih baik pada slave menggunakan binlog_group_commit_sync_delay.
Solusi ini sangat bagus tetapi bukan tanpa kekurangan. Setiap penundaan dalam melakukan transaksi pada akhirnya dapat memengaruhi bagian aplikasi yang dihadapi pengguna. Tentu, Anda dapat menyetel penundaan dalam rentang beberapa milidetik, tetapi meskipun demikian, latensi tambahan inilah yang memperlambat aplikasi.
Peningkatan Kinerja Replikasi di MySQL 8.0
MySQL 8.0, yang sampai sekarang (Agustus 2017) masih dalam status beta, membawa beberapa perbaikan bagus untuk replikasi. Awalnya, ini dikembangkan untuk Replikasi Grup (GR), tetapi karena GR menggunakan replikasi reguler di bawah tenda, replikasi MySQL "normal" diuntungkan darinya. Peningkatan yang kami sebutkan adalah informasi pelacakan ketergantungan yang disimpan dalam log biner. Apa yang terjadi adalah MySQL 8.0 sekarang memiliki cara untuk menyimpan informasi tentang baris mana yang terpengaruh oleh transaksi tertentu (disebut writeset), dan membandingkan writeset dari transaksi yang berbeda. Hal ini memungkinkan untuk mengidentifikasi transaksi-transaksi yang tidak bekerja pada subset baris yang sama dan, oleh karena itu, ini dapat diterapkan secara paralel. Ini memungkinkan untuk meningkatkan tingkat paralelisasi beberapa kali dibandingkan dengan implementasi dari MySQL 5.7. Yang perlu Anda ingat adalah, pada akhirnya, seorang budak akan melihat tampilan data yang berbeda, yang tidak pernah muncul di master. Ini karena transaksi dapat diterapkan dalam urutan yang berbeda dari pada master. Ini seharusnya tidak menjadi masalah. Implementasi replikasi multithreaded saat ini di MySQL 5.7 juga dapat menyebabkan masalah ini kecuali Anda secara eksplisit mengaktifkan slave-preserve-commit-order.
Untuk mengontrol perilaku baru ini, variabel binlog_transaction_dependency_tracking telah diperkenalkan. Ini dapat mengambil tiga nilai:
- COMMIT_ORDER:ini adalah default, menggunakan mekanisme default yang tersedia di MySQL 5.7.
- WRITESET:Ini memungkinkan paralelisasi yang lebih baik dan master mulai menyimpan data writeset dalam log biner.
- WRITESET_SESSION:Ini memastikan bahwa transaksi akan dijalankan pada slave secara berurutan dan masalah dengan slave yang melihat status database yang tidak pernah terlihat pada master dihilangkan. Ini mengurangi paralelisasi tetapi masih dapat memberikan throughput yang lebih baik daripada pengaturan default.
Tolok ukur
Pada bulan Juli, di mysqlhighavailability.com, Vitor Oliveira menulis posting di mana ia mencoba mengukur kinerja mode baru. Dia menggunakan skenario kasus terbaik - tidak ada daya tahan sama sekali, untuk menunjukkan perbedaan antara mode lama dan baru. Kami memutuskan untuk menggunakan pendekatan yang sama, kali ini dalam pengaturan yang lebih nyata:log biner diaktifkan dengan log_slave_updates. Pengaturan daya tahan dibiarkan default (jadi, sync_binlog=1 - itu default baru di MySQL 8.0, buffer penulisan ganda diaktifkan, checksum InnoDB diaktifkan, dll.) Satu-satunya pengecualian dalam daya tahan adalah innodb_flush_log_at_trx_commit disetel ke 2.
Kami menggunakan instans m4.2xl, 32G, 8 core (jadi slave_parallel_workers disetel ke 8). Kami juga menggunakan skrip sysbench, oltp_read_write.lua. 16 juta baris dalam 32 tabel disimpan pada volume gp2 1000GB (itu 3000 IOPS). Kami menguji kinerja semua mode untuk 1, 2, 4, 8, 16 dan 32 koneksi sysbench bersamaan. Prosesnya sebagai berikut:stop slave, jalankan 100k transaksi, mulai slave dan hitung berapa lama waktu yang dibutuhkan untuk menghapus slave lag.
Pertama-tama, kita tidak benar-benar tahu apa yang terjadi ketika sysbench dieksekusi menggunakan 1 utas saja. Setiap tes dilakukan lima kali setelah lari pemanasan. Konfigurasi khusus ini telah diuji dua kali - hasilnya stabil:beban kerja single-threaded adalah yang tercepat. Kami akan menyelidikinya lebih lanjut untuk memahami apa yang terjadi.
Selain itu, selebihnya hasilnya sesuai dengan apa yang kami harapkan. COMMIT_ORDER adalah yang paling lambat, terutama untuk lalu lintas rendah, 2-8 utas. Performa WRITESET_SESSION biasanya lebih baik daripada COMMIT_ORDER tetapi lebih lambat daripada WRITESET untuk lalu lintas serentak yang rendah.
Bagaimana itu bisa Membantu saya?
Keuntungan pertama jelas:jika beban kerja Anda lambat namun slave Anda cenderung mundur dalam replikasi, mereka dapat memperoleh manfaat dari peningkatan kinerja replikasi segera setelah master ditingkatkan ke 8.0. Dua catatan di sini:pertama - fitur ini kompatibel ke belakang dan 5.7 budak juga dapat memanfaatkannya. Kedua - pengingat bahwa 8.0 masih dalam status beta, kami tidak menganjurkan Anda untuk menggunakan perangkat lunak beta pada produksi, meskipun sangat membutuhkan, ini adalah opsi untuk menguji. Fitur ini dapat membantu Anda tidak hanya ketika budak Anda tertinggal. Mereka mungkin sepenuhnya terjebak tetapi ketika Anda membuat budak baru atau memperbaiki yang sudah ada, budak itu akan tertinggal. Memiliki kemampuan untuk menggunakan mode “WRITESET” akan membuat proses penyediaan host baru menjadi lebih cepat.
Secara keseluruhan, fitur ini akan memiliki dampak yang jauh lebih besar yang mungkin Anda pikirkan. Mengingat semua tolok ukur yang menunjukkan kemunduran kinerja saat MySQL menangani lalu lintas dengan konkurensi rendah, apa pun yang dapat membantu mempercepat replikasi di lingkungan seperti itu merupakan peningkatan besar.
Jika Anda menggunakan master perantara, ini juga merupakan fitur yang harus dicari. Setiap master perantara menambahkan beberapa serialisasi ke dalam bagaimana transaksi ditangani dan dieksekusi - di dunia nyata, beban kerja pada master perantara hampir selalu kurang paralel daripada pada master. Memanfaatkan writeset untuk memungkinkan paralelisasi yang lebih baik tidak hanya meningkatkan paralelisasi pada master perantara tetapi juga dapat meningkatkan paralelisasi pada semua budaknya. Bahkan mungkin (walaupun akan memerlukan pengujian serius untuk memverifikasi semua bagian akan cocok dengan benar) untuk menggunakan master perantara 8.0 untuk meningkatkan kinerja replikasi dari budak Anda (harap diingat bahwa budak MySQL 5.7 dapat memahami data writeset dan menggunakannya meskipun itu tidak dapat menghasilkannya sendiri). Tentu saja, mereplikasi dari 8.0 ke 5.7 terdengar cukup rumit (dan itu bukan hanya karena 8.0 masih beta). Dalam beberapa keadaan, ini mungkin berhasil dan dapat mempercepat penggunaan CPU pada 5.7 slave Anda.
Perubahan Lain pada Replikasi MySQL
Memperkenalkan writeset, meskipun ini yang paling menarik, bukan satu-satunya perubahan yang terjadi pada replikasi MySQL di MySQL 8.0. Mari kita lihat beberapa perubahan penting lainnya. Jika Anda menggunakan master yang lebih lama dari MySQL 5.0, 8.0 tidak akan mendukung format log binernya. Kami tidak berharap untuk melihat banyak pengaturan seperti itu, tetapi jika Anda menggunakan beberapa MySQL yang sangat lama dengan replikasi, ini adalah waktu yang tepat untuk meningkatkan.
Nilai default telah diubah untuk memastikan bahwa replikasi seaman mungkin:master_info_repository dan relay_log_info_repository diatur ke TABEL. Kedaluwarsa_log_days juga telah diubah - sekarang nilai defaultnya adalah 30. Selain expire_log_days , variabel baru telah ditambahkan, binlog_expire_log_seconds , yang memungkinkan kebijakan rotasi binlog yang lebih halus. Beberapa stempel waktu tambahan telah ditambahkan ke log biner untuk meningkatkan kemampuan pengamatan jeda replikasi, memperkenalkan granularitas mikrodetik.
Dengan segala cara, ini bukan daftar lengkap perubahan dan fitur yang terkait dengan replikasi MySQL. Jika Anda ingin mempelajari lebih lanjut, Anda dapat memeriksa log perubahan MySQL. Pastikan Anda meninjau semuanya - sejauh ini, fitur telah ditambahkan di semua versi 8.0.
Seperti yang Anda lihat, replikasi MySQL masih berubah dan menjadi lebih baik. Seperti yang kami katakan di awal, itu harus menjadi proses yang berjalan lambat tetapi sangat bagus untuk melihat apa yang ada di depan. Senang juga melihat pekerjaan untuk Replikasi Grup mengalir dan digunakan kembali dalam replikasi MySQL "biasa".
