背景與問題

運維工程師經(jīng)常會遇到這樣的場景：MySQL 服務器的磁盤空間告警，但查看數(shù)據(jù)目錄時發(fā)現(xiàn)數(shù)據(jù)庫本身并不大。大量磁盤空間被未知文件消耗。通過排查發(fā)現(xiàn)，二進制日志（Binary Log）是主要的磁盤空間消耗者。

二進制日志是 MySQL 復制和數(shù)據(jù)恢復的核心組件，但如果管理不當，它會迅速占滿磁盤空間。本文系統(tǒng)講解二進制日志的工作原理、磁盤空間問題的成因、排查方法以及最佳實踐。

本文基于 MySQL 8.0.36 版本，操作系統(tǒng)為 Ubuntu 24.04 LTS。所有命令和配置均經(jīng)過實際環(huán)境驗證。

一、二進制日志基礎

1.1 二進制日志的作用

二進制日志記錄了所有修改數(shù)據(jù)庫數(shù)據(jù)的操作，包括：

數(shù)據(jù)修改語句：INSERT、UPDATE、DELETE。

數(shù)據(jù)定義語句：CREATE、ALTER、DROP（可配置）。

服務器運行時事件：如主從復制中的心跳事件。

二進制日志的主要用途：

主從復制：從服務器通過讀取主服務器的二進制日志來同步數(shù)據(jù)。

數(shù)據(jù)恢復：使用 mysqlbinlog 工具可以恢復指定時間點的數(shù)據(jù)。

增量備份：結合全量備份和二進制日志實現(xiàn)增量備份。

審計：可以用于審計數(shù)據(jù)庫的變更歷史。

1.2 二進制日志的文件結構

二進制日志文件名格式：mysql-bin.000001、mysql-bin.000002等。

# 查看二進制日志目錄
ls -lh /var/log/mysql/

# 二進制日志文件列表
mysql -u root -p -e"SHOW BINARY LOGS;"

# 當前使用的二進制日志
mysql -u root -p -e"SHOW MASTER STATUS;"

每個二進制日志文件包含多個日志事件（Event），日志事件分為幾種類型：

Format_description：格式描述事件，記錄 MySQL 版本信息。

Table_map：表映射事件，記錄操作涉及的表。

Write_rows/Update_rows/Delete_rows：行事件，記錄實際的數(shù)據(jù)變更。

Xid：事務提交事件。

1.3 二進制日志格式

MySQL 8.0 支持三種二進制日志格式：

ROW：記錄行的變更，完整且安全，但日志量較大。

STATEMENT：記錄 SQL 語句，節(jié)省空間，但可能有不確定結果。

MIXED：混合模式，默認使用 STATEMENT，在不確定結果時切換到 ROW。

-- 查看當前二進制日志格式
SHOWVARIABLESLIKE'binlog_format';
-- +---------------+-------+
-- | Variable_name | Value |
-- +---------------+-------+
-- | binlog_format | ROW  |
-- +---------------+-------+

-- 設置二進制日志格式（臨時生效）
SETGLOBALbinlog_format ='ROW';

-- 永久生效需要在配置文件中設置
-- binlog_format = ROW

二、二進制日志磁盤空間問題

2.1 問題場景描述

某生產(chǎn)環(huán)境 MySQL 服務器磁盤空間告警，/var/lib/mysql 目錄占用 500GB，但實際數(shù)據(jù)只有 80GB。

排查后發(fā)現(xiàn)，二進制日志占用超過 400GB，這些日志包含了過去半年的所有數(shù)據(jù)變更記錄。

這是一個典型案例：沒有配置二進制日志清理策略，導致日志無限增長。

2.2 二進制日志增長速度分析

二進制日志的增長速度取決于以下因素：

業(yè)務負載：寫操作越頻繁，日志增長越快。

日志格式：ROW 格式比 STATEMENT 格式日志量更大。

表的數(shù)據(jù)量：大表的小更新在 ROW 格式下也會產(chǎn)生大量日志。

-- 查看當前二進制日志總大小
SELECT
 SUM(FILE_SIZE) /1024/1024/1024AStotal_size_gb
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG';

-- 查看每個二進制日志文件的大小
SELECT
  LOG_NAMEASfile_name,
  FILE_SIZE /1024/1024ASsize_mb
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG'
ORDERBYLOG_NAME;

