AI 助理
备案控制台
开发者社区 数据库 文章 正文

带你解析MySQL binlog

2022-05-28 1749
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS MySQL，高可用系列 2核4GB
简介： 我们都知道，binlog可以说是MySQL中比较重要的日志了，在日常学习及运维过程中，也经常会遇到。不清楚你对binlog了解多少呢？本篇文章将从binlog作用、binlog相关参数、解析binlog内容三个方面带你了解binlog。

1.binlog简介


binlog即binary log，二进制日志文件。它记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。

binlog主要有两个应用场景，一是用于复制，master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。二是用于数据恢复，例如还原备份后，可以重新执行备份后新产生的binlog，使得数据库保持最新状态。除去这两个主要用途外，binlog可以用于异构系统之间数据的交互，binlog完整保存了一条记录的前项和后项记录，可以用DTS服务，将MySQL数据以准实时的方式抽取到底层数据平台，比如HBase、Hive、Spark等，打通OLTP和OLAP。


binlog日志可以选择三种模式，分别是 STATEMENT、 ROW、 MIXED，下面简单介绍下这三种模式：


  • STATEMENT：基于SQL语句的复制，每一条会修改数据的sql语句会记录到binlog中。该模式下产生的binlog日志量会比较少，但可能导致主从数据不一致。
  • ROW：基于行的复制，不记录每一条具体执行的SQL语句，仅需记录哪条数据被修改了，以及修改前后的样子。该模式下产生的binlog日志量会比较大，但优点是会非常清楚的记录下每一行数据修改的细节，主从复制不会出错。
  • Mixed：混合模式复制，以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。


binlog模式在MySQL 5.7.7之前，默认为 STATEMENT，在之后的版本中，默认为ROW。这里建议采用ROW模式，因为ROW模式更安全，可以清楚记录每行数据修改的细节。


2.binlog相关参数


binlog默认情况下是不开启的，不过一般情况下，初始化的时候建议在配置文件中增加log-bin参数来开启binlog。

# 配置文件中增加log-bin配置
[mysqld]
log-bin = binlog
# 不指定路径默认在data目录下，也可以指定路径
[mysqld]
log-bin = /data/mysql/logs/binlog
# 查看数据库是否开启了binlog
show variables like 'log_bin%';

开启binlog后，还需注意一些与binlog相关的参数，下面简单介绍下相关参数：


binlog_format

设置binlog模式，建议设为ROW。

binlog_do_db

此参数表示只记录指定数据库的二进制日志，默认全部记录，一般情况下不建议更改。

binlog_ignore_db

此参数表示不记录指定的数据库的二进制日志，同上，一般不显式指定。

expire_logs_days

此参数控制二进制日志文件保留天数，默认值为0，表示不自动删除，可设置为0~99。可根据实际情况设置，比如保留15天或30天。MySQL8.0版本可用binlog_expire_logs_seconds参数代替。

max_binlog_size

控制单个二进制日志大小，当前日志文件大小超过此变量时，执行切换动作。此参数的最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束。一般情况下可采取默认值。

log_bin_trust_function_creators

当二进制日志启用后，此参数就会启用。它控制是否可以信任存储函数创建者，不会创建写入二进制日志引起不安全事件的存储函数。如果设置为0（默认值），用户不得创建或修改存储函数，除非它们具有除CREATE ROUTINE或ALTER ROUTINE特权之外的SUPER权限。建议设置为1。

sync_binlog

控制MySQL服务端将二进制日志同步到磁盘的频率，默认值为1。

设置为0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新；

设置为1，表示每次事务提交，MySQL都会把binlog刷下去，这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响；

设置为n，其中n为0或1以外的值，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，将Binlog文件缓存刷新到磁盘。

推荐设置为1，出于性能考虑也可酌情调整。


关于binlog操作与管理相关的SQL也有很多，下面介绍下部分常用的语句：

