10-MySql 日志-binlog

MySQL 专栏收录该内容
22 篇文章 0 订阅

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_binbinlog保存路径,注意配置的是文件夹,文件名系统自己生成“D:/mysql/mysql-5.7.27-winx64/data/bin_log/”
log_bin_index指定二进制索引文件的路径与名称
expire_logs_days配置日志定期清理7
server-id主从模式下该id必须唯一100
binlog-formatbinlog模式Statement(默认) /Row /Mixed(推荐)/
max_binlog_sizebinlog每个日志文件大小100m
binlog_cache_sizebinlog缓存大小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

六、参考

  • 0
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 精致技术 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值