BinLogDiskUsageメトリックの動作について
AWS-RDSを使用しています。以下は、過去6週間でのバイナリログのディスク使用量の変化のスクリーンショットです。
ログの保持期間は3日です。テーブルは最適化され、週に1回アーカイブされます。 BinLogDiskUsageはほぼ一定であり（AWSによるログの定期的なパージを想定）、アーカイブタスク中にスパイクが発生すると想定していました。
グラフのこの波状の性質を誰かが説明できますか？
（長いが、不完全な答え）
グラフはスムーズに上下に移動します。これは私を困惑させました。あなたの最新の数字で、何が起こっているのかいくつかを説明できます。
データはmax_binlog_size（あなたの場合128M）を超えるまでbinlogに書き込まれます。その時点で、新しいbinlogファイルが作成されます。
スレーブはバイナリログから継続的にデータをプルし、通常は継続します。ただし、スレーブがbinlogファイルでallを終了したときにマスターに通知するフィードバックはありません。そのため、代わりに、古いバイナリログを削除するための他のメカニズムがあります。
expire_logs_days（ここでは3）を使用すると、その日数より古いbinlogファイルが削除されます。
通常、2GB（1447 * 1396626）は約16のbinlogファイル（/ 134217728）を占有します。そして、グラフは時々128MBの明確な低下を示します。
16の代わりに1447のbinlogに導くために私が考えることができる唯一のことは、偽のPURGEコマンドです。これらを実行してください：
SHOW GLOBAL STATUS LIKE '%purge%';
SHOW GLOBAL STATUS LIKE 'Uptime';
商は、1秒あたりのパージ数を示します。通常、これはゼロに近くなります。しかし、システムには1時間に数個あるようです。それで、私は不思議なグラフを「なぜPURGEが頻繁に実行されるのか」に変換しました。
（STATUSとVARIABLESの詳細な分析が必要な場合は、 http://mysql.rjweb.org/doc.php/mysql_analysis#tuning を参照してください。）
もっと
purge_logs_days_seconds = 500を含む1447個のバイナリログ（5分）。これは通常、毎回1つまたは2つのbinlogが削除されることを示しています。グラフは、weeklyパターンを示しています。週の一部はかなり忙しいです-はるかに少ない3日間の古いファイルをパージしながらビンログに多くを追加します。これにより、グラフが上がります。ダウンの同上。フラットは、削除しているのと同じレートで追加していると言います。
5月の最後の週に交通量が少なかった、または国民の祝日があったのでしょうか。
あなたが提供した小さなデータにはまだ矛盾があります。 1447で、3日後にパージすると、1時間あたり12ではなく3分間隔になります。または3日ではなく5日。また、最大binlogサイズが70MB（最大128MBのうち）の場合、パージサイクルで複数のファイルがパージされることはありません。
システムにはリズムがあります。ひどく間違っているようには見えません。