10-MySql 日誌-binlog

MySql日誌-binlog

• MySQL中有六種日誌文件，分別是：事物日誌、（包括redo log和undo log）、二進制日誌（binlog）、錯誤日誌（errorlog）、慢查詢日誌（slow query log）、一般查詢日誌（general log），中繼日誌（relay log），本文關於二進制日誌(binlog)。

一、作用和場景

• Binary Log簡稱binlog 即二進制日誌文件，日誌記錄了MySql所有DDL和DML操作。通過 binlog 可以做數據恢復，主主和主從複製等。簡言之BinLlog兩個重要的用途：複製和恢復，MySQL的很多特性比如可靠性、備份，數據重放等機制都依賴於binlog。

binlog會保存所有的DDL語句和非select的DML操作，用於對數據進行恢復和備份。

應用場景

• 主從複製：master 會開啓binlog並將其傳遞給slave來達到master和slave數據一致的目的。
• 數據恢復：mysqlbinlog等工具通過binlog來恢復數據。

二、配置

2.1 查看binlog是否開啓

show variables like 'log_bin%'; 
log_bin_basename: binlog文件的保存路徑

2.2 查看binlog位置

• 查看binlog的保存位置(binlog的位置和數據路徑一致)

show variables like '%datadir%';

2.3 查看binlog模式

show variables like 'binlog_format';

set global bin_log format = statement;//修改binlog模式

show variables like 'binlog%'; 

關於binlog模式：binlog記錄日誌有多種模式，通過配置 binlog-format 指定

• Statement：每一條修改數據的sql都會記錄到 master 的 binlog 中。slave在複製的時候sql進程會解析成和原來的master端執行的相同的sql來再次執行。

• Row：日誌中會記錄成每一行數據被修改的形式，然後在slave端再對相同的數據進行修改。

• Mixed：實際上就是前兩種模式的結合，MySQL根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，在Statement和Row之間選擇一種。

• 表格對比

配置值	優點	缺點
Statement	不需要記錄每一行數據的變化，減少 binlog 日誌量，節約IO，提高性能。需要記錄每條語句在執行的上下文信息
Row	可以不記錄執行的sql語句的上下文信息，可能會產生大量的日誌內容,尤其是當執行alter table之類的語句的時候，產生的日誌量是驚人的。
Mixed	二者兼顧	二者兼顧

• 在性能允許的時候，建議使用 ROW 模式，statement 可以在有些時候會導致複製數據不一致

2.4 binlog配置文件

• binlog 相關配置

[mysqld]
log_bin = "D:/mysql/mysql-5.7.27-winx64/data/bin_log/"
expire_logs_days=5
server-id = 1
binlog-format = Row (設置爲 MIXED 才能記錄到insert語句)

• 配置說明

配置	說明	示例值
log_bin	binlog保存路徑，注意配置的是文件夾，文件名系統自己生成	“D:/mysql/mysql-5.7.27-winx64/data/bin_log/”
log_bin_index	指定二進制索引文件的路徑與名稱
expire_logs_days	配置日誌定期清理	7
server-id	主從模式下該id必須唯一	100
binlog-format	binlog模式	Statement(默認) /Row /Mixed(推薦)/
max_binlog_size	binlog每個日誌文件大小	100m
binlog_cache_size	binlog緩存大小	4m
max_binlog_cache_size	最大binlog緩存大小	512m

• 配置expire_logs_days決定binlog文件的過期，對於非活動的binlog文件，如果生成時間大於該配置的天數會被自動刪除。(只會有一個活動的binlog文件)

show variables like '%expire_logs_days%'

PS：關於 binlog-format 配置，參考1.3小節binlog的模式。

2.5 binlog刷盤配置

• binlog 日誌刷盤策略由配置項 sys_binlog 控制，sync_binlog=[N]:，N 表示每多少個事務寫入緩衝刷一次盤，默認值爲0表示由操作系統決定何時刷盤，數據安全性要求較高時建議配置爲1；

