J'utilise Aurora Mysql 5.7.mysql_aurora.2.07.2 et je suis confronté à un goulot d'étranglement dans un test de charge qui écrit une charge de travail importante. Lors de l'activation de Performance Insights, j'ai remarqué un grand nombre de sessions en attente de l'événement wait/synch/cond/sql/MYSQL_BIN_LOG::COND_done.
Après avoir parcouru la documentation AWS, j'ai pensé que cela était dû à un grand nombre de commits, ce qui est le cas dans ma base de code, mais pour tout wait/synch/*/sql/MYSQL_BIN_LOG l'explication est essentiellement un événement générique , mais je Je ne trouve pas la situation exacte qui déclenche un événement COND_DONE spécifique dans la documentation de Mysql ou Aurora.
La réponse de Max est correcte. Pour mon cas d'utilisation, je n'utilise pas binlog pour la réplication, mais je modifie la capture de données et je ne peux pas la désactiver en production.
La mise à niveau d'Aurora MySQL vers la version 2.10 a résolu ce problème pour nous grâce à l'introduction du cache d'E/S binlog. https://aws.amazon.com/blogs/database/introducing-binlog-i-o-cache-in-amazon-aurora-mysql-to-improve-binlog-performance/
J'ai détaillé l'ensemble du processus de débogage et de résolution de ce problème ici. https://blog.hotstar. com/de-bottlenecking-aurora-mysql-for-19 millions d'utilisateurs simultanés-ee98d6247cfe
Voici ce qu'il y a dans la documentation - il s'agit d'une section relativement nouvelle et elle concerne uniquement les ajustements des événements en attente :
https://docs.aws.amazon .com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Waitevents.html
"synch/cond/sql/MYSQL_BIN_LOG::COND_done - La journalisation binaire est activée. Il peut y avoir un débit de validation élevé, un grand nombre de validations de transactions ou des réplicas lisant le journal binaire. Pensez à utiliser des relevés multilignes ou à regrouper des relevés dans une transaction. Dans Aurora, utilisez la base de données globale au lieu de la réplication des journaux binaires ou utilisez les paramètres aurora_binlog_*. »