MySQL中的binlog和redo浅析(r12笔记第5天)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:    有一个小问题可能很多人都想起过,那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单,但是细细品来,还是有不少值得注意的地方。

   有一个小问题可能很多人都想起过,那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单,但是细细品来,还是有不少值得注意的地方。

    对于数据恢复,尤其是异常宕机的情况下,再次启动的时候,如何恢复,恢复的数据依据,这个尤为重要,在MySQL中是有checkpoint的技术来做一个基本的检查点控制,也就是常说的LSN,对于事务性数据库,大都会采用write ahead log的策略,即当前事务提交的时候,先写redo,在修改相应的页,如果发生宕机导致数据丢失的时候,可以通过重做日志来完成数据的恢复,但是MySQL和其它有些数据库有些特别的是这个binlog,它不是采用checkpoint的实现方式,我们可以设想这样一个情况,一个事务提交的时候,信息会写入redo,而在这个操作的过程中,其实binlog的写入也是同步的,如果redo的信息在redo log buffer中可能还没有刷新到磁盘中,出现宕机的情况,就可能导致从库的数据已经应用了binlog传输的数据变化,而redo中还没来得及提交,这可能就会有数据不一致的情况发生,如果在异常状态下启动数据库就会开启数据恢复的模式,可能从库的数据就会出现不一致。

   这种情况听起来有些特别,但是对于我们理解redo和binlog的问题蛮有帮助,我们来做一个测试吧,仅仅在测试环境中进行调试所用。

首先为了减少数据的变更影响,我们先做一个flush logs的操作,尽可能保留少,数据变化新的日志内容

在主库端切换日志:
flush logs;

查看binlog的情况,使用show master status或者show binary logs都可以。
mysql> show master status\G
*************************** 1. row ***************************
             File: binlog.000014
         Position: 230
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 1bb1b861-f776-11e6-be42-782bcb377193:1,
25ee7482-07cd-11e7-a40c-0026b935eb76:1-1502468
1 row in set (0.00 sec)

我们得到mysql服务的进程号。
# ps -ef|grep -w mysqld|grep -v grep|awk '{print $2}'
1751

我们创建一个表test 字段为id和name(id int ,name varchar(20))

已经存在4条数据如下:

mysql> select *from test.test;
+------+------+
| id   | name |
+------+------+
|    1 | aa   |
|    2 | bb   |
|    3 | cc   |
|    4 | dd   |
+------+------+
4 rows in set (0.00 sec)


从库 查看数据和主库此时是同步的。这是我们测试的一个基础。

我们可以通过gdb的方式进行简单调试。
# gdb -p 1751

就马上进入了调试模式,我们可以设置一个断点。


我们在设置断点之前先插入2条数据,从库此时也是5条数据。

mysql> insert into test values(5,'ee');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test values(6,'ff');
Query OK, 1 row affected (0.00 sec)

然后设置断点,这是关键所在。
(gdb) b MYSQL_BIN_LOG::process_commit_stage_queue
Breakpoint 1 at 0xec73ca: file /export/home/pb2/build/sb_0-21378219-1480347226.17/mysql-5.7.17/sql/binlog.cc, line 8430. (2 locations)


然后在主库尝试插入一条记录
insert into test values(7,'gg');
毫无疑问,这条语句会hang住。因为我们的断点就在提交的时候。

这个时候我们前进一小步,使用c即continue

(gdb) c
Continuing.
[Switching to Thread 0x409c0940 (LWP 1798)]

Breakpoint 1, MYSQL_BIN_LOG::process_commit_stage_queue (this=0x1e8ba00, thd=0xec254e0, first=0xec254e0)
    at /export/home/pb2/build/sb_0-21378219-1480347226.17/mysql-5.7.17/sql/binlog.cc:8430
8430    /export/home/pb2/build/sb_0-21378219-1480347226.17/mysql-5.7.17/sql/binlog.cc: No such file or directory.
        in /export/home/pb2/build/sb_0-21378219-1480347226.17/mysql-5.7.17/sql/binlog.cc
这个时候那条SQL语句依旧是hang的状态,但是可以看出堆栈,binlog是写入完成了


从库此时是应用了数据变更,此时是7条数据。
我们也可以抓取一下binlog,看看里面是否已经写入了数据。
[root@grtest s1]# /usr/local/mysql/bin/mysqlbinlog -vv binlog.0000014
可以明显看到这样的语句:

...

