mysql二进制文件操作语法(mysql binary log operate statements)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 开启 binary logs 功能在 mysql 配置文件中配置 log-bin,重启 mysqlmy.cnf (on Linux/unix) or my.ini (on Windows) 例子:[client]...[mysqld]...log-bin=mysql-bin (log_bin=/var/mydb/bin-log,指定 log 的路径,以及名称前缀)---一旦重启,Mysql 会自动创建新的二进制文件。

开启 binary logs 功能

在 mysql 配置文件中配置 log-bin,重启 mysql
my.cnf (on Linux/unix) or my.ini (on Windows) 例子:

[client]
...

[mysqld]
...
log-bin=mysql-bin  (log_bin=/var/mydb/bin-log,指定 log 的路径,以及名称前缀)
---

一旦重启,Mysql 会自动创建新的二进制文件。您也不妨看看下面的变量

server-id        = 1
expire_logs_days = 4 (自动删除 log 的天数,缺省值为 0,即不自动删除)
sync_binlog      = 1

详细信息可以阅读 MySQL documentation,如果你使用主从库(使用二进制文件的主要理由),请查阅Replication configuration checklist

查看 binary logs

登陆 MySQL 之后执行如下语句:

SHOW BINARY LOGS
等价
SHOW MASTER LOGS

返回值:

mysql> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |        98 |
+------------------+-----------+
1 row in set (0.00 sec)

手动删除 binary log

PURGE { BINARY | MASTER } LOGS
    { TO 'log_name' | BEFORE datetime_expr }

例子:

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

datetime_expr 参数格式为 YYYY-MM-DD hh:mm:ss
上述语法,当从库正在同步时,也可以安全运行。你不必要关闭从库。如果你正在删除一个从库正在同步的 log,上述语句将不会做任何操作。MySQL 5.7.2 以及之后版本将会报错。然而,如果你删除了一个从库没有同步的 log,那么从库将无法与主库保持数据一致。
手动安全删除日志的步骤:

  • 在每一个从库的 MySQL 上运行 SHOW SLAVE STATUS,检验从库没有从主库读取日志
  • 使用命令 SHOW BINARY LOGS,查看主库上的 binary log 文件
  • 找出在从库中时间最早的 log 文件,这是我们要删除的目标文件。如果所有从库都对同一个 log 与主库保持同步,那么那个日志就是我们要删除的目标文件
  • 删除之前,备份 log。(这一步是可选的,但是建议你这么做)
  • 删除目标文件之前的 log

可以通过设置 expire_logs_days 参数,自动删除 log。
在调用上述删除语句之前,log 已经被删除,比如 linux 中使用 rm 命令,那么该语句将会报错。

binary log 格式

binary log 会记录所有与数据修改相关的操作,查询不会被记录哦。
比如我有如下的一些操作:

1. drop table student_information;
2. drop table student;
3. CREATE TABLE `student` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `name` char(20) NOT NULL,
     `age` tinyint(2) NOT NULL DEFAULT '0',
     PRIMARY KEY (`id`),
     KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;
4. insert student values(1,'zhangsan',20);
5. insert student values(1,'zhangsan',20);
6. insert student values(3,'wangwu',22);

通过命令将 binary log 转为 SQL 脚本:

mysqlbinlog mysql-bin.000001 > my.sql

binary log 存储内容为:

