MySQL 兩大高頻報錯排查實錄：TokuDB 磁盤空間保留參數與主從同步 Fatal error 1236

MySQL 兩大高頻報錯排查實錄：TokuDB 磁盤空間保留參數與主從同步 Fatal error 1236

生產環境中，TokuDB 存儲引擎因磁盤空間保留機制觸發寫入受限、主從同步因 binlog 位點不匹配報 Fatal error 1236 是兩類典型疑難雜癥。本文記錄實際排查過程、根因分析與解決方案，供同類問題參考。

案例一：TokuDB「文件系統空間極低，訪問受限」

現象

ERROR: TokuFT file system space is really low and access is restricted

寫入請求被拒絕，數據庫實際可用空間尚有餘量。

根因

TokuDB 默認保留 5% 磁盤空間（參數 tokudb_fs_reserve_percent=5），當可用空間低於該閾值時，主動限制寫入保護數據完整性。此參數為靜態參數，修改需重啟實例。

解決方案

1. 臨時緩解：清理無用日志、備份文件、臨時表空間釋放空間至閾值以上。
2. 根治調整：編輯 my.cnf 降低保留比例（如 1%）：

   [mysqld]
   tokudb_fs_reserve_percent = 1

3. 重啟 MySQL 生效：systemctl restart mysqld
4. 監控磁盤使用率，設置告警閾值（如 80%）。

參考資料

TokuDB fs_reserve_percent 參數詳解

案例二：主從同步「Fatal error 1236: Client requested master to start replication from impossible position」

現象

Slave_IO_Running: No
Last_IO_Error: Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log

從庫 IO 線程停止，無法從主庫拉取 binlog。

根因深度分析

1. 現象：從庫記錄的 Master_Log_File=99.000302, Read_Master_Log_Pos=165112917。
2. 主庫實際：通過 mysqlbinlog 99.000302 解析，文件末尾位點僅 165111351，小於從庫請求位點。
3. 原因：主庫配置 sync_binlog=0（默認），事務提交時不強制 fsync binlog 到磁盤，由 OS 緩存決定刷盤時機。主庫突發宕機重啟，OS 緩存中尚未刷盤的 binlog 丟失，導致文件實際大小小于從庫已拉取的位點。
4. 機制：Slave IO 線程讀取的是 Master Dump 線程內存中的位點（可能超前于磁盤文件），而非磁盤文件實際末尾。

解決方案

1. 快速恢復：在從庫執行 CHANGE MASTER TO 指向主庫下一個 binlog 文件的起始位點（通常為 4 或 98）：

   STOP SLAVE;
   CHANGE MASTER TO MASTER_LOG_FILE='99.000303', MASTER_LOG_POS=98;
   START SLAVE;

2. 根治配置：主庫設置 sync_binlog=1，確保每次事務提交強制刷盤，犧牲約 5 倍寫入性能換取數據零丟失（對金融/核心業務必須）。
3. 折中方案：sync_binlog=1000 或更大值，平衡性能與安全，但仍有丟失風險。

參考資料

MySQL 主從同步 error 1236 排查

舉一反三：同步報錯通用排查清單

1. 檢查 Slave_IO_Running / Slave_SQL_Running 狀態。
2. 查看從庫 Last_IO_Error / Last_SQL_Error 詳細信息。
3. 主庫 SHOW MASTER STATUS 確認當前 binlog 文件與位點。
4. 對比從庫 Relay_Master_Log_File / Exec_Master_Log_Pos 是否落後。
5. 主庫錯誤日志 .err 檢查是否有 Crash/Restart 記錄。
6. 必要時用 mysqlbinlog 解析主庫 binlog 驗證位點連續性。
7. 評估 sync_binlog、innodb_flush_log_at_trx_commit 參數與業務一致性要求匹配度。

報錯是系統在說話，讀懂日志、懂參數機制、會對比位點，是 DBA 進階的必修課。