I'm using Aurora Mysql 5.7.mysql_aurora.2.07.2 and facing a bottleneck in a load test that writes a large workload. When enabling Performance Insights, I noticed that a large number of sessions were waiting for event wait/synch/cond/sql/MYSQL_BIN_LOG::COND_done.
After looking through the AWS documentation, I thought this was caused by a large number of commits, which is the case in my codebase, but for all wait/synch/*/sql/MYSQL_BIN_LOG, The explanation is essentially a generic event, but I can't find the exact circumstances that trigger a specific COND_DONE event in the documentation for Mysql or Aurora.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Max's answer is correct. For my use case, I'm not using binlog for replication, but change data capture, and can't turn it off in production.
Upgrading Aurora MySQL to 2.10 solved this problem for us due to the introduction of binlog I/O cache. https://aws.amazon.com/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/
I've detailed the entire process of debugging and fixing this issue here. https://blog.hotstar. com/de-bottlenecking-aurora-mysql-for-19 million concurrent users-ee98d6247cfe
Here's what's in the docs - this is a relatively new section and it's all about tweaks to waiting events:
https://docs.aws.amazon .com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Waitevents.html
"synch/cond/sql/MYSQL_BIN_LOG::COND_done - You have binary logging turned on. There may be high commit throughput, large number of transaction commits, or replicas reading the binary log. Consider using multiple lines of statements or bundling statements into a transaction. In Aurora, use global database instead of binary log replication, or use the aurora_binlog_* parameters. ”