了解 BinLogDiskUsage 指標行為

我們正在使用 AWS-RDS。以下是過去 6 週二進制日誌磁碟使用情況變化的螢幕截圖。

日誌保留期為 3 天。表格每週優化和歸檔一次。我們預計 BinLogDiskUsage 幾乎是恆定的（假設 AWS 定期清除日誌）在歸檔任務期間會出現峰值。

任何人都可以解釋圖表的這種波浪性質嗎？

（冗長但不完整的答案）

圖形上下移動相當平滑。這讓我很困惑。用你最新的數字，我可以解釋一些正在發生的事情。

數據被寫入二進制日誌，直到超過max_binlog_size（在您的情況下為 128M）。此時，會創建一個新的 binlog 文件。

Slave(s) 不斷地從 binlogs 中提取數據，並且通常會跟上。但是，沒有回饋讓 Master 知道所有Slave 何時完成了 binlog 文件。因此，有一些其他機制可以刪除舊的 binlog。

使用expire_logs_days（在您的情況下為 3），將刪除超過該天數的 binlog 文件。

通常你的 2GB (1447*1396626) 會佔用大約 16 個 binlog 文件（即 /134217728）。該圖會每隔一段時間顯示 128MB 的明顯下降。

對於導致 1447 個二進制日誌而不是 16 個，我唯一能想到的就是虛假PURGE命令。請執行這些：

SHOW GLOBAL STATUS LIKE '%purge%';
SHOW GLOBAL STATUS LIKE 'Uptime';

商將說明每秒清除多少次。通常，這將接近於零。但是您的系統似乎每小時有幾個。因此，我將神秘的圖表轉換為“為什麼PURGE如此頻繁地執行”。

（如果您想對 和 進行更深入的分析，請參閱http://mysql.rjweb.org/doc.php/mysql_analysis#tuning。）STATUS``VARIABLES

更多的

1447個二進制日誌purge_logs_days_seconds = 500（5 分鐘）。這表示每次通常都會清除 1 或 2 個 binlog。該圖顯示了每週模式。一周的某個時間段非常忙碌——在 binlogs 中添加了很多內容，同時清除了 3 天前的文件，這些文件的內容要少得多。這使得圖表上升。同上。Flat 表示您正在以與刪除相同的速率添加。

我猜在 5 月的最後一周，交通或國定假日會有停頓嗎？

您提供的少量數據仍然存在矛盾。1447 並在 3 天后清除會說 3 分鐘間隔，而不是 12/小時。或者 5 天，而不是 3 天。此外，最大二進制日誌大小為 70MB（最大 128MB）意味著清除週期永遠不會清除超過 1 個文件。

系統有節奏；似乎沒有什麼大錯特錯。

引用自：https://dba.stackexchange.com/questions/242049