Ich verwende Aurora Mysql 5.7.mysql_aurora.2.07.2 und stehe bei einem Lasttest vor einem Engpass, der eine große Arbeitslast schreibt. Beim Aktivieren von Performance Insights ist mir aufgefallen, dass eine große Anzahl von Sitzungen auf das Ereignis wait/synch/cond/sql/MYSQL_BIN_LOG::COND_done wartet.
Nachdem ich die AWS-Dokumentation durchgesehen hatte, dachte ich, dass dies durch eine große Anzahl von Commits verursacht wurde, was in meiner Codebasis der Fall ist, aber für alle wait/synch/*/sql/MYSQL_BIN_LOG ist die Erklärung im Wesentlichen ein generisches Ereignis, aber ich Ich kann in der Dokumentation für MySQL oder Aurora nicht die genaue Situation finden, die ein bestimmtes COND_DONE-Ereignis auslöst.
Max的回答是正确的。对于我的用例,我没有使用 binlog 进行复制,而是使用更改数据捕获,并且无法在生产中将其关闭。
由于引入了 binlog I/O 缓存,将 Aurora MySQL 升级到 2.10 为我们解决了这个问题。 https://aws.amazon.com/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/
我在这里详细介绍了调试和修复此问题的整个过程。 https://blog.hotstar。 com/de-bottlenecking-aurora-mysql-for-1900万并发用户-ee98d6247cfe
这是文档中的内容 - 这是一个相对较新的部分,所有内容都是关于等待事件的调整:
https://docs.aws.amazon .com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Waitevents.html
“synch/cond/sql/MYSQL_BIN_LOG::COND_done - 您已打开二进制日志记录。可能存在高提交吞吐量、大量事务提交或副本读取二进制日志。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中,使用全局数据库而不是二进制日志复制,或使用 aurora_binlog_* 参数。”