###一、問題來源

這是一位朋友的問題，因為前期朋友設定max_binlog_cache_size為8m，後面線上進行了修改了本引數，但是結果導致整個3節點的MGR叢集除了primary節點其他兩個second節點均掉線。大概的日誌如下：
![image.png](https://upload-images.jianshu.io/upload_images/7398834-bcc9282950415b6d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

###二、使用binlog cache的大概流程
這也是我以前寫過的一個過程。

- 開啟讀寫事務。
- 執行‘DML’語句，在‘DML’語句第一次執行的時候會分配記憶體空間給binlog cache緩衝區。
- 執行‘DML’語句期間生成的Event不斷寫入到binlog cache緩衝區。
- 如果binlog cache緩衝區已經寫滿了，則將binlog cache緩衝區的資料寫入到binlog cache臨時檔案，同時清空binlog cache緩衝區，這個臨時檔名以ML開頭。
- 事務提交，binlog cache緩衝區和binlog cache臨時檔案資料全部寫入到binary log中進行固化，釋放binlog cache緩衝區和binlog cache臨時檔案。但是注意此時binlog cache緩衝區的記憶體空間留用供下次事務使用，但是binlog cache臨時檔案被截斷為0，保留檔案描述符。其實也就是IO\_CACHE結構保留，並且保留IO\_CACHE中分配的記憶體空間和臨時檔案檔案描述符。
- 斷開連線，這個過程會釋放IO\_CACHE同時釋放其持有的binlog cache緩衝區記憶體以及持有的binlog cache臨時檔案。

###三、max_binlog_cache_size引數的作用
這部分也是我以前記錄過的。

max\_binlog\_cache\_size：修改需要使用set global進行修改，定義了binlog cache臨時檔案的最大容量。如果某個事務的Event總量大於了（max\_binlog\_cache\_size+binlog\_cache\_size）的大小那麼將會報錯，如下：
```
ERROR 1197 (HY000): Multi-statement transaction required more than 
'max_binlog_cache_size' bytes of storage; increase this mysqld variable 
and try again
```

我們在函式\_my\_b\_write可以看到如下程式碼：

```
if (pos_in_file+info->buffer_length > info->end_of_file) //判斷binlog cache臨時檔案的位置加上本次需要寫盤的資料大於info->end_of_file的大小則拋錯
  {
    errno=EFBIG;
    set_my_errno(EFBIG);
    return info->error = -1;
  }
```

其中info->end\_of\_file的大小正是來自於我們的引數max\_binlog\_cache\_size。

###四、分析問題

從second節點的報錯來看，是applier執行緒應用的事務超過了max_binlog_cache_size設定的大小，但是朋友已經修改了其大小，並且主庫並沒有報這個錯誤。
我們知道MGR applier執行緒從啟動MGR的那一刻開始就不會停止，類似的master-slave的sql執行緒也是一樣，我們修改引數是透過set global修改的引數，但是實際上在對於MGR的applier執行緒並不會生效。
但是對於主庫來講，我們修改引數後只要重啟應用重新連線那麼引數就生效了，這個時候實際上primary session的max_binlog_cache_size和second applier的max_binlog_cache_size並不一致，一旦有主庫做一個稍大的事務，如果這個事務的binlog大於以前設定的值，主庫雖然能成功，但是備節點就會由於applier執行緒的max_binlog_cache_size過小而導致備節點脫離整個叢集。
對於這一點我們可以透過debug MySQL的sql執行緒進行驗證。

###五、驗證

這裡我們使用master-slave來進行驗證，我們對sql執行緒進行debug。如下，

- 當前配置

![image.png](https://upload-images.jianshu.io/upload_images/7398834-79f771cc557baaa2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- sql執行緒
![image.png](https://upload-images.jianshu.io/upload_images/7398834-944c0d227e735635.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- 修改引數
![image.png](https://upload-images.jianshu.io/upload_images/7398834-31158c4a807b1c8d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- 主庫執行一個事務，從庫執行
我們可以檢視sql執行緒binlog cache的IO CACHE的資訊如下：
![image.png](https://upload-images.jianshu.io/upload_images/7398834-a9a05d984a33c64c.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

可以看到這個值還是老值。

- 重後sql執行緒後，主庫再做一個事務觀察

![image.png](https://upload-images.jianshu.io/upload_images/7398834-e17a0478ad3725b6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

很明顯我們剛才修改的值重啟sql執行緒後才生效。
因此故障原因得到證明。

MySQL：MGR修改max_binlog_cache_size引數導致異常

相關文章