# 也可以直接查看文件大小
ls -lh /var/log/mysql/mysql-bin.* | tail -20
du -sh /var/log/mysql/

2.3 二進制日志清理機制

MySQL 提供兩種二進制日志清理機制：

自動清理：通過 expire_logs_days 參數(shù)設置。

手動清理：通過 PURGE BINARY LOGS 命令刪除。

-- 查看自動清理配置
SHOWVARIABLESLIKE'expire_logs_days';
-- 默認值是 0，表示不自動清理

-- 設置自動清理（保留最近 7 天）
SETGLOBALexpire_logs_days =7;

-- 永久生效需要在配置文件中設置
-- expire_logs_days = 7

2.4 手動清理二進制日志

-- 刪除指定時間之前的日志
PURGEBINARYLOGSBEFORE'2026-01-01 0000';

-- 刪除指定日志文件之前的所有日志
PURGEBINARYLOGSTO'mysql-bin.000100';

-- 查看當前日志文件
SHOWMASTERSTATUS;

清理時需要注意：

不要刪除還沒被從服務器讀取的日志，否則從服務器會中斷復制。

先在主服務器上執(zhí)行 SHOW SLAVE STATUS，確認從服務器已經(jīng)讀取到要刪除的位置。

-- 檢查從服務器狀態(tài)
SHOWSLAVESTATUSG
-- 查看 Master_Log_File 和 Relay_Master_Log_File 字段
-- 確保主服務器上要刪除的日志文件名在這些字段之后

三、磁盤空間問題排查步驟

3.1 初步診斷

# 查看磁盤使用情況
df -h