sys_binlog配置值	含義
0	默認，表示由操作系統決定何時刷盤，此時寫入binlog文件但是存在文件系統緩存，不會調用 fsync 刷盤，系統奔潰可能會丟失binlog日誌
N	表示每多少個事務寫入緩衝刷一次盤，比如配置1，那麼每一次事物都會調用 fsync 寫磁盤

2.6 binlog文件和命令

• binlog的文件名稱由配置項：log-bin 決定,產生的文件類似於下面所示，後綴000001 … 遞增，並且還會有一個 index 後綴的索引文件

log-bin=mysql-bin

-rw-r----- 1 mysql mysql 2.5K Dec 23 11:29 mysql-bin.000001
-rw-r----- 1 mysql mysql  779 Dec 23 11:43 mysql-bin.000002
-rw-r----- 1 mysql mysql  490 Dec 23 11:47 mysql-bin.000003
-rw-r----- 1 mysql mysql  469 Dec 23 11:48 mysql-bin.000004
-rw-r----- 1 mysql mysql   76 Dec 23 11:47 mysql-bin.index

• 注意，bin-log有很多種情況會生成一個新的文件，比如flush logs、MySql重啓、還有文件大小達到閾值，都會重新創建一個文件，可以通過index文件查詢binlog日誌文件；

2.7 binlog其他配置

• 其他更多配置

binlog_do_db:只記錄指定數據庫的二進制日誌
binlog_ignore_db:不記錄指定的數據庫的二進制日誌

binlog_cache_use：使用二進制日誌緩存的事務數量
max_binlog_cache_size：binlog使用的內存最大值
binlog_cache_size:binlog使用的內存大小，可以通過狀態變量binlog_cache_use和binlog_cache_disk_use來幫助測試。
binlog_cache_disk_use:使用二進制日誌緩存但超過binlog_cache_size值並使用臨時文件來保存事務中的語句的事務數量

max_binlog_size:Binlog最大值，最大和默認值是1GB，該設置並不能嚴格控制Binlog的大小，尤其是Binlog比較靠近最大值而又遇到一個
比較大事務時，爲了保證事務的完整性，不可能做切換日誌的動作，只能將該事務的所有SQL都記錄進當前日誌，直到事務結束

三、binlog操作

3.1 查看所有binlog日誌

show master logs
//或者
show binary logs;

3.2 查看最新binlog日誌

• 查看最新binlog日誌編號及最後一個操作事件的結束點(Position)值；

show master status;

3.3 刷新binlog

• flush刷新log日誌；flush後會產生一個新編號的binlog日誌文件;

flush logs;

3.4 清空binlog

• 清空binlog；執行之後會刪除之前的binlog，生成新的binlog和index文件。

reset master;

3.5 查看binlog日誌

• 查看binlog內容；使用mysqlbinlog自帶查看命令法

mysqlbinlog mysql-bin.00001
mysqlbinlog --start-position=1 --stop-position=100  -d dbName   .000001

• 更精確查詢；可以從指定的pos起點位置開始查詢，還可指定偏移和查詢條數。

show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

show binlog events in '.000001';
show binlog events in  'mysql-bin.000004' ;

3.6 查看bin-log日誌

• binlog 日誌文件的後綴名稱是遞增的，查看之前刷新一下，然後操作一下數據庫就可以看到新的日誌文件了

mysql> flush logs;
Query OK, 0 rows affected (0.03 sec)
mysql> 
mysql> show binlog events in  'mysql-bin.000003' ;
+------------------+-----+----------------+-----------+-------------+---------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                  |
+------------------+-----+----------------+-----------+-------------+---------------------------------------+
| mysql-bin.000003 |   4 | Format_desc    |       100 |         123 | Server ver: 5.7.28-log, Binlog ver: 4 |
| mysql-bin.000003 | 123 | Previous_gtids |       100 |         154 |                                       |
| mysql-bin.000003 | 154 | Anonymous_Gtid |       100 |         219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'  |
| mysql-bin.000003 | 219 | Query          |       100 |         295 | BEGIN                                 |
| mysql-bin.000003 | 295 | Table_map      |       100 |         352 | table_id: 109 (mzptest2.user)         |
| mysql-bin.000003 | 352 | Write_rows     |       100 |         412 | table_id: 109 flags: STMT_END_F       |
| mysql-bin.000003 | 412 | Xid            |       100 |         443 | COMMIT /* xid=327 */                  |
+------------------+-----+----------------+-----------+-------------+---------------------------------------+
7 rows in set (0.00 sec)

