首先，給出我的MySQL版本

SELECT  VERSION();
5.7.25-log

mysqlbinlog
    --database 
    --base64-output=DECODE-ROWS #如果截取出來的日志是為了SOURCE執(zhí)行，不要添加這個(gè)參數(shù)
    --verbose
    --set-charset=utf8
    --skip-gtids
    --include-gtids='bec1f53c-61b9-11e9-8871-000c29d144c9:200-2302' #需要再次執(zhí)行的GTID
    --exclude-gtids='bec1f53c-61b9-11e9-8871-000c29d144c9:220' #需要過濾掉的GTID
    --result-file=/var/log/mysql/dump.sql

重要參數(shù)說明

1. --skip-gtids
   這里先給出官方文檔中的說法

   Do not display any GTIDs in the output. 
   This is needed when writing to a dump file from 
   one or more binary logs containing GTIDs, 
   as shown in this example:
   shell> mysqlbinlog --skip-gtids binlog.000001 >  /tmp/dump.sql
   shell> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
   shell> mysql -u root -p -e "source /tmp/dump.sql"
   The use of this option is otherwise not normally recommended in production. 
   

   也就是說，除了上述用法，不建議在生產(chǎn)環(huán)境中使用這個(gè)參數(shù)。這個(gè)參數(shù)的作用可能是規(guī)避GTID的冪等性。經(jīng)過試驗(yàn)，發(fā)現(xiàn)，如果沒有加這個(gè)參數(shù)，截取出來的SQL二進(jìn)制日志即使被SOURCE，也不會(huì)產(chǎn)生效果。另外，即使在sql_log_bin=1時(shí)，如果沒有加上這個(gè)參數(shù)，由于冪等性，二進(jìn)制日志并不會(huì)真正執(zhí)行，所以，并不會(huì)產(chǎn)生新的二進(jìn)制日志記錄。

2. --base64-output=DECODE-ROWS
   如果加上這個(gè)參數(shù)，截取出來的日志雖然可以SOURCE成功，但是不會(huì)執(zhí)行SQL。
   那么，給出結(jié)論，如果是為了查看截取出來的日志，加上這個(gè)參數(shù)和--verbose，如果是為了執(zhí)行SQL，不要加這個(gè)參數(shù)。

遺留問題

1. --idempotent

   Tell the MySQL Server to use idempotent mode while processing updates;
   this causes suppression of any duplicate-key or key-not-found errors
   that the server encounters in the current session while processing updates.
   This option may prove useful whenever it is desirable or necessary to replay one or more binary logs to a MySQL Server which may not contain all of the data to which the logs refer.
   The scope of effect for this option includes the current mysqlbinlog client and session only.

   怎么理解和使用？

2. 加上--database就可以按照庫來篩選，如何以表為精度進(jìn)行篩選？

參考文檔

4.6.7 mysqlbinlog — Utility for Processing Binary Log Files