Aurora Mysql 5.7.mysql_aurora.2.07.2 を使用していますが、大規模なワークロードを書き込む負荷テストでボトルネックに直面しています。 Performance Insights を有効にすると、多数のセッションがイベント wait/synch/cond/sql/MYSQL_BIN_LOG::COND_done を待機していることに気付きました。
AWS ドキュメントを確認した後、これは大量のコミットが原因であると思いました。私のコードベースではこれが当てはまりますが、すべての wait/synch/*/sql/MYSQL_BIN_LOG、説明は基本的に次のとおりです。一般的な イベントですが、特定の COND_DONE イベントをトリガーする正確な状況が Mysql または Aurora のドキュメントで見つかりません。
マックスの答えは正しいです。私のユースケースでは、レプリケーションに binlog を使用しているのではなく、変更データのキャプチャに使用しているため、運用環境ではこれをオフにすることができません。
Aurora MySQL を 2.10 にアップグレードすると、binlog I/O キャッシュの導入により、この問題は解決されました。 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_* パラメーターを使用します。 「