# 查看 MySQL 數(shù)據(jù)目錄占用
du -sh /var/lib/mysql/*

# 查看 MySQL 日志目錄
du -sh /var/log/mysql/*

3.2 二進制日志占用分析

-- 查看所有二進制日志文件及大小
mysql -u root -p -e "
SELECT
  LOG_NAME,
  FILE_SIZE /1024/1024ASsize_mb,
  (SELECTCOUNT(*)FROMinformation_schema.FILES)AStotal_files
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG'
ORDERBYLOG_NAME;
"

-- 統(tǒng)計總大小
mysql -u root -p -e "
SELECT
 COUNT(*)AStotal_files,
 SUM(FILE_SIZE) /1024/1024/1024AStotal_size_gb
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG';
"

3.3 查找磁盤空間消耗源頭

如果 df 顯示磁盤占用很高但 du 顯示文件很小，可能是以下問題：

打開的文件句柄未釋放

MySQL 臨時文件未刪除

系統(tǒng)日志文件過大

# 查看 MySQL 進程打開的文件
sudo lsof -p $(pgrep mysqld) | grep -E"REG|DIR"| awk'{print $NF}'| sort | uniq | xargs -I {} ls -lh {} 2>/dev/null

# 查看 MySQL 臨時目錄
SHOW VARIABLES LIKE'tmpdir';

# 查看臨時表使用情況
SHOW STATUS LIKE'Created_tmp%';

四、復制環(huán)境中的特殊處理

4.1 主從復制架構概述

在主從復制環(huán)境中，二進制日志的管理需要格外謹慎：

主服務器：必須開啟二進制日志，記錄所有變更。

從服務器：通過 I/O 線程讀取主服務器的二進制日志，寫入本地 relay log。

從服務器：通過 SQL 線程執(zhí)行 relay log 中的事件，完成數(shù)據(jù)同步。

-- 主服務器上查看從服務器連接狀態(tài)
SHOWSLAVEHOSTS;

-- 從服務器上查看復制狀態(tài)
SHOWSLAVESTATUSG

4.2 從服務器需要開啟二進制日志嗎

從服務器是否開啟二進制日志取決于架構設計：

如果從服務器同時作為其他從服務器的主服務器，必須開啟。

如果從服務器只是用于讀負載均衡，可以關閉。

如果需要使用從服務器進行增量備份，必須開啟。

-- 查看從服務器是否開啟二進制日志
SHOWVARIABLESLIKE'log_slave_updates';
-- log_slave_updates = ON 表示從服務器會將 relay log 執(zhí)行后記錄到自己的二進制日志

4.3 復制環(huán)境下的日志清理策略

在復制環(huán)境中，清理二進制日志需要考慮從服務器的讀取進度：

-- 查看所有從服務器的狀態(tài)
SHOWSLAVEHOSTS;
-- +-----------+-------------+------+-----------+
-- | Server_id | Host    | Port | Master_id |
-- +-----------+-------------+------+-----------+
-- |     2 | slave-01  | 3306 |     1 |
-- |     3 | slave-02  | 3306 |     1 |
-- +-----------+-------------+------+-----------+

-- 查看每個從服務器讀取到哪個日志文件
SHOWSLAVESTATUSG
-- Relay_Master_Log_File: mysql-bin.000050
-- Exec_Master_Log_Pos: 12345678

安全清理策略：只刪除所有從服務器都已經(jīng)讀取完畢的日志。

-- 方式一：基于從服務器狀態(tài)自動清理
-- 使用 mysqlrpladmin 工具
-- mysqlrpladmin --master=root:pass@master-host --discover-slaves-for=master prune

-- 方式二：手動確認后清理
-- 1. 在每個從服務器上執(zhí)行 SHOW SLAVE STATUS，記錄 Relay_Master_Log_File
-- 2. 在主服務器上找到最早的日志文件
-- 3. 使用 PURGE BINARY LOGS TO 'mysql-bin.xxxxxx' 刪除更早的日志

4.4 GTID 模式下的日志管理

MySQL 8.0 推薦使用 GTID（Global Transaction Identifier）模式，簡化復制管理：

-- 查看 GTID 配置
SHOWVARIABLESLIKE'gtid_mode';
SHOWVARIABLESLIKE'enforce_gtid_consistency';

-- 查看當前執(zhí)行的 GTID
SELECT@@GLOBAL.gtid_executed;
SELECT@@GLOBAL.gtid_purged;

在 GTID 模式下，日志清理更加安全：

-- 查看已執(zhí)行的 GTID 集合
SHOWGLOBALVARIABLESLIKE'gtid_executed';

-- 自動清理會考慮 GTID 集合
-- PURGE BINARY LOGS 會自動跳過包含已執(zhí)行事務的日志
PURGEBINARYLOGSTO'mysql-bin.000100';
-- 上面命令會報錯，如果 mysql-bin.000100 包含未執(zhí)行的事務

五、二進制日志配置優(yōu)化

5.1 基礎配置參數(shù)

# /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
# 開啟二進制日志
log_bin = /var/log/mysql/mysql-bin

# 二進制日志格式
binlog_format = ROW

# 二進制日志緩存大?。ɑ跁挘?binlog_cache_size = 4M

# 最大二進制日志緩存大小
max_binlog_cache_size = 512M

# 單個二進制日志文件大小
max_binlog_size = 1G

# 自動清理天數(shù)
expire_logs_days = 7

# sync_binlog 控制何時將二進制日志同步到磁盤
sync_binlog = 1 # 每次事務提交后同步，最安全但性能影響大
# sync_binlog = 0 # 依賴操作系統(tǒng)刷盤，性能好但可能有數(shù)據(jù)丟失

# binlog_row_image 控制 ROW 格式下記錄哪些鏡像
binlog_row_image = FULL # 記錄所有列
# binlog_row_image = MINIMAL # 只記錄主鍵和變更的列

5.2 性能與安全的權衡

sync_binlog 參數(shù)的選擇：

sync_binlog = 1：最安全，每次事務提交都同步日志到磁盤。MySQL 崩潰時最多丟失一個事務。性能影響最大。

sync_binlog = 0：性能最好，依賴操作系統(tǒng)刷盤。MySQL 崩潰時可能丟失多個事務。

sync_binlog = N：每 N 個事務同步一次。性能和數(shù)據(jù)安全的折中。

-- 查看當前配置
SHOWVARIABLESLIKE'sync_binlog';
-- +---------------+-------+
-- | Variable_name | Value |
-- +---------------+-------+
-- | sync_binlog  | 1   |
-- +---------------+-------+

-- 設置同步策略
SETGLOBALsync_binlog =100; -- 每100個事務同步一次

5.3 二進制日志緩存優(yōu)化

binlog_cache_size 用于緩存未提交事務的二進制日志：

-- 查看二進制日志緩存使用情況
SHOWSTATUSLIKE'Binlog_cache%';
-- +-----------------------+-------+
-- | Variable_name     | Value |
-- +-----------------------+-------+
-- | Binlog_cache_disk_use | 1234 | -- 內(nèi)存緩存不夠，使用了磁盤
-- | Binlog_cache_use   | 5678 | -- 使用內(nèi)存緩存的事務數(shù)
-- +-----------------------+-------+

-- 如果 Binlog_cache_disk_use 較大，增加 binlog_cache_size
SETGLOBALbinlog_cache_size =8*1024*1024; -- 8MB

5.4 行格式下的優(yōu)化

binlog_row_image 參數(shù)影響 ROW 格式下的日志大小：

-- FULL：記錄所有列的完整數(shù)據(jù)
-- MINIMAL：只記錄主鍵和實際變更的列
-- NOBLOB：對于沒有 BLOB 列的表，不記錄 BLOB 數(shù)據(jù)

SHOWVARIABLESLIKE'binlog_row_image';
-- +------------------+-------+
-- | Variable_name  | Value |
-- +------------------+-------+
-- | binlog_row_image | FULL |
-- +------------------+-------+

-- 如果表沒有 BLOB 列，可以設置為 MINIMAL 減少日志量
SETGLOBALbinlog_row_image = MINIMAL;

六、實戰(zhàn)案例分析

6.1 案例一：未配置自動清理導致磁盤爆滿

6.1.1 問題現(xiàn)象

監(jiān)控告警：/var 分區(qū)使用率超過 90%。

SSH 登錄后檢查：du -sh /var/lib/mysql 顯示只有 200GB。

但 df -h 顯示已使用 350GB。

6.1.2 排查過程

# 查看磁盤使用
df -h /var
# Filesystem   Size Used Avail Use% Mounted on
# /dev/sda1    400G 380G  20G 95% /var

# 查看 MySQL 目錄詳情
du -sh /var/lib/mysql/*
# 78G   /var/lib/mysql/data (實際數(shù)據(jù))
# 280G  /var/lib/mysql/binlog (二進制日志)
# 12G   /var/lib/mysql/relaylog (從服務器 relay log)

# 確認二進制日志
ls -lh /var/log/mysql/mysql-bin.0* | tail -10

6.1.3 問題根因

配置文件中未設置 expire_logs_days 參數(shù)，默認為 0 表示不自動清理。

業(yè)務上線時從全量備份恢復后，從未清理過二進制日志。

沒有配置從服務器的 relay log 清理。

6.1.4 解決步驟

-- 1. 確認從服務器狀態(tài)
SHOWSLAVESTATUSG
-- Relay_Master_Log_File: mysql-bin.00150
-- Exec_Master_Log_Pos: 1234567

-- 2. 設置自動清理（保留最近 7 天）
SETGLOBALexpire_logs_days =7;

-- 3. 手動清理超過 7 天的日志
PURGEBINARYLOGSTO'mysql-bin.00150';

-- 4. 修改配置文件永久生效
-- 在 [mysqld] 段添加或修改：
-- expire_logs_days = 7

-- 5. 從服務器也需要清理 relay log
SHOWVARIABLESLIKE'relay_log_purge';
SETGLOBALrelay_log_purge =ON;

6.1.5 預防措施

在 MySQL 配置文件中始終設置 expire_logs_days。

部署監(jiān)控告警，監(jiān)控二進制日志目錄大小。

定期檢查二進制日志使用情況。

6.2 案例二：大事務導致單個日志文件過大

6.2.1 問題現(xiàn)象

某個表執(zhí)行了大表更新，導致二進制日志瞬間增長 50GB。

max_binlog_size 設置為 1GB，但單個日志文件超過 10GB。

6.2.2 排查過程

-- 查看最大的二進制日志文件
SELECT
  LOG_NAME,
  FILE_SIZE /1024/1024ASsize_mb
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG'
ORDERBYFILE_SIZEDESC
LIMIT10;

-- 查看是什么時間點開始變大
SHOWBINARYLOGS;

6.2.3 問題分析

大表更新（如 UPDATE t SET col = 'xxx' 沒有 WHERE 條件）產(chǎn)生了大量 ROW 格式日志。

max_binlog_size 只是觸發(fā)切換的條件，不是硬性限制。

大事務必須完整寫入一個二進制日志文件，不能分割。

6.2.4 解決建議

分批處理大事務：

-- 原來的一次性更新
-- UPDATE large_table SET status = 1;

-- 改為分批更新
DELIMITER //
CREATEPROCEDUREbatch_update()
BEGIN
 DECLAREbatch_sizeINTDEFAULT1000;
 DECLAREoffset_numINTDEFAULT0;
 DECLAREdoneINTDEFAULTFALSE;

  WHILE NOT doneDO
   UPDATElarge_table
   SETstatus=1
   WHEREidBETWEENoffset_numANDoffset_num + batch_size -1;

   SEToffset_num = offset_num + batch_size;

   -- 檢查是否還有未更新的記錄
    IF ROW_COUNT() < batch_size THEN
? ? ? ? ? ??SET?done =?TRUE;
? ? ? ??ENDIF;

? ? ? ??-- 提交當前批次
? ? ? ??COMMIT;
? ??ENDWHILE;
END?//
DELIMITER ;

CALL?batch_update();

6.3 案例三：從服務器 relay log 占用大量空間

6.3.1 問題現(xiàn)象

從服務器磁盤空間告警，但主服務器一切正常。

檢查發(fā)現(xiàn)從服務器的 relay-log 目錄占用 200GB。

6.3.2 排查過程

-- 在從服務器上查看 relay log 配置
SHOWVARIABLESLIKE'%relay%';
-- relay_log      = /var/lib/mysql/mysql-relay-bin
-- relay_log_purge   = ON
-- relay_log_space_limit = 0 (0 表示不限制)

-- 查看 relay log 文件
ls -lh /var/lib/mysql/mysql-relay-bin.* | head -20

6.3.3 問題根因

雖然 relay_log_purge 默認為 ON，但以下情況會導致 relay log 堆積：

復制中斷，從服務器無法執(zhí)行事件。

網(wǎng)絡問題導致從服務器長時間無法讀取主服務器的日志。

某些大事務導致單個 relay log 文件過大。

6.3.4 解決方案

-- 確保 relay log 自動清理開啟
SHOWVARIABLESLIKE'relay_log_purge';
SETGLOBALrelay_log_purge =ON;

-- 如果有復制中斷，先解決中斷問題
SHOWSLAVESTATUSG
-- 查看 Last_Error 和 Last_IO_Error 字段

-- 手動清理 relay log
STOPSLAVE;
PURGERELAYLOGS;
STARTSLAVE;

七、二進制日志監(jiān)控

7.1 監(jiān)控指標

-- 二進制日志總大小
SELECT
 COUNT(*)AStotal_files,
 SUM(FILE_SIZE) /1024/1024AStotal_mb,
 MAX(FILE_SIZE) /1024/1024ASmax_file_mb
FROMinformation_schema.FILES
WHEREFILE_TYPE ='BINARY LOG';

-- 二進制日志寫入統(tǒng)計
SHOWSTATUSLIKE'Binlog%';
-- +-----------------------+-------+
-- | Variable_name     | Value |
-- +-----------------------+-------+
-- | Binlog_cache_disk_use | 0   |
-- | Binlog_cache_use   | 1000 |
-- +-----------------------+-------+

-- 復制相關的二進制日志統(tǒng)計
SHOWSTATUSLIKE'Slave%';

7.2 監(jiān)控腳本

#!/bin/bash
# 二進制日志監(jiān)控腳本

ALERT_THRESHOLD_GB=100
LOG_DIR="/var/log/mysql"
MYSQL_USER="root"
MYSQL_PASS="YourPassword"

# 獲取二進制日志總大小
TOTAL_SIZE=$(mysql -u${MYSQL_USER}-p${MYSQL_PASS}-N -e"
SELECT SUM(FILE_SIZE) / 1024 / 1024 / 1024
FROM information_schema.FILES
WHERE FILE_TYPE = 'BINARY LOG';
")

# 比較閾值
if["$(echo "$TOTAL_SIZE > $ALERT_THRESHOLD_GB" | bc)"-eq 1 ];then
 echo"ALERT: Binary log size (${TOTAL_SIZE}GB) exceeds threshold (${ALERT_THRESHOLD_GB}GB)"
 # 發(fā)送告警通知
 # 這里可以接入郵件、短信、釘釘?shù)雀婢? exit1
fi

# 獲取最舊的日志文件
OLDEST_LOG=$(mysql -u${MYSQL_USER}-p${MYSQL_PASS}-N -e"SHOW BINARY LOGS;"| head -1 | awk'{print $1}')

# 獲取最新日志文件
NEWEST_LOG=$(mysql -u${MYSQL_USER}-p${MYSQL_PASS}-N -e"SHOW BINARY LOGS;"| tail -1 | awk'{print $1}')

echo"Binary Log Report:"
echo"Total Size:${TOTAL_SIZE}GB"
echo"Files:${OLDEST_LOG}to${NEWEST_LOG}"
echo"Oldest file:${OLDEST_LOG}"

7.3 Prometheus 監(jiān)控配置

# mysql_exporter 二進制日志監(jiān)控指標
-job_name:'mysql'
static_configs:
-targets:['localhost:9104']
relabel_configs:
-source_labels:[__address__]
 target_label:instance
 regex:'(.+):d+'
 replacement:'${1}'

八、二進制日志恢復實踐

8.1 基于時間點的恢復

# 假設需要恢復到 2026-01-15 1000 的狀態(tài)

# 1. 先找到對應的日志文件
mysqlbinlog --no-defaults --stop-datetime="2026-01-15 0959"
 /var/log/mysql/mysql-bin.000123 > /tmp/full_recovery.sql

# 2. 如果需要跳過某些錯誤
mysqlbinlog --no-defaults 
 --stop-datetime="2026-01-15 0959"
 --database=opsdb 
 /var/log/mysql/mysql-bin.000123 /var/log/mysql/mysql-bin.000124 
 > /tmp/partial_recovery.sql

# 3. 恢復數(shù)據(jù)
mysql -u root -p < /tmp/full_recovery.sql

8.2 基于位置點的恢復

# 找到需要恢復的位置點
mysqlbinlog --no-defaults --base64-output=decode-rows -v 
 /var/log/mysql/mysql-bin.000123 | grep -A 5"DROP TABLE"| head -30

# 找到位置點后
mysqlbinlog --no-defaults 
 --stop-position=12345678 
 /var/log/mysql/mysql-bin.000123 > /tmp/recovery.sql

mysql -u root -p < /tmp/recovery.sql

8.3 從從服務器恢復

如果主服務器的二進制日志不可用，可以從從服務器恢復：

-- 在從服務器上執(zhí)行
SHOWSLAVESTATUSG
-- 記錄 Master_Log_File 和 Exec_Master_Log_Pos

# 從從服務器的 relay log 恢復
mysqlbinlog --no-defaults 
 --start-position=123 
 --stop-position=12345678 
 /var/lib/mysql/mysql-relay-bin.000050 > /tmp/slave_recovery.sql

mysql -u root -p < /tmp/slave_recovery.sql

九、最佳實踐總結

9.1 配置規(guī)范

# /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
# 二進制日志基礎配置
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
max_binlog_size = 1G
expire_logs_days = 7

# 性能優(yōu)化
sync_binlog = 1000 # 性能敏感場景
binlog_cache_size = 8M
max_binlog_cache_size = 512M

# 從服務器配置
log_slave_updates = ON
relay_log_purge = ON
relay_log_recovery = ON

9.2 運維規(guī)范

每日檢查二進制日志目錄大小。

設置合理的告警閾值（建議磁盤使用的 80%）。

重要數(shù)據(jù)變更前記錄當前的二進制日志位置。

定期備份二進制日志到異地存儲。

9.3 恢復預案

每季度測試一次恢復流程。

維護最新的備份和日志位置文檔。

記錄所有大事務的日志位置，便于選擇性恢復。

總結

二進制日志是 MySQL 運維中最重要的組件之一，但也是最容易引發(fā)磁盤空間問題的組件。

理解二進制日志的工作原理是解決問題的前提：它記錄所有數(shù)據(jù)變更，用于復制和恢復，在 ROW 格式下日志量可能很大。

磁盤空間暴漲的主要原因是未配置自動清理策略。在生產(chǎn)環(huán)境中，必須設置 expire_logs_days 參數(shù)，并配置監(jiān)控告警。

復制環(huán)境下清理日志需要格外謹慎，必須確保所有從服務器已經(jīng)讀取完畢要刪除的日志文件。

大事務會產(chǎn)生大量日志，分批處理是最佳實踐。

日常監(jiān)控和定期檢查是預防問題的關鍵。配置合理的告警閾值，建立日志增長趨勢分析，才能在問題發(fā)生前發(fā)現(xiàn)端倪。