四、binlog恢復數據

4.1 創建數據庫，新增數據

• 首先創建數據庫，新增數據，導出的sql如下：

SET FOREIGN_KEY_CHECKS=0;
-- ----------------------------
-- Table structure for t_name
-- ----------------------------
DROP TABLE IF EXISTS `t_name`;
CREATE TABLE `t_name` (
  `name` varchar(30) DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;

-- ----------------------------
-- Records of t_name
-- ----------------------------
INSERT INTO `t_name` VALUES ('name1', '1');
INSERT INTO `t_name` VALUES ('name2', '2');
INSERT INTO `t_name` VALUES ('name3', '3');
INSERT INTO `t_name` VALUES ('name4', '4');
INSERT INTO `t_name` VALUES ('name5', '5');
INSERT INTO `t_name` VALUES ('name6', '6');
INSERT INTO `t_name` VALUES ('name7', '7');
INSERT INTO `t_name` VALUES ('name8', '8');
INSERT INTO `t_name` VALUES ('name9', '9');

4.2 整庫備份

• 正常情況，會一定週期的整庫備份，現在備份一把,備份文件和備份sql如下，假設此時數據庫的狀態爲狀態1

mysqldump -h 192.168.31.147 --port 3308  -u root -p123456 -t testbinlog  --tables  t_name > t_name_bak.sql

• 備份的dump文件

-- MySQL dump 10.13  Distrib 5.7.27, for Win64 (x86_64)
--
-- Host: 192.168.31.147    Database: testbinlog
-- ------------------------------------------------------
-- Server version	5.7.27-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Dumping data for table `t_name`
--

LOCK TABLES `t_name` WRITE;
/*!40000 ALTER TABLE `t_name` DISABLE KEYS */;
INSERT INTO `t_name` VALUES ('name1',1),('name2',2),('name3',3),('name4',4),('name5',5),('name6',6),('name7',7),('name8',8),('name9',9);
/*!40000 ALTER TABLE `t_name` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2019-12-24 11:30:37

4.3 模擬誤操作

• 爲了便於模擬，此時我們執行 flush logs ，讓mysql開始一個新的binlog文件；
• 定時備份後，繼續業務操作，假設業務操作sql 如下，假設操作之後記爲狀態2，此時所有的 name字段 都被加上了 “_state1” 這樣一個後綴；

UPDATE t_name set name = CONCAT(name,'_state1'); --- 狀態2

• 然後不小心發生了誤操作，假設誤操作sql如下,不小心刪除了id大於5的記錄，此時數據庫狀態記爲狀態3

DELETE FROM t_name where id >5; -- 狀態3

• 到此數據已經有問題，現在我們的需求是恢復到狀態2，不能僅僅靠之前的定時備份來恢復到狀態1，那樣我們的業務修改就沒有了(注意中間的業務操作可能有很多，這裏只是用一個sql來模擬)，此時我們先通過定時備份恢復到狀態1，先把數據庫記錄刪除，然後用定時備份恢復到狀態1；後面再通過binlog從狀態1恢復到狀態2

4.4 binlog恢復數據

• 首先要用整庫備份的數據，恢復到備份時候的數據，也就是狀態1；後面的數據就要用binlog恢復了，但是不能完全執行binlog，因爲裏面有誤操作的日誌，我們要去掉誤操作的，否則就直接到狀態2了；
• 現在假設我們已經用整庫恢復了原始的數據，現在我們要回到狀態1，先看看binlog

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#191224  5:58:45 server id 100  end_log_pos 123 CRC32 0xef099625 	Start: binlog v 4, server v 5.7.28-log created 191224  5:58:45
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
FakBXg9kAAAAdwAAAHsAAAABAAQANS43LjI4LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
ASWWCe8=
'/*!*/;
# at 123
#191224  5:58:45 server id 100  end_log_pos 154 CRC32 0xd9b4eed2 	Previous-GTIDs
# [empty]
# at 154
#191224  5:59:35 server id 100  end_log_pos 219 CRC32 0xc45bcb07 	Anonymous_GTID	last_committed=0	sequence_number=1	rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
#191224  5:59:35 server id 100  end_log_pos 294 CRC32 0xa425d252 	Query	thread_id=15	exec_time=0	error_code=0
SET TIMESTAMP=1577167175/*!*/;
SET @@session.pseudo_thread_id=15/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 294
#191224  5:59:35 server id 100  end_log_pos 349 CRC32 0xce4849bb 	Table_map: `db_test`.`t_name` mapped to number 108
# at 349
#191224  5:59:35 server id 100  end_log_pos 646 CRC32 0xa78a1ca1 	Update_rows: table id 108 flags: STMT_END_F

BINLOG '
R6kBXhNkAAAANwAAAF0BAAAAAGwAAAAAAAEAB2RiX3Rlc3QABnRfbmFtZQACDwMCWgABu0lIzg==
R6kBXh9kAAAAKQEAAIYCAAAAAGwAAAAAAAEAAgAC///8BW5hbWUxAQAAAPwMbmFtZTFfc3RhdGUx
AQAAAPwFbmFtZTICAAAA/AxuYW1lMl9zdGF0ZTECAAAA/AVuYW1lMwMAAAD8DG5hbWUzX3N0YXRl
MQMAAAD8BW5hbWU0BAAAAPwMbmFtZTRfc3RhdGUxBAAAAPwFbmFtZTUFAAAA/AxuYW1lNV9zdGF0
ZTEFAAAA/AVuYW1lNgYAAAD8DG5hbWU2X3N0YXRlMQYAAAD8BW5hbWU3BwAAAPwMbmFtZTdfc3Rh
dGUxBwAAAPwFbmFtZTgIAAAA/AxuYW1lOF9zdGF0ZTEIAAAA/AVuYW1lOQkAAAD8DG5hbWU5X3N0
YXRlMQkAAAChHIqn
'/*!*/;
# at 646
#191224  5:59:35 server id 100  end_log_pos 677 CRC32 0xf301eae3 	Xid = 184
COMMIT/*!*/;
# at 677
#191224  5:59:58 server id 100  end_log_pos 742 CRC32 0xe996d5c5 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 742
#191224  5:59:58 server id 100  end_log_pos 817 CRC32 0xbeb75473 	Query	thread_id=15	exec_time=0	error_code=0
SET TIMESTAMP=1577167198/*!*/;
BEGIN
/*!*/;
# at 817
#191224  5:59:58 server id 100  end_log_pos 872 CRC32 0xffcf032e 	Table_map: `db_test`.`t_name` mapped to number 108
# at 872
#191224  5:59:58 server id 100  end_log_pos 979 CRC32 0x28bb1396 	Delete_rows: table id 108 flags: STMT_END_F

BINLOG '
XqkBXhNkAAAANwAAAGgDAAAAAGwAAAAAAAEAB2RiX3Rlc3QABnRfbmFtZQACDwMCWgABLgPP/w==
XqkBXiBkAAAAawAAANMDAAAAAGwAAAAAAAEAAgAC//wMbmFtZTZfc3RhdGUxBgAAAPwMbmFtZTdf
c3RhdGUxBwAAAPwMbmFtZThfc3RhdGUxCAAAAPwMbmFtZTlfc3RhdGUxCQAAAJYTuyg=
'/*!*/;
# at 979
#191224  5:59:58 server id 100  end_log_pos 1010 CRC32 0x2d34be1e 	Xid = 193
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*/;

• 能夠看到裏面有兩個 BEGIN ，第一個是 BEGIN 裏面是 Update_rows，對應第一次的業務更新操作，第二次是 Delete_rows ，對應後面一次的誤刪除操作，可以看到第一個事物完成後的position是742，因此我們可以將這個 binlog 文件的開始部分到742部分導出成爲sql：

mysqlbinlog --stop-position="742" /var/lib/mysql/mysql-bin.000002 > back_1.sql

• 首先通過定時備份恢復到狀態1，恢復後就回到了第一次全量本分的時候:

• 然後運行sql之前得到的sql，下面是我整個操作的命令截圖：

//整個過程如下：
 
mysql> select * from t_name;  --- 這是通過定時備份恢復到狀態1
+-------+----+
| name  | id |
+-------+----+
| name1 |  1 |
| name2 |  2 |
| name3 |  3 |
| name4 |  4 |
| name5 |  5 |
| name6 |  6 |
| name7 |  7 |
| name8 |  8 |
| name9 |  9 |
+-------+----+
9 rows in set (0.00 sec)

mysql> source /var/lib/mysql/back_1.sql   --- 導入binlog中的日誌來恢復業務操作
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Charset changed
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.02 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> select * from t_name;   --- 得到了狀態2，數據都在，沒有丟失
+--------------+----+
| name         | id |
+--------------+----+
| name1_state1 |  1 |
| name2_state1 |  2 |
| name3_state1 |  3 |
| name4_state1 |  4 |
| name5_state1 |  5 |
| name6_state1 |  6 |
| name7_state1 |  7 |
| name8_state1 |  8 |
| name9_state1 |  9 |
+--------------+----+
9 rows in set (0.00 sec)
mysql> 

• 最後就回到了包含 9 條數據的誤操作之前的狀態，被刪除的數據恢復了
• 這裏我使用的binlog模式是ROW模式，另外需要注意的是真正遇到需要通過binlog回覆數據的時候，數據量以及發生的業務修改是非常多的，可能binlog文件也很多，只要binlog文件保存着，最關鍵的是找到自己需要恢復的數據對應在 binlog 中的時間點，就像起那麼找到position 742 一樣，通過 mysqlbinlog 命令可以查看，但是非常多的時候，未必有這麼好查看，mysqlbinlog 命令可以通過position和其實時間來控制導出，最後附了一些可供參考的命令

五、mysqlbinlog命令參考

假設 binlog-format=ROW 模式下:

• 提取指定數據庫的指定binlong文件日誌

mysqlbinlog -d db_name --base64-output=decode-rows -v binlog.00000x > ./bak.sql

• 提取指定數據庫的數據表的指定binlong文件日誌

mysqlbinlog -d db_name --base64-output=decode-rows -v binlog.00000x |grep table_name > /bak.sql

• 提取insert/update操作的binlog日誌

mysqlbinlog -d db_name --base64-output=decode-rows -v binlog.00000x | grep insert/update  > /bak.sql

• 提取指定時間段日誌

mysqlbinlog --base64-output=decode-rows -v --start-datetime='2019-12-24 00:00:00' --stop-datetime='2019-12-24 23:59:59' binlog.00000x > /bak.sql

• 提取指定position日誌

mysqlbinlog --base64-output=decode-rows -v --start-position='123' --stop-position='456' binlog.00000x > /bak.sql

• 提取並壓縮

mysqlbinlog --start-position="123" --stop-position="456" binlog.00000x | gzip  > /bak.gz

• 提取後直接導入數據庫

mysqlbinlog --start-position="123" --stop-position="456" binlog.00000x | mysql -uroot -p 

• 批量binlog文件提取

mysqlbinlog --start-position="123" --stop-position="456" binlog.00000x binlog.00000y  > /bak.sql
mysqlbinlog  /var/lib/mysql/mysql-bin.000001 /var/lib/mysql/mysql-bin.000002 > ./bak.sql

• 遠程提取數據庫的binlog

mysqlbinlog  -h10.168.10.11 -P3306 -uroot -p --stop-datetime="2020-01-01 00:00:00" --read-from-remote-server  mysql-bin.0000x  > /bak.sql

六、參考

• [1] mysql binlog詳解
• [2] Mysql Binlog三種格式詳細介紹
• [3] MySQL 利用binlog增量備份+還原實例
• [4] Mysql的Binlog原理