作者羅小波
沃趣科技MySQL高級數據庫技術專家
玩過binlog server的同學都知道，它使用mysqlbinlog命令以daemon進程的方式模擬一個slave的IO線程與主庫連接，可以很方便地即時同步主庫的binlog，以便彌補定時備份策略中最近一次備份到下一次備份完成之前這段時間內的數據容易丟失的問題。
-
優點：備份出來的binlog不會受到主庫expire_logs_days參數的影響，因爲binlog server是模擬slave的IO線程，也不會受到從庫relay_log_purge參數影響。這些binlog除非你手動清理，否則就會持續累計。so，你可以使用這些binlog+主庫的全備做基於時間點和pos點的數據恢復。
-
缺點：因爲binlog server是模擬slave的IO線程，所以在主庫crash的時間點，具有與真正的slave相同的來不及同步主庫最後一部分數據的風險。除此之外，binlog server本身也有bug。問題來了，這個bug是什麼bug？爲什麼會有這個bug？這個bug在等到官方修復之前，有沒有什麼替代方案？請看下文分析過程
-
背景
-
數據庫版本：5.7.18
-
數據庫關鍵配置參數
雙一，log_slave_updates，log-bin，slave_parallel_workers=16，binlog_rows_query_log_events=ON，server-id=3306250，slave_parallel_type=LOGICAL_CLOCK，slave_rows_search_algorithms='INDEX_SCAN,HASH_SCAN'，innodb_page_cleaners=4 -
數據庫IP：主庫IP 10.10.30.250，binlog server IP 10.10.30.217，下文中提到的服務器信息分別使用master和binlog server代替IP
-
服務器配置
-
CPU：16 vcpus
-
內存：64G
-
磁盤：100G flash卡
-
網卡：Speed: 100Mb/s
一 、建測試庫表
-
創建數據庫
qogir_env@localhost : (none) 03:07:20> CREATE DATABASE `xiaoboluo`;
-
創建表
qogir_env@localhost : (none) 03:07:20> CREATE TABLE `test` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`test` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`test2` varchar(100) COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
二 、使用binlog server
-
本文演示binlog server需要使用到mysqlbinlog的相關選項如下
-
–defaults-file=file_name：僅讀取該選項指定的配置文件
-
–host=host_name, -h host_name：在使用binlog server時，指定從哪臺mysql server主機上獲取二進制日誌
-
–password[=password], -p[password]：連接到服務器時使用的密碼
-
–port=port_num, -P port_num：用於連接到遠程server的TCP / IP端口號
-
–raw：默認情況下，不使用–raw選項，mysqlbinlog讀取二進制日誌文件，並解析爲文本格式輸出事件(直接打印在標準輸出中，可以使用輸出重定向到文件中，也可以使用–result-file選項指定輸出文件)， –raw選項告訴mysqlbinlog仍然以讀取binlog時的原始二進制格式輸出。該選項需要結合–read-from-remote-server選項使用
-
–read-from-remote-server, -R
1、使用該選項時，mysqlbinlog會僞裝成一個slave，連接讀取，請求指定的binlog file，主庫獲取接收到這個請求之後就創建一個binlog dump線程推送binlog給mysqlbinlog server。2、從MySQL server讀取二進制日誌，而不是讀取本地日誌文件。對於這些選項–host，–password，–port，–protocol，–socket和–user，除非給出了–read-from-remote-server選項結合使用，否則單獨指定這些TCP/IP連接選項將被忽略不生效
-
–result-file=name, -r name：不與–raw選項一併使用時，此選項指定一個mysqlbinlog解析的文本存放的文件，當單獨使用–raw選項時，mysqlbinlog會使用從遠程server傳輸的原始binlog格式寫入本地文件中，默認情況下輸出文件與原始日誌文件使用相同的文件名稱。如果與–raw選項一併使用時，–result-file選項值會修改輸出文件名的前綴，如：原本是mysql-bin.000001，使用–result-file=binlog，則輸出文件名爲binlogmysql-bin.000001
-
更多選項信息詳見官方文檔鏈接：https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog.html
2.1. binlog server原始格式轉儲
-
原始格式轉儲同步需要使用–raw選項，使用該選項時會以master實例中原始的binlog格式和文件名轉儲到binlog server本地系統指定目錄下存放，下面是演示步驟
-
登錄到master服務器的數據庫實例中，執行刷新日誌並查看日誌文件編號到多少了
qogir_env@localhost : (none) 03:13:05> flush logs;
Query OK, 0 rows affected (0.01 sec)
qogir_env@localhost : (none) 03:18:23> show binary logs;
| mysql-bin.000032 | 4721608 |
| mysql-bin.000033 | 281 |
| mysql-bin.000034 | 3273 |
| mysql-bin.000035 | 1777 |
| mysql-bin.000036 | 1777 |
| mysql-bin.000037 | 655 |
| mysql-bin.000038 | 234 |
+------------------+-----------+
38 rows in set (0.00 sec)
-
從上面可以看到，最後一個binlog file是mysql-bin.000038，記錄下這個文件名登錄到binlog server服務器中，使用mysqlbinlog如下命令啓動一個binlog server進程(帶–raw選項)
# 先創建一個用於存放binlog server轉儲的文件目錄，並進入到這個目錄下啓動mysqlbinlog進程，因爲mysqlbinlog使用--raw選項時無法指定輸出路徑，只能轉儲到工作目錄下，所以需要先使用cd命令切換路徑
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba ~]# mkdir /data/backup/binlogserver/
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba ~]# cd /data/backup/binlogserver/
# 啓動mysqlbinlog進程並掛後臺執行
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# mysqlbinlog --host=10.10.30.250 --password=password --user=admin --read-from-remote-server mysql-bin.000038 --raw --stop-never &
# 查看工作目錄，可以發現文件已經被同步過來了，此時主庫還沒有寫入任何東西
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# ll
total 4
-rw-r----- 1 root root 123 May 22 16:08 mysql-bin.000038
-
現在登錄到master的數據庫實例中，寫入幾行測試數據，留意第二次insert語句的值改爲了2017-05-23
qogir_env@localhost : (none) 03:51:47> insert into xiaoboluo.test(test) values('2017-05-22 00:03:26');
Query OK, 1 row affected (0.00 sec)
qogir_env@localhost : (none) 04:09:46> insert into xiaoboluo.test(test) values('2017-05-23 00:03:26');
Query OK, 1 row affected (0.00 sec)
qogir_env@localhost : (none) 04:09:50>
-
到binlog server中解析binlog mysql-bin.000038，查看轉儲的binlog內容
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# mysqlbinlog -vv mysql-bin.000038
...... #這裏我們直接查看最後一個事務，即最後一個BEGIN開始往後的內容即可
BEGIN
/*!*/;
# at 746
#170522 16:09:50 server id 3306250 end_log_pos 832 CRC32 0x434a1500 Rows_query
# insert into xiaoboluo.test(test) values('2017-05-23 00:03:26')
# at 832
#170522 16:09:50 server id 3306250 end_log_pos 890 CRC32 0x8fbe85a5 Table_map: `xiaoboluo`.`test` mapped to number 249
# at 890
#170522 16:09:50 server id 3306250 end_log_pos 951 CRC32 0x41154915 Write_rows: table id 249 flags: STMT_END_F
BINLOG '
zpwiWR0KczIAVgAAAEADAACAAD5pbnNlcnQgaW50byB4aWFvYm9sdW8udGVzdCh0ZXN0KSB2YWx1
ZXMoJzIwMTctMDUtMjMgMDA6MDM6MjYnKQAVSkM=
zpwiWRMKczIAOgAAAHoDAAAAAPkAAAAAAAEACXhpYW9ib2x1bwAEdGVzdAADAw8PBCwBLAEGpYW+
jw==
zpwiWR4KczIAPQAAALcDAAAAAPkAAAAAAAEAAgAD//z4wQIAEwAyMDE3LTA1LTIzIDAwOjAzOjI2
FUkVQQ==
'/*!*/;
### INSERT INTO `xiaoboluo`.`test`
### SET
### @1=180728 /* INT meta=0 nullable=0 is_null=0 */
### @2='2017-05-23 00:03:26' /* VARSTRING(300) meta=300 nullable=1 is_null=0 */ #這裏可以看到在master中寫入的第二行數據，日期爲2017-05-23的那一行
### @3=NULL /* VARSTRING(300) meta=300 nullable=1 is_null=1 */
ROLLBACK /* added by mysqlbinlog */ /*!*/; #留意這裏，這裏按照正常邏輯來講，應該是一個帶commit語句和xid號的 event，然而這裏卻是一個rollback語句
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*/;
-
從上面的結果中可以看到，master中第二個insert語句數據，binlog server通過mysqlbinlog命令轉儲之後，解析轉儲二進制日誌文件的輸出文本中並沒有打commit語句，也就是說，使用mysqlbinlog轉儲的binlog進行數據恢復時，第二個insert語句的數據將被回滾掉，導致數據丟失
-
現在，登錄到master中解析一下這個binlog文件中第二個insert數據是如何記錄的呢
[root@e710d318-d5b4-4bc7-a606-d09f06ff5f5d binlog]# mysqlbinlog -vv mysql-bin.000038
......
BEGIN
/*!*/;
# at 746
#170522 16:09:50 server id 3306250 end_log_pos 832 CRC32 0x434a1500 Rows_query
# insert into xiaoboluo.test(test) values('2017-05-23 00:03:26')
# at 832
#170522 16:09:50 server id 3306250 end_log_pos 890 CRC32 0x8fbe85a5 Table_map: `xiaoboluo`.`test` mapped to number 249
# at 890
#170522 16:09:50 server id 3306250 end_log_pos 951 CRC32 0x41154915 Write_rows: table id 249 flags: STMT_END_F
BINLOG '
zpwiWR0KczIAVgAAAEADAACAAD5pbnNlcnQgaW50byB4aWFvYm9sdW8udGVzdCh0ZXN0KSB2YWx1
ZXMoJzIwMTctMDUtMjMgMDA6MDM6MjYnKQAVSkM=
zpwiWRMKczIAOgAAAHoDAAAAAPkAAAAAAAEACXhpYW9ib2x1bwAEdGVzdAADAw8PBCwBLAEGpYW+
jw==
zpwiWR4KczIAPQAAALcDAAAAAPkAAAAAAAEAAgAD//z4wQIAEwAyMDE3LTA1LTIzIDAwOjAzOjI2
FUkVQQ==
'/*!*/;
### INSERT INTO `xiaoboluo`.`test`
### SET
### @1=180728 /* INT meta=0 nullable=0 is_null=0 */
### @2='2017-05-23 00:03:26' /* VARSTRING(300) meta=300 nullable=1 is_null=0 */ #日期爲2017-05-23的數據在這裏
### @3=NULL /* VARSTRING(300) meta=300 nullable=1 is_null=1 */
# at 951
#170522 16:09:50 server id 3306250 end_log_pos 982 CRC32 0x60d092ff Xid = 1156777
COMMIT/*!*/; # 可以看到master中記錄的binlog是正常的，代表這個事務在主庫已經正常commit了
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*/;
-
通過以上解析結果對比可以看到，mysqlbinlog同步機制使用原始格式轉儲的binlog文件中，最後一個事務原本應該是commit的語句，然而卻是rollback，爲什麼會這樣呢？稍安勿躁，稍後見第3節總結部分，這裏咱們先看看binlog server文本格式轉儲是不是也有這個問題呢？
2.2.binlog server文本格式轉儲
-
不使用–raw選項時，mysqlbinlog讀取master實例的binlog之後，在轉儲之前會解析爲文本格式的事件日誌輸出，可以使用輸出重定向到一個文件中保存，也可以使用–result-file=file選項指定一個文件進行存放，解析結果只能轉儲到同一個文件中，主庫有新的binlog產生時，會在該文件末尾持續追加，下面是演示步驟
-
登錄到binlog server服務器中，停止mysqlbinlog進程並清空/data/backup/binlogserver目錄
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# killall mysqlbinlog
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# ps aux |grep mysqlbinlog
root 11878 0.0 0.0 103252 840 pts/0 S+ 16:34 0:00 grep mysqlbinlog
[1]+ Terminated mysqlbinlog --host=10.10.30.250 --password=password --user=admin --read-from-remote-server mysql-bin.000038 --raw --stop-never
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# rm -rf *
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# ll
total 0
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]#
-
登錄到master服務器的數據庫實例中，執行刷新日誌並查看日誌文件編號到多少了
qogir_env@localhost : (none) 04:09:50> flush logs;
Query OK, 0 rows affected (0.01 sec)
qogir_env@localhost : (none) 04:35:04> show binary logs;
| mysql-bin.000034 | 3273 |
| mysql-bin.000035 | 1777 |
| mysql-bin.000036 | 1777 |
| mysql-bin.000037 | 655 |
| mysql-bin.000038 | 1029 |
| mysql-bin.000039 | 234 |
+------------------+-----------+
39 rows in set (0.00 sec)
-
從上面可以看到，最後一個binlog file是mysql-bin.000039，記錄下這個文件名登錄到binlog server服務器中，使用mysqlbinlog如下命令啓動一個binlog server進程(不帶–raw選項，添加–result-file=binlog_parse)
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba ~]# cd /data/backup/binlogserver/
# 啓動mysqlbinlog並掛後臺執行（注意：爲了演示需要，把base-64編碼解析爲可讀格式的sql語句，加上了-vv選項，實際生產環境如果要用於重放，請不要添加-vv選項）
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# mysqlbinlog --host=10.10.30.250 --password=password --user=admin --read-from-remote-server mysql-bin.000039 \
--result-file=binlog_parse --stop-never -vv &
# 查看工作目錄，可以發現目錄下多了一個binlog_parse文件，此時主庫還沒有寫入任何東西
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# ll
total 4
-rw-r----- 1 root root 741 May 22 16:38 binlog_parse
-
現在登錄到master的數據庫實例中，寫入幾行測試數據，留意這裏第二個insert的值改爲了2017-05-23
qogir_env@localhost : (none) 04:35:11> insert into xiaoboluo.test(test) values('2017-05-22 00:03:26');
Query OK, 1 row affected (0.01 sec)
qogir_env@localhost : (none) 04:39:15> insert into xiaoboluo.test(test) values('2017-05-23 00:03:26');
Query OK, 1 row affected (0.00 sec)
qogir_env@localhost : (none) 04:39:18>
-
到binlog server中查看已經被mysqlbinlog命令解析並轉儲的binlog文本文件binlog_parse
[root@4ee3a2ca-0be4-4057-a415-0ac5c05363ba binlogserver]# cat binlog_parse
...... #這裏我們直接查看最後一個事務，即最後一個BEGIN開始往後的內容即可
BEGIN
/*!*/;
# at 746
#170522 16:39:18 server id 3306250 end_log_pos 832 CRC32 0xe3c8e631 Rows_query
# insert into xiaoboluo.test(test) values('2017-05-23 00:03:26')
# at 832
#170522 16:39:18 server id 3306250 end_log_pos 890 CRC32 0x7debb044 Table_map: `xiaoboluo`.`test` mapped to number 249
# at 890
#170522 16:39:18 server id 3306250 end_log_pos 951 CRC32 0xabb8de46 Write_rows: table id 249 flags: STMT_END_F
BINLOG '
tqMiWR0KczIAVgAAAEADAACAAD5pbnNlcnQgaW50byB4aWFvYm9sdW8udGVzdCh0ZXN0KSB2YWx1
ZXMoJzIwMTctMDUtMjMgMDA6MDM6MjYnKTHmyOM=
tqMiWRMKczIAOgAAAHoDAAAAAPkAAAAAAAEACXhpYW9ib2x1bwAEdGVzdAADAw8PBCwBLAEGRLDr
fQ==
tqMiWR4KczIAPQAAALcDAAAAAPkAAAAAAAEAAgAD//z8wQIAEwAyMDE3LTA1LTIzIDAwOjAzOjI2
Rt64qw==
'/*!*/;
### INSERT INTO `xiaoboluo`.`test`
### SET
### @1=180732 /* INT meta=0 nullable=0 is_null=0 */
### @2='2017-05-23 00:03:26' /* VARSTRING(300) meta=300 nullable=1 is_null=0 */ #日期爲2017-05-23的event在這裏
### @3=NULL /* VARSTRING(300) meta=300 nullable=1 is_null=1 */
# at 951
#170522 16:39:18 server id 3306250 end_log_pos 982 CRC32 0x29f585cc Xid = 1156784
COMMIT/*!*/; #這裏可以看到commit語句在不帶--raw時被正確轉儲了
-
從上面的結果中可以看到，master中第二個insert語句插入的數據的commit標記被正確轉儲了，也就是說，binlog server通過mysqlbinlog命令轉儲的二進制日誌在不使用–raw選項時（使用文本格式轉儲時），不會導致數據丟失
-
現在，登錄到master中解析一下這個binlog文件中第二個Insert語句的數據，做個對比
[root@e710d318-d5b4-4bc7-a606-d09f06ff5f5d binlog]# mysqlbinlog -vv mysql-bin.000038
......
BEGIN
/*!*/;
# at 746
#170522 16:39:18 server id 3306250 end_log_pos 832 CRC32 0xe3c8e631 Rows_query
# insert into xiaoboluo.test(test) values('2017-05-23 00:03:26')
# at 832
#170522 16:39:18 server id 3306250 end_log_pos 890 CRC32 0x7debb044 Table_map: `xiaoboluo`.`test` mapped to number 249
# at 890
#170522 16:39:18 server id 3306250 end_log_pos 951 CRC32 0xabb8de46 Write_rows: table id 249 flags: STMT_END_F
BINLOG '
tqMiWR0KczIAVgAAAEADAACAAD5pbnNlcnQgaW50byB4aWFvYm9sdW8udGVzdCh0ZXN0KSB2YWx1
ZXMoJzIwMTctMDUtMjMgMDA6MDM6MjYnKTHmyOM=
tqMiWRMKczIAOgAAAHoDAAAAAPkAAAAAAAEACXhpYW9ib2x1bwAEdGVzdAADAw8PBCwBLAEGRLDr
fQ==
tqMiWR4KczIAPQAAALcDAAAAAPkAAAAAAAEAAgAD//z8wQIAEwAyMDE3LTA1LTIzIDAwOjAzOjI2
Rt64qw==
'/*!*/;
### INSERT INTO `xiaoboluo`.`test`
### SET
### @1=180732 /* INT meta=0 nullable=0 is_null=0 */
### @2='2017-05-23 00:03:26' /* VARSTRING(300) meta=300 nullable=1 is_null=0 */
### @3=NULL /* VARSTRING(300) meta=300 nullable=1 is_null=1 */
# at 951
#170522 16:39:18 server id 3306250 end_log_pos 982 CRC32 0x29f585cc Xid = 1156784
COMMIT/*!*/;
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*/;
-
從上面的結果中可以看到，文本格式轉儲並不會導致最後一個事務的commit被替換爲rollback，你可以使用文本格式轉儲主庫binlog，雖然避免了數據丟失，但是問題也顯而易見…就是需要進行恢復時，因爲是已經解析過的文本，所以不能使用–start-，–stop-這些選項來過濾查找你想要的數據，需要手工來完成這個工作。數據量小還好，數據量大了就…不管怎樣，也勉強算是解決了原始格式轉儲的問題。至於你要不要用，那就見仁見智了。
三、總 結
-
從2.1和2.2小節的對比演示可以看到
-
mysqlbinlog使用–raw選項以binlog日誌原始格式轉儲時，通過解析轉儲文件發現來自master的最後一個事務的commmit標記缺失了，會導致利用mysqlbinlog轉儲的binlog文件做數據恢復時，丟失最後一個事務，因爲這最後一個事務原本是commit標記的位置使用的是rollback語句，會導致這最後一個事務被回滾掉，爲什麼這個commit語句缺失了以及爲什麼多了一個rollback語句？因爲在mysqlbinlog工具的源碼中，轉儲binlog文件到磁盤是調用glibc來寫文件，當mysqlbinlog僞裝的slave在連接master使用–raw+–read-from-remote-server 選項時，glibc的緩存會把最後一個event留在內存中不調用fflush函數落盤(但master的binlog dump線程把mysqlbinlog的連接仍然當作一個正常的slave一樣把完整的binlog發送過去給mysqlbinlog了)，所以當你啓動另外一個mysqlbinlog進程去解析這個binlog文件時，並沒有看到最後一個事務的commit標記，但是卻看到了rollback(這個rollback語句只要調用mysqlbinlog命令結束都會加上的，要注意，這個rollback語句是你用於解析這個binlog文件的那一個mysqlbinlog進程加上的，跟binlog server的那一個mysqlbinlog沒關係，binlog server的那一個mysqlbinlog進程還仍然再運行中，還卡在最後一個commit未落盤這裏)
-
mysqlbinlog不使用–raw選項時，mysqlbinlog同步的binlog被直接解析爲文本格式轉儲，這個時候轉儲的binlog內容中最後一個事務與主庫中記錄的一致，都帶有commit語句，即這個時候使用mysqlbinlog轉儲的binlog做數據恢復時，不會發生數據丟失，那這個時候爲什麼有commit語句而沒有rollback語句呢？因爲非raw模式的轉儲時（即只使用–read-from-remote-server 選項不使用–raw選項），mysqlbinlog解析時會調用glibc的fflush函數強制把緩存中的數據刷新到文件中，所以不使用–raw選項時就會有commit語句，而缺失這個rollback語句是因爲轉儲binlog的mysqlbinlog進程仍然在繼續運行，只有在mysqlbinlog結束的時候纔會加上rollback語句。那爲什麼使用–raw模式的時候mysqlbinlog也在運行，解析出來的binlog文件就有rollback語句呢？還記得是另外調用了一個mysqlbinlog命令來解析的嗎？解析binlog的這個mysqlbinlog進程在執行完解析之後就退出了，so…
-
因爲binlog server在持續運行期間，最後一個事務的commit標記總是不落盤（除非你正常停止這個binlog server進程），所以，如果經濟上允許，建議單獨使用一臺服務器，搭建一個備份專用備庫，還可以避免備份與線上業務訪問相互影響的問題，系統參數relay_log_purge別忘記設置爲OFF，因爲是備份binlog專用的備庫，所以表引擎可以改爲blackhole引擎。
-
注意：
-
mysqlbinlog server在加了–stop-never選項之後就會一直監聽所連接的server是否有新的events發送過來，也正因爲如此，導致了最後一個事務的commit語句一直不能落盤，直到主庫有新的events發送過來時，這個事務的commit纔會被觸發寫盤。如果不使用–stop-never選項當然就沒有問題，因爲mysqlbinlog在讀取了server最後一個binlog文件之後會退出，退出時會把緩存中的events都落盤。但是這也會導致了無法即時轉儲主庫的數據更新。
-
在MySQL 5.7.x版本中，mysqlbinlog工具解析任何一個本地的binlog或relay log時，都不會在mysqlbinlog命令執行結束時追加rollback語句，但在MySQL 5.6.x版本中，mysqlbinlog工具解析每一個本地binlog和relay log時在mysqlbinlog命令退出時都會加rollback語句