技術分享丨 關於MySQL binlog解析那些事

作為一名資料庫DBA，檢視解析 binlog 是日常工作的一部分。

但如果 binlog 檔案很多呢？如何高效解析 binlog，能否同時解析多個binlog？這個問題至關重要。

本文就針對能否同時解析多個binlog、innodb_buffer_pool_instances設定多少合適這兩個問題進行探討。

可以同時解析多個binlog嗎？

首先，答案是肯定的。

其次，當我們採用這種方式解析binlog時  $ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=2000 binlog.000001 binlog.000002 時，它的工作方式是這樣的：

• 指定binlog停止位置的引數，只對最後一個binlog 檔案生效（指定開始位置則針對第一個檔案生效）；

• 前面的binlog檔案則是全量解析；

• 如果沒有匹配的 stop-position，則向上取值最接近的position；

• 如果同時多次指定 start-position 或 stop-position，則以最後一次指定的為準；

• 如果指定的 stop-position 超出binlog的最大範圍，則會發出WARN；

• 如果 stop-position 指向的最後一個event是 table_map，也會發出WARN。

我們分別舉幾個例子看下：

a.解析多個檔案，但每次指定順序不同

$ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=1500 mgr01.001205 mgr01.001206 mgr01.001207 > /tmp/b1
$ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=1500 mgr01.001206 mgr01.001205 mgr01.001207 > /tmp/b2
$ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=1500 mgr01.001207 mgr01.001206 mgr01.001205 > /tmp/b3
$ ls -la /tmp/b*
-rw-r--r-- 1 root root 5027246 Oct 30 19:36 /tmp/b1
-rw-r--r-- 1 root root 5027246 Oct 30 19:21 /tmp/b2
-rw-r--r-- 1 root root 3126107 Oct 30 19:22 /tmp/b3
# 雖然 /tmp/b1、/tmp/b2檔案大小看起來一樣，但其MD5SUM是不同的
$ md5sum /tmp/b*
ac8e223d417310e02366d5cbfcb4a882  /tmp/b1
6a09fddd30ab210f3370613aff85571c  /tmp/b2
9e2e70e1cee5fb10860c66c2ef770c0a  /tmp/b3

b.指定stop-position，但實際會向上取值

$ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=1500 mgr01.001205 mgr01.001206 mgr01.001207 > /tmp/b1
# 檢視文字格式的binlog，發現end_log_pos最大值超過了1500
$ grep end_log_pos /tmp/b1 | tail
...
#221030 19:17:12 server id 3306  end_log_pos 1208 CRC32 0x8e5ca346      Table_map: `sbtest`.`sbtest5` mapped to number 926
#221030 19:17:12 server id 3306  end_log_pos 1624 CRC32 0x0059617f      Update_rows: table id 926 flags: STMT_END_F

c.指定stop-position對應的是table_map event，會發出WARN

$ mysqlbinlog -vvv --base64-output=decode-rows --start-position=4 --stop-position=1208 mgr01.001205
WARNING: The range of printed events ends with a row event or a table map event that does not have the STMT_END_F flag set. This might be because the last statement was not fully written to the log, or because you are using a --stop-position or --stop-datetime that refers to an event in the middle of a statement. The event(s) from the partial statement have not been written to output.
#221030 19:17:12 server id 3306  end_log_pos 1141 CRC32 0x5226ecd8      Rows_query
# UPDATE sbtest7 SET c='85585077000-51806678786-29036174562-00737528630-90333366602-59672213053-90973506235-01305133574-41639459483-63273277428' WHERE id=83642
# at 1141
#221030 19:17:12 server id 3306  end_log_pos 1208 CRC32 0x96186542      Table_map: `sbtest`.`sbtest7` mapped to number 928
ROLLBACK /* added by mysqlbinlog */ /*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

更多的規則自己摸索吧 ：）

innodb_buffer_pool_instances 設定 多少合 適

將innodb buffer pool拆分成多個instance，每個instance有獨立的free lists、flush lists、LRU list，也有獨立的mutex，有助於提升InnoDB併發效能。

當  innodb_buffer_pool_size 小於1GB時， innodb_buffer_pool_instances 預設值為1。反之，則預設值為8。

instance的設定儘量符合幾個原則：

• 首先，innodb_buffer_pool_size 大於1GB時，設定多個instance才有意義；

• 拆分後，每個instance也儘量大於1GB；

• 拆分後，每個instance必須是128MB（innodb_buffer_pool_chunk_size定義的值）的整數倍。