| Replikasi Paralel MySQL. Semua 5. 7 dan 8. 0 Detail (LOGICAL_CLOCK) dari Jean-François Gagné Show MTR merupakan puncak dari evolusi perkembangan replikasi paralel yang mengikuti jalur tersebut
Kami akan mengesampingkan, untuk saat ini, fitur pelacakan ketergantungan baru-baru ini KonteksSebelum kita membahas implementasi multi-utas, mari kita tinjau secara detail batasan replikasi dengan satu utas. Yang paling jelas adalah kapasitas pemrosesan CPU. Dengan satu utas, suatu proses terikat pada satu inti CPU. Jika pembaruan yang harus dijalankan replika adalah intensif CPU, replika kemungkinan akan tertinggal. Namun, situasi ini cukup luar biasa, beban replikasi jarang intensif CPU, setidaknya seharusnya tidak. Dengan replikasi berbasis baris, satu-satunya cara replika dapat berjalan dengan CPU tinggi adalah jika skema tidak diindeks dengan benar. Ini jelas merupakan kasus patologis Latensi operasi IO adalah batasan kinerja paling umum dari satu utas. Disk yang berputar memiliki latensi beberapa milidetik, pada dasarnya terkait dengan waktu yang dibutuhkan piringan untuk berputar dan kepala untuk bergerak ke silinder yang diinginkan. Jika latensi ini 10 md, satu utas tidak akan dapat melakukan lebih dari 100 IOP per detik. Latensi perangkat penyimpanan flash jauh lebih rendah tetapi sering diakses melalui jaringan. Latensi dengan demikian masih signifikan Untuk mengilustrasikan masalah replikasi utas tunggal, berikut adalah tolok ukur pembaruan terindeks sysbench sederhana dengan pengaturan yang peka terhadap latensi IO. Warna kuning adalah tingkat com_update untuk server utama dengan satu hingga 16 utas untuk eksekusi sysbench singkat selama dua menit. Dalam warna hijau adalah tingkat com_update yang sesuai dari replika. Area di bawah setiap kurva, untuk jumlah utas sysbench tertentu, adalah sama. Replika harus menjalankan pembaruan yang sama dan diizinkan untuk mengejar yang utama sebelum proses berikutnya dimulai. Sementara pada satu utas tarifnya sama, pada 16 utas perbedaannya sangat besar  Dalam skenario dunia nyata, kami jarang melihat lalu lintas single-threaded berjalan di server utama. Aplikasi modern mengandalkan skalabilitas bersamaan. Ini berarti replikasi single-threaded sangat mungkin mengalami kelambatan yang akan menimbulkan masalah. Pertama, kelambatan dapat mencegah penyeimbangan muatan karena replika memiliki data yang kedaluwarsa. Selain itu, failover berpotensi memakan waktu lebih lama karena replika perlu pulih dari kelambatan, dll… Hingga kedatangan MySQL 5. 6 dan khususnya 5. 7, ini adalah masalah yang terlalu akrab dengan replikasi MySQL Replikasi Per-DatabaseSebelum terjun ke analisis topik yang sebenarnya, perlu disebutkan salah satu jenis replikasi paralel yang diperkenalkan dalam versi. Ini disebut replikasi per-database atau replikasi per-skema. Diasumsikan bahwa transaksi yang berjalan dalam skema yang berbeda dapat diterapkan secara paralel pada replika. Ini adalah peningkatan kinerja yang penting, terutama di lingkungan yang terfragmentasi di mana banyak database menerima penulisan secara paralel di server utama Komitmen GrupKeterbatasan single-threaded dari replikasi MySQL bukan satu-satunya masalah terkait kinerja. Tingkat transaksi yang dapat ditangani oleh MySQL/InnoDB cukup terbatas dalam penyiapan yang sepenuhnya tahan lama. Setiap komit, meskipun implisit, diperlukan untuk menyelesaikan tiga operasi fsync. fsync mungkin adalah jenis operasi IO yang paling lambat, bahkan pada perangkat flash, ini bisa memakan waktu lebih dari satu milidetik Ketika sebuah file disinkronkan, semua buffer kotor yang tertunda dari file tersebut akan dipindahkan ke penyimpanan, bukan hanya yang ditulis oleh utas yang melakukan fsync. Jika ada 10 utas pada tahap komit, utas pertama untuk menyinkronkan file log InnoDB dan file log biner menghapus data dari semua sembilan utas lainnya. Proses ini disebut komit kelompok. Komitmen grup diperkenalkan pada 5. 6 dan sangat meningkatkan skalabilitas MySQL untuk beban kerja tersebut. Ini juga akan berdampak besar pada replikasi Replikasi Logical_clockUntuk memahami replikasi paralel, kita harus menyadari bahwa transaksi dalam komit grup bersifat independen. Transaksi yang bergantung pada transaksi lain pada tahap komit dikunci oleh InnoDB. Informasi itu sangat penting, karena memungkinkan transaksi dalam grup berkomitmen untuk diterapkan secara paralel MySQL5. 7 menambahkan penanda dalam log biner untuk menunjukkan batas komit grup dan mode replikasi baru untuk memanfaatkan penanda ini, logical_clock. Anda dapat melihat penanda ini di log biner dengan alat mysqlbinlog. Ini sebuah contoh Kerang1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 akar@ip - 172-31-10-84:~# mysqlbinlog ip-172-31-10-84-bin. 000047. grep last_committed. awk '{ cetak $11" "$12}'. lebih last_committed = 0 angka_urutan = 1 last_committed = 0 angka_urutan = 2 last_committed = 0 angka_urutan = 3 last_committed = 0 angka_urutan = 4 last_committed = 0 angka_urutan = 5 last_committed = 0 angka_urutan = 6 last_committed = 0 angka_urutan = 7 last_committed = 0 angka_urutan = 8 last_committed = 0 angka_urutan = 9 last_committed = 0 angka_urutan = 10 last_committed = 0 angka_urutan = 11 last_committed = 0 angka_urutan = 12 last_committed = 0 angka_urutan = 13 last_committed = 1 angka_urutan = 14 <= trx 1 committed alone last_committed = 1 angka_urutan = 15 last_committed = 1 angka_urutan = 16 last_committed = 1 angka_urutan = 17 last_committed = 8 angka_urutan = 18 <= trx 2 to 8 committed together last_committed = 8 angka_urutan = 19 last_committed = 8 angka_urutan = 20 last_committed = 8 angka_urutan = 21 last_committed = 8 angka_urutan = 22 last_committed = 8 angka_urutan = 23 last_committed = 17 angka_urutan = 24 <= trx 9 to 17 committed together last_committed = 17 angka_urutan = 25 Ada satu hal penting yang perlu diingat dengan replikasi multi-threaded dan logical_clock. jika Anda ingin replika menerapkan transaksi secara paralel, harus ada grup yang berkomitmen pada yang utama Konfigurasi TesIni tidak semudah kelihatannya untuk menunjukkan hasil replikasi yang bersih, bahkan dengan sesuatu yang sederhana seperti pemutakhiran yang diindeks dengan sysbench. Kita harus menunggu replikasi untuk disinkronkan dan pembilasan dengan mudah mengacaukan hasil, menambahkan banyak kebisingan. Untuk mendapatkan hasil yang lebih bersih, Anda perlu. menjalankan sysbench pendek, pembilasan tertunda, dan menunggu pembilasan selesai sebelum memulai proses baru. Meski begitu, hasilnya tidak sebersih yang kita harapkan Kami telah menggunakan instans AWS EC2 untuk tolok ukur kami bersama dengan volume EBS berbasis SSD tujuan umum gp3 yang baru. Pengaturan kami dapat diringkas sebagai berikut
Ukuran dataset dipilih lebih dari empat kali ukuran kumpulan buffer InnoDB (12GB). Karena pembaruan dilakukan secara acak, tolok ukur terikat IO, 79% dari waktu halaman perlu dibaca dari penyimpanan. Proses benchmark dipilih singkat, satu atau dua menit, untuk menghindari masalah dengan pembilasan halaman Sysbench sendiri dijalankan dari VM EC2 ketiga, c6i. contoh xlarge, untuk menghindari persaingan sumber daya dengan server basis data. Instance ini juga menghosting Percona Monitoring and Management (PMM) untuk mengumpulkan metrik kinerja server database. Figur postingan ini langsung diambil dari custom dashboard di PMM Seberapa Baik MTR?Kita telah melihat sebelumnya, keterbatasan replikasi dengan satu utas. Untuk kluster database yang sepenuhnya tahan lama, mari jalankan kembali tolok ukur pembaruan yang diindeks sysbench tetapi kali ini, replika memiliki replica_parallel_workers yang disetel ke 16 Seperti yang bisa kita lihat, replika sepenuhnya mampu mengikuti replikasi. Itu mulai tertinggal hanya ketika sysbench menggunakan utas hampir sebanyak yang telah kita definisikan di replica_parallel_workers. Perlu diingat meskipun ini adalah beban kerja yang sederhana dan terdefinisi dengan baik, beban kerja dunia nyata mungkin tidak mengalami tingkat peningkatan yang sama Biaya Daya TahanDurability adalah “D” dari singkatan ACID. Sekarang Anda harus menyadari pentingnya komitmen grup untuk skalabilitas replikasi dan cara utama untuk mencapai komitmen grup adalah daya tahan. Dua variabel mengontrol daya tahan dengan MySQL/InnoDB innodb_flush_log_at_trx_commit (1 tahan lama, 0 dan 2 tidak) sync_binlog (1 tahan lama, 0 tidak) Namun ada kasus di mana server utama yang tahan lama tidak diinginkan atau, dengan kata lain, daya tahan menyebabkan terlalu banyak latensi. Contoh dari kasus tersebut adalah perekaman klik-iklan. Yang penting dengan beban kerja ini adalah mencatat, secepat mungkin, klik pada iklan web. Saat promosi baru keluar, mungkin ada lonjakan besar dalam jumlah klik. Yang penting dalam kasus seperti itu adalah merekam klik secepat mungkin. Mampu menangkap lonjakan lebih penting daripada potensi kehilangan beberapa klik karena crash Tidak adanya daya tahan pada server utama membuatnya lebih cepat untuk penulisan kecil tetapi pada dasarnya menonaktifkan komit grup. Menjadi sangat sulit bagi replika untuk mengikuti dan kami kembali ke masalah kinerja replikasi asli Gambar berikut menunjukkan empat eksekusi sysbench masing-masing satu menit dengan 1, 2, 3, dan 4 utas. Server utama (kuning) tidak tahan lama. Meskipun replika (hijau) dikonfigurasi dengan 16 utas pekerja paralel, itu jelas tidak dapat mengikuti. Jadi, antara server primer tahan lama yang "lambat" yang memungkinkan replika untuk disimpan dan server utama tidak tahan lama yang "cepat" yang tidak dapat diikuti oleh replika, apakah ada kemungkinan kompromi? Penundaan SinkronisasiAlih-alih mengandalkan perangkat keras (fsync), bagaimana jika kita memiliki kemungkinan untuk menentukan durasi waktu pengelompokan transaksi. Inilah tujuan dari variabel binlog_group_commit_sync_delay. Variabel ini menentukan waktu, dalam mikrodetik, selama transaksi dikelompokkan. Transaksi pertama memulai penghitung waktu dan hingga kedaluwarsa, transaksi berikut dikelompokkan dengannya. Keuntungan utama dari variabel ini dibandingkan dengan perilaku aslinya adalah intervalnya dapat disetel. Gambar berikut menunjukkan hasil tidak tahan lama yang sama dengan yang sebelumnya, tetapi kali ini, penundaan pengelompokan kecil 5us ditambahkan Angka tersebut menunjukkan tingkat com_update yang sama dari primer (kuning) dan replika (hijau). Untuk beban kerja kami yang sangat sederhana, dampak pada replika dari penundaan kecil itu sangat signifikan. Dengan empat utas sysbench, laju eksekusi replika mendekati 2000/dtk, meningkat mendekati 30%. Ada juga dampak pada primer, terutama untuk jumlah utas sysbench yang lebih rendah. Tingkat pembaruan sysbench dengan satu utas lebih rendah hampir 30% dengan penundaan Jadi, biaya penambahan penundaan agak mirip dengan biaya daya tahan. Latensi transaksi meningkat dan ini memengaruhi sebagian besar beban kerja konkurensi yang rendah. Orang dapat berargumen bahwa beban kerja seperti itu bukan yang paling mungkin menyebabkan masalah kelambatan replikasi. Pada tingkat konkurensi yang lebih tinggi, saat lebih banyak utas aktif pada saat yang sama, penundaan masih ada tetapi kurang terlihat. Untuk throughput tertentu, database hanya akan menggunakan beberapa utas lagi untuk mengatasi dampak penundaan Sinkronisasi Tanpa Hitungan PenundaanMeskipun beberapa utas yang berjalan biasanya bukan masalah besar, beban kerja database sering kali menampilkan ledakan di mana jumlah utas yang berjalan tiba-tiba meningkat. Penambahan penundaan pengelompokan memperburuk keadaan dan pertengkaran bisa meningkat. Untuk menghindari masalah ini, dimungkinkan untuk mengonfigurasi primer sehingga menyerah menunggu jika terlalu banyak transaksi sudah tertunda. Variabel yang mengontrol perilaku ini adalah binlog_group_commit_sync_no_delay_count. Arti dari variabel adalah. jika jumlah transaksi yang menunggu penundaan sinkronisasi adalah nilai variabel, hentikan menunggu dan lanjutkan Variabel ini memberikan perlindungan terhadap dampak terburuk penundaan sinkronisasi. Seseorang dapat menetapkan penundaan yang agresif untuk membantu replika mengikuti beban kerja normal dan memiliki hitungan tanpa penundaan yang rendah untuk menyerap puncak. Sebagai aturan praktis, jika hitungan tanpa penundaan digunakan, maka harus disetel ke jumlah utas pekerja replika Untuk lebih memahami dampak dari nilai no-delay count, gambar berikut menunjukkan tingkat pembaruan sysbench untuk high sync delay (12ms) tetapi dengan berbagai nilai no delay count Dalam semua kasus, sysbench menggunakan 16 utas dan replika memiliki 16 utas pekerja. Nilai “0” (kiri) menonaktifkan fitur penghitungan tanpa penundaan. Ini mengarah ke tingkat yang sangat rendah pada replika utama tetapi disinkronkan dengan sempurna. Nilai "1" pada dasarnya menonaktifkan fitur penundaan sinkronisasi. Hal ini menyebabkan tingkat transaksi yang tinggi pada yang utama tetapi replikanya kesulitan. Untuk nilai yang lebih tinggi, stabilitas tarif transaksi utama mengejutkan saya. Saya mengharapkan penurunan kinerja dengan nilai hitungan tanpa penundaan yang lebih tinggi. Replika di sisi lain berperilaku seperti yang diharapkan, semakin besar pengelompokannya, semakin tinggi tingkat transaksinya KesimpulanDalam posting ini, kita membahas implementasi replikasi multi-threaded MySQL LOGICAL_CLOCK dari 5. 7 dan hubungannya dengan komitmen kelompok. Meskipun luar biasa, komitmen grup bergantung pada daya tahan dan tidak semua beban kerja dapat menangani latensi tambahan. Implementasi LOGICAL_CLOCK juga mendukung algoritme penundaan pengelompokan yang lebih fleksibel bersama dengan jumlah pengelompokan maksimum untuk beban kerja yang sensitif terhadap latensi ini Peningkatan kinerja replikasi sejak 5. 7 sangat menakjubkan. Ini membantu membuka hambatan kinerja yang telah mengganggu replikasi selama bertahun-tahun. Semoga posting ini akan membantu Anda memahami teknologi ini dan cara menyetelnya |
Cara menggunakan mysql parallel replication logical_clock
Pos Terkait
Copyright © 2024 kemunculan Inc.