BINLOG '
DK3KWBPqDAAALgAAAHcDAAAAAOUAAAAAAAEABHRlc3QABHRlc3QAAgMPAhQAAw==
DK3KWB7qDAAAJwAAAJ4DAAAAAOUAAAAAAAEAAgAC//wHAAAAAmdn
'/*!*/;
### INSERT INTO `test`.`test`
### SET
###   @1=7 /* INT meta=0 nullable=1 is_null=0 */
###   @2='gg' /* VARSTRING(20) meta=20 nullable=1 is_null=0 */
# at 926
#170316 23:19:40 server id 3306  end_log_pos 953        Xid = 55
COMMIT/*!*/;
我们此时模拟宕机的情况,杀掉进程

 kill -9 1751 29617

然后把binlog改个名字,关闭log_bin
[root@grtest s1]# mv binlog.000014  binlog.000014.bak
再次启动之后,就会发现此时的主库中数据还是6条,而从库却是7条。
  而如果我们把binlog改回来,开启log_bin并启动主库
mv binlog.000014.bak binlog.000014

   然后再次查看数据,就会发现主从库此时的数据竟然不同。从库的数据明显要多,这也就从一个侧面映射了我们开始的一个设想,在异常宕机的情况下,redo的数据还没有刷新到redo文件中,此时已经写入了binlog,这样就在这样一个临界点导致了主从数据的不一致。

   当然我是使用一个调试的态度来做的测试,里面还有很多技巧需要巩固。



相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
3天前
|
SQL 存储 关系型数据库
Mysql优化提高笔记整理,来自于一位鹅厂大佬的笔记,阿里P7亲自教你
Mysql优化提高笔记整理,来自于一位鹅厂大佬的笔记,阿里P7亲自教你
|
2天前
|
SQL 资源调度 关系型数据库
实时计算 Flink版产品使用合集之在抓取 MySQL binlog 数据时,datetime 字段会被自动转换为时间戳形式如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
9 2
|
2天前
|
关系型数据库 MySQL 数据处理
实时计算 Flink版产品使用合集之在同步MySQL的时候卡在某个binlog文件处如何解决
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
12 1
实时计算 Flink版产品使用合集之在同步MySQL的时候卡在某个binlog文件处如何解决
|
3天前
|
Prometheus Cloud Native 关系型数据库
实时计算 Flink版产品使用合集之binlog被清理掉的问题,并且binlog有备份,有什么方法来恢复到RDS
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
20 2
|
3天前
|
关系型数据库 MySQL Java
实时计算 Flink版产品使用合集之如果MySQL的binlog保存时间只有三天,那么三天之前的数据是不是会通过Doris的外表手动插入
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
12 0
|
5天前
|
存储 关系型数据库 MySQL
【MySQL系列笔记】分库分表
分库分表是一种数据库架构设计的方法,用于解决大规模数据存储和处理的问题。 分库分表可以简单理解为原来一个表存储数据现在改为通过多个数据库及多个表去存储,这就相当于原来一台服务器提供服务现在改成多台服务器组成集群共同提供服务。
28 8
|
5天前
|
存储 SQL 关系型数据库
MySQL万字超详细笔记❗❗❗
MySQL万字超详细笔记❗❗❗
78 1
MySQL万字超详细笔记❗❗❗
|
5天前
|
SQL 关系型数据库 MySQL
【MySQL系列笔记】MySQL总结
MySQL 是一种关系型数据库,说到关系,那么就离不开表与表之间的关系,而最能体现这种关系的其实就是我们接下来需要介绍的主角 SQL,SQL 的全称是 Structure Query Language ,结构化的查询语言,它是一种针对表关联关系所设计的一门语言,也就是说,学好 MySQL,SQL 是基础和重中之重。SQL 不只是 MySQL 中特有的一门语言,大多数关系型数据库都支持这门语言。
240 8
|
5天前
|
SQL 关系型数据库 MySQL
【MySQL系列笔记】常用SQL
常用SQL分为三种类型,分别为DDL,DML和DQL;这三种类型的SQL语句分别用于管理数据库结构、操作数据、以及查询数据,是数据库操作中最常用的语句类型。 在后面学习的多表联查中,SQL是分析业务后业务后能否实现的基础,以及后面如何书写动态SQL,以及完成级联查询的关键。
204 6
|
5天前
|
存储 安全 关系型数据库
Mysql 的binlog日志的优缺点
MySQL的binlog(二进制日志)是一个记录数据库更改的日志文件,它包含了所有对数据库执行的更改操作,如INSERT、UPDATE和DELETE等。binlog的主要目的是复制和恢复。以下是binlog日志的优缺点: ### 优点: 1. **数据恢复**:当数据库出现意外故障或数据丢失时,可以利用binlog进行点恢复(point-in-time recovery),将数据恢复到某一特定时间点。 2. **主从复制**:binlog是实现MySQL主从复制功能的核心组件。主服务器将binlog中的事件发送到从服务器,从服务器再重放这些事件,从而实现数据的同步。 3. **审计**:b

推荐镜像

更多