SET TIMESTAMP=1473842609/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1/*!*/;
SET @@session.sql_mode=1344274432/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
drop table student_information
/*!*/;
# at 193
#160914 16:43:35 server id 1  end_log_pos 276   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842615/*!*/;
drop table student
/*!*/;
# at 276
#160914 16:43:57 server id 1  end_log_pos 578   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842637/*!*/;
CREATE TABLE `student` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` char(20) NOT NULL,
  `age` tinyint(2) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
/*!*/;
# at 578
#160914 16:44:11 server id 1  end_log_pos 648   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842651/*!*/;
BEGIN
/*!*/;
# at 648
#160914 16:44:11 server id 1  end_log_pos 751   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842651/*!*/;
insert student values(1,'zhangsan',20)
/*!*/;
# at 751
#160914 16:44:11 server id 1  end_log_pos 778   Xid = 29
COMMIT/*!*/;
# at 778
#160914 16:44:19 server id 1  end_log_pos 848   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842659/*!*/;
BEGIN
/*!*/;
# at 848
#160914 16:44:19 server id 1  end_log_pos 947   Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842659/*!*/;
insert student values(2,'lisi',21)
/*!*/;
# at 947
#160914 16:44:19 server id 1  end_log_pos 974   Xid = 30
COMMIT/*!*/;
# at 974
#160914 16:44:25 server id 1  end_log_pos 1044  Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842665/*!*/;
BEGIN
/*!*/;
# at 1044
#160914 16:44:25 server id 1  end_log_pos 1145  Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473842665/*!*/;
insert student values(3,'wangwu',22)
/*!*/;
# at 1145
#160914 16:44:25 server id 1  end_log_pos 1172  Xid = 31
COMMIT/*!*/;
# at 1172
#160914 17:31:33 server id 1  end_log_pos 1242  Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473845493/*!*/;
BEGIN
/*!*/;
# at 1242
#160914 17:31:33 server id 1  end_log_pos 1348  Query   thread_id=1 exec_time=0 error_code=0
SET TIMESTAMP=1473845493/*!*/;
update student set age = 100 where id = 1
/*!*/;
# at 1348
#160914 17:31:33 server id 1  end_log_pos 1375  Xid = 33
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

从语法上可以看出,如果是 update 操作恢复的概率相对要麻烦很多,需要对比操作。 SET TIMESTAMP 是操作的时间戳,这个相当有用,这样就允许我们通过时间来确定重做的范围。delete 以及 update 都被放置在事务里边了,但是只有当整个 binary log 执行完成才算成功,任何一条语法的异常都会导致事务回滚,重做失败。

使用 binary log 增量恢复数据

直接重做 binary log 中的操作:

mysqlbinlog mysql-bin.000001 | mysql -u root -p

执行过程中发生异常就被被终止,所以在重做之前需要自己处理该文件,使得重做的动作是自己想要的。比如从上述 binary log 中有 drop table student_information 操作,而此时的数据库中已经不存在该表,所以重做该步骤就会抛出异常信息。ERROR 1051 (42S02) at line 16: Unknown table 'student_information'

逐行查看 binary log 中内容:

mysqlbinlog mysql-bin.000001 | more

转换 binary log 为 SQL 脚本:

mysqlbinlog mysql-bin.000001 > my.sql

重做 SQL 脚本:

mysql -u root -p < my.sql

如果你有多个 binary log 文件需要被执行,安全的方式是:将所有的 binary log 一次性执行。不安全方法的示例:

mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!

使用两个不同连接处理 binary log 可能导致问题,有可能会发生如下情况:第一个 binary log 包含语法 CREATE TEMPOARY TEBLE 而第二个 binary log 使用到该临时表。当第一个 binary log 执行完成将会删除临时表,那么第二个 binary log 需要使用到该临时表的语句将报错。

在一个连接中完成 binary logs 的处理,例子如下:

mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

另外一种方法,将 binary logs 合并为一个 SQL 脚本:

mysqlbinlog binlog.000001 >  /tmp/statements.sql
mysqlbinlog binlog.000002 >> /tmp/statements.sql
mysql -u root -p -e "source /tmp/statements.sql"

When writing to a dump file while reading back from a binary log containing GTIDs (see Section 18.1.3, “Replication with Global Transaction Identifiers”), use the --skip-gtids option with mysqlbinlog, like this:

mysqlbinlog --skip-gtids binlog.000001 >  /tmp/dump.sql
mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
mysql -u root -p -e "source /tmp/dump.sql"

欢迎转载,但请注明本文链接,谢谢你。
2016.9.14 19:08

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
6天前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
21 5
图解MySQL【日志】——Redo Log
|
21天前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
5天前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
19 4
图解MySQL【日志】——两阶段提交
|
20天前
|
SQL 缓存 关系型数据库
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
|
3天前
|
关系型数据库 MySQL 数据库
MySQL日志
本文介绍了MySQL中三个重要的日志:binlog、redolog和undolog。binlog记录数据库更改操作,支持数据恢复、复制和审计;redolog保证事务的原子性和持久性,实现crash-safe;undolog用于事务回滚及MVCC的实现。每个日志都有其独特的作用和应用场景,确保数据库的稳定性和数据一致性。
|
5天前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
19 3
|
8天前
|
缓存 关系型数据库 MySQL
图解MySQL【日志】——Buffer Pool
Buffer Pool 是数据库管理系统(DBMS)中用于缓存磁盘数据页的内存区域,主要包含数据页、索引页、undo 页等。它通过减少磁盘 I/O 提升性能,特别是在处理大型数据库时效果显著。查询时,整个数据页而非单条记录会被加载到 Buffer Pool 中,以提高访问效率。
17 0
图解MySQL【日志】——Buffer Pool
|
1月前
|
监控 Oracle 关系型数据库
Mysql、Oracle审计日志的开启
通过上述步骤,可以在 MySQL 和 Oracle 数据库中启用和配置审计日志。这些日志对于监控数据库操作、提高安全性和满足合规性要求非常重要。确保正确配置审计参数和策略,定期查看和分析审计日志,有助于及时发现并处理潜在的安全问题。
65 11
|
8天前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
19 0
|
3月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
1044 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板