mysql binlog 按日生成

文章目录

• MySql日志-binlog

• 一、作用和场景
• 二、配置

• 2.1 查看binlog是否开启
• 2.2 查看binlog位置
• 2.3 查看binlog模式
• 2.4 binlog配置文件
• 2.5 binlog刷盘配置
• 2.6 binlog文件和命令
• 2.7 binlog其他配置

• 三、binlog操作

• 3.1 查看所有binlog日志
• 3.2 查看最新binlog日志
• 3.3 刷新binlog
• 3.4 清空binlog
• 3.5 查看binlog日志
• 3.6 查看bin-log日志

• 四、binlog恢复数据

• 4.1 创建数据库，新增数据
• 4.2 整库备份
• 4.3 模拟误操作
• 4.4 binlog恢复数据

• 五、mysqlbinlog命令参考
• 六、参考

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原理