SQL语句 语句含义
show master status 查看当前最新的一个binlog日志的编号名称，及最后一个事件结束的位置
show binary logs 查看目前保留的所有binlog日志列表及大小
flush logs 刷新binlog，此刻开始产生一个新编号的binlog日志文件
purge binary logs before '2020-07-01 12:00:00' 手动清理指定时间之前的binlog日志
purge binary logs to 'binlog.000012' 将指定日志文件之前的日志清除
reset master 清空所有的binlog日志，慎用
show binlog events in 'binlog.000030' 查看指定的binlog日志event
show binlog events in 'binlog.000030' from 931 从指定的位置开始，查看指定的binlog日志
show binlog events in 'binlog.000030' from 931 limit 2 从指定的位置开始，查看指定的binlog日志，限制查询的enent数


3.解析binlog内容


前面说过，所有对数据库的修改都会记录在binglog中。但binlog是二进制文件，无法直接查看，想要更直观的观测它就要借助mysqlbinlog命令工具了，下面的内容主要介绍如何使用mysqlbinlog来解析binlog日志内容。

为了故事的顺利发展，我们首先切换下binlog，然后创建测试库、测试表，执行插入数据，更新数据。这些前置操作暂不展示，下面我们来看下如何解析并查看生成的binlog内容：

