Saya menggunakan Aurora Mysql 5.7.mysql_aurora.2.07.2 dan menghadapi kesesakan dalam ujian beban yang menulis beban kerja yang besar. Apabila mendayakan Performance Insights, saya melihat sejumlah besar sesi menunggu acara wait/synch/cond/sql/MYSQL_BIN_LOG::COND_done.
Setelah melihat dokumentasi AWS, saya fikir ini disebabkan oleh sejumlah besar komit, yang berlaku dalam pangkalan kod saya, tetapi untuk semua tunggu/segerak/*/sql/MYSQL_BIN_LOG penjelasannya pada dasarnya adalah peristiwa Generik , tetapi saya tidak dapat mencari situasi tepat yang mencetuskan peristiwa COND_DONE tertentu dalam dokumentasi untuk Mysql atau Aurora.
Jawapan Max betul. Untuk kes penggunaan saya, saya tidak menggunakan binlog untuk replikasi, tetapi menukar tangkapan data dan tidak boleh mematikannya dalam pengeluaran.
Menaik taraf Aurora MySQL kepada 2.10 menyelesaikan masalah ini untuk kami kerana pengenalan binlog I/O cache. https://aws.amazon.com/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/
Saya telah memperincikan keseluruhan proses penyahpepijatan dan membetulkan isu ini di sini. https://blog.hotstar. com/de-bottlenecking-aurora-mysql-for-19 juta pengguna serentak-ee98d6247cfe
Berikut ialah apa yang terdapat dalam dokumentasi - ini adalah bahagian yang agak baharu dan semuanya mengenai tweak pada acara menunggu:
https://docs.aws.amazon .com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Waitevents.html
"synch/cond/sql/MYSQL_BIN_LOG::COND_done - Anda telah menghidupkan pengelogan binari. Mungkin terdapat daya pemprosesan komit tinggi, jumlah komit transaksi yang besar, atau replika membaca log binari. Pertimbangkan untuk menggunakan berbilang baris penyata atau penggabungan penyata ke dalam urus niaga. Di Aurora, gunakan pangkalan data global dan bukannya replikasi log binari, atau gunakan parameter aurora_binlog_*. ”