# 本次解析基于MySQL8.0版本，实例已开启gtid，模式为ROW
[root@centos logs]# mysqlbinlog  --no-defaults --base64-output=decode-rows -vv binlog.000013
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
...
...
#200708 16:52:09 server id 1003306  end_log_pos 1049 CRC32 0xbcf3de39   Query   thread_id=85    exec_time=0     error_code=0    Xid = 1514
use `bindb`/*!*/;
SET TIMESTAMP=1594198329/*!*/;
SET @@session.explicit_defaults_for_timestamp=1/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE  `bin_tb` (
  `increment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `stu_id` int(11) NOT NULL COMMENT '学号',
  `stu_name` varchar(20) DEFAULT NULL COMMENT '学生姓名',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (`increment_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='测试binlog'
/*!*/;
# at 1049
#200708 16:52:45 server id 1003306  end_log_pos 1128 CRC32 0xf19ea0a9   GTID    last_committed=2        sequence_number=3       rbr_only=yes    original_committed_timestamp=1594198365741300   immediate_commit_timestamp=1594198365741300        transaction_length=468
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1594198365741300 (2020-07-08 16:52:45.741300 CST)
# immediate_commit_timestamp=1594198365741300 (2020-07-08 16:52:45.741300 CST)
/*!80001 SET @@session.original_commit_timestamp=1594198365741300*//*!*/;
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= '0032d819-2d32-11ea-91b5-5254002ae61f:24883'/*!*/;
# at 1128
#200708 16:52:45 server id 1003306  end_log_pos 1204 CRC32 0x5b4b03db   Query   thread_id=85    exec_time=0     error_code=0
SET TIMESTAMP=1594198365/*!*/;
BEGIN
/*!*/;
# at 1204
#200708 16:52:45 server id 1003306  end_log_pos 1268 CRC32 0xd4755d50   Table_map: `bindb`.`bin_tb` mapped to number 139
# at 1268
#200708 16:52:45 server id 1003306  end_log_pos 1486 CRC32 0x274cf734   Write_rows: table id 139 flags: STMT_END_F
### INSERT INTO `bindb`.`bin_tb`
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1001 /* INT meta=0 nullable=0 is_null=0 */
###   @3='from1' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
### INSERT INTO `bindb`.`bin_tb`
### SET
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1002 /* INT meta=0 nullable=0 is_null=0 */
###   @3='dfsfd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
...
# at 1486
#200708 16:52:45 server id 1003306  end_log_pos 1517 CRC32 0x0437e777   Xid = 1515
COMMIT/*!*/;
...
# at 1596
#200708 16:54:35 server id 1003306  end_log_pos 1681 CRC32 0x111539b6   Query   thread_id=85    exec_time=0     error_code=0
SET TIMESTAMP=1594198475/*!*/;
BEGIN
/*!*/;
# at 1681
#200708 16:54:35 server id 1003306  end_log_pos 1745 CRC32 0x6f0664ee   Table_map: `bindb`.`bin_tb` mapped to number 139
# at 1745
#200708 16:54:35 server id 1003306  end_log_pos 1939 CRC32 0xfafe7ae8   Update_rows: table id 139 flags: STMT_END_F
### UPDATE `bindb`.`bin_tb`
### WHERE
###   @1=5 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1005 /* INT meta=0 nullable=0 is_null=0 */
###   @3='dsfsdg' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
### SET
###   @1=5 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1005 /* INT meta=0 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198475 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
### UPDATE `bindb`.`bin_tb`
### WHERE
###   @1=6 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1006 /* INT meta=0 nullable=0 is_null=0 */
###   @3='fgd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
### SET
###   @1=6 /* INT meta=0 nullable=0 is_null=0 */
###   @2=1006 /* INT meta=0 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */
###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
###   @5=1594198475 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */
...
# at 1939
#200708 16:54:35 server id 1003306  end_log_pos 1970 CRC32 0x632a82b7   Xid = 1516
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*/;
# 可以看出，binlog中详细记录了每条sql执行产生的变化，
并且包括执行时间、pos位点、server_id等系统值。

关于mysqlbinlog工具的使用技巧还有很多，例如只解析对某个库的操作或者某个时间段内的操作等。简单分享几个常用的语句，更多操作可以参考官方文档。


mysqlbinlog --no-defaults --base64-output=decode-rows -vv binlog.000013 > /tmp/bin13.sql

将解析到的SQL导入文件中

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --database=testdb binlog.000013

只解析某个库的操作

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-datetime="2020-01-11 01:00:00" --stop-datetime="2020-01-11 23:59:00" binlog.000008

解析指定时间段内的操作

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-position=204136360 --stop-position=204136499 binlog.000008

解析指定pos位点内的操作

mysqlbinlog --no-defaults --start-position=204136360 --stop-position=204136499 binlog.000008 | mysql -uroot -pxxxx testdb

在指定库中恢复指定位点间的操作


总结：


不知不觉写的挺长了，本文讲述了各类binlog相关知识点，希望你读完会对binlog有更深的认识。其实最重要的还是实践，只有多学多用才能更好的掌握。这么硬核的知识，希望大家用到的时候可以拿来读读，欢迎各位转发分享，让更多人看到。

文章标签：
云数据库 RDS MySQL 版
云解析DNS
日志服务
SQL
OLTP
关系型数据库
运维
MySQL
HIVE
安全
数据库
缓存
存储
关键词：
云数据库 RDS MySQL 版解析
云数据库 RDS MySQL 版binlog
mysql binlog
binlog解析
解析云数据库 RDS MySQL 版
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
MySQL技术
目录
相关文章
潇洒洒
|
14天前
|
监控 关系型数据库 MySQL
MySQL自增ID耗尽应对策略：技术解决方案全解析
在数据库管理中，MySQL的自增ID（AUTO_INCREMENT）属性为表中的每一行提供了一个唯一的标识符。然而，当自增ID达到其最大值时，如何处理这一情况成为了数据库管理员和开发者必须面对的问题。本文将探讨MySQL自增ID耗尽的原因、影响以及有效的应对策略。
潇洒洒
51 3
潇洒洒
|
15天前
|
存储 关系型数据库 MySQL
MySQL 字段类型深度解析：VARCHAR(50) 与 VARCHAR(500) 的差异
在MySQL数据库中，`VARCHAR`类型是一种非常灵活的字符串存储类型，它允许存储可变长度的字符串。然而，`VARCHAR(50)`和`VARCHAR(500)`之间的差异不仅仅是长度的不同，它们在存储效率、性能和使用场景上也有所不同。本文将深入探讨这两种字段类型的区别及其对数据库设计的影响。
潇洒洒
28 2
大数据文摘
|
17天前
|
存储 SQL 关系型数据库
mysql 的ReLog和BinLog区别
MySQL中的重做日志（Redo Log）和二进制日志（Binary Log）是两种重要的日志系统。重做日志主要用于保证事务的持久性和原子性，通过记录数据页的物理修改信息来恢复未提交的事务更改。二进制日志则记录了数据库的所有逻辑变化操作，用于数据的复制、恢复和审计。两者在写入时机、存储方式、配置参数和使用范围上有所不同，共同确保了数据库的稳定性和可靠性。
大数据文摘
35 2
游客sjjs6jgz4gp7m1
|
19天前
|
存储 关系型数据库 MySQL
PHP与MySQL动态网站开发深度解析####
本文作为技术性文章，深入探讨了PHP与MySQL结合在动态网站开发中的应用实践，从环境搭建到具体案例实现，旨在为开发者提供一套详尽的实战指南。不同于常规摘要仅概述内容，本文将以“手把手”的教学方式，引导读者逐步构建一个功能完备的动态网站，涵盖前端用户界面设计、后端逻辑处理及数据库高效管理等关键环节，确保读者能够全面掌握PHP与MySQL在动态网站开发中的精髓。 ####
游客sjjs6jgz4gp7m1
35 3
最好zzz
|
26天前
|
存储 关系型数据库 MySQL
MySQL MVCC深度解析：掌握并发控制的艺术
【10月更文挑战第23天】 在数据库领域，MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种重要的并发控制机制，它允许多个事务并发执行而不产生冲突。MySQL作为广泛使用的数据库系统，其InnoDB存储引擎就采用了MVCC来处理事务。本文将深入探讨MySQL中的MVCC机制，帮助你在面试中自信应对相关问题。
最好zzz
88 3
最好zzz
|
26天前
|
缓存 关系型数据库 MySQL
MySQL执行计划深度解析：如何做出最优选择
【10月更文挑战第23天】 在数据库查询性能优化中，执行计划的选择至关重要。MySQL通过查询优化器来生成执行计划，但有时不同的执行计划会导致性能差异。理解如何选择合适的执行计划，以及为什么某些计划更优，对于数据库管理员和开发者来说是一项必备技能。
最好zzz
42 2
喜欢猪猪
|
1月前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog：深入解析
【10月更文挑战第21天】在数据库管理系统中，日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统，提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog，从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析，并通过Java代码示例展示如何与这些日志进行交互。
喜欢猪猪
84 0
喜欢猪猪
|
10天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性，极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理，并通过Java代码手写模拟Spring Boot的启动过程，特别是spring.factories文件的解析源码API机制。
喜欢猪猪
39 2
Codelinghu
|
1月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
Codelinghu
70 0
Codelinghu
|
1月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
Codelinghu
57 0

热门文章

最新文章

  • 1
    测试开启MySQL performance_schema后对性能的影响
  • 2
    RDS入门——Excel文件转存到RDS数据库实践
  • 3
    Spring Boot整合MyBatis操作mysql数据库实战（附源码 超详细）
  • 4
    MySQL全文搜索与JSON支持：高效检索与灵活数据处理
  • 5
    JDBC操作MySQL5日期类型字段的问题解决方法
  • 6
    Mariadb/Mysql TEMPORARY表
  • 7
    MySQL的innodb_flush_log_at_trx_commit配置值的设定
  • 8
    JDBC 驱动升级到 Version 8.0.28 连接 MySQL 的踩坑记录
  • 9
    PG+MySQL第11课-多维向量搜索
  • 10
    FAQ系列 | 启用SELinux后，PHP连接MySQL异常
  • 1
    【Uniapp 专栏】基于 Uniapp 的电商应用开发案例解析
    183
  • 2
    Java 8新特性之Lambda表达式与Stream API的深度解析
    90
  • 3
    深入解析Linux tee命令：从基础用法到高级场景的全面指南
    1220
  • 4
    PandasTA 源码解析（二十三）
    72
  • 5
    PandasTA 源码解析（二十二）（3）
    63
  • 6
    PandasTA 源码解析（二十二）（2）
    61
  • 7
    PandasTA 源码解析（二十二）（1）
    63
  • 8
    PandasTA 源码解析（二十一）（4）
    71
  • 9
    PandasTA 源码解析（二十一）（3）
    63
  • 10
    PandasTA 源码解析（二十一）（2）
    63

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • MySQL 技术大全：开发、优化与运维实战
  • 搭建电商项目架构连接MySQL
  • PolarDB-X 2.0 全局 Binlog 与备份恢复能

    • 相关实验场景

    更多
  • MySQL基础-学生管理系统数据库设计
  • 如何快速连接云数据库RDS MySQL
  • MySQL数据库快速部署实践
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 使用CloudLens采集RDS日志并进行审计分析

    • 推荐镜像

    更多
  • DNS
  • mysql
  • postgresql
    • 下一篇
    无影云桌面