小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

文章图片

小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

文章图片

小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

文章图片

小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

文章图片

小米科技|一生挚友redo log、binlog《死磕MySQL系列 二》

文章图片


系列文章

  • 原来一条select语句在MySQL是这样执行的《死磕MySQL系列 一》
  • 一生挚友redo log、binlog《死磕MySQL系列 二》
前言
上期根据一条查询语句查询流程分析MySQL的整体架构 。 同样 , 本期也使用一条查询SQL语句来做引子 。 可以肯定的是 , 查询语句执行的流程更新语句同样也会执行 。
因此本期的着重点就不在MySQL架构图上 , 文章标题也给出了大家重点 , 就是要了解redo log、binlog 。
一、redo  log第一步 , 创建一个表 user , 主键是 id , 下面是创建语句 。
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT
`name` varchar(255) NOT NULL
`age` tinyint(4) NOT NULL
`time` int(11) NOT NULL
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

插入一条数据
insert into user (`name``age``time`) values (\"咔咔\"\"25\"unix_timestamp(now()))

若要将插入的这条数据的age改为26 , 则需要执行语句
update user set age = 26 where id = 1;

第一期文章中提到一条查询语句的执行流程 , 该流程与更新语句相同 。 这里将那幅图拿过来在熟悉一下 。

每个模块的功能可以回到第一期文章去查看 。
在MySQL8.0中redo log、binlog日志文件都位于/var/lib/mysql此目录下 , 如图

文件名为ib_logfile的是重做日志 , undo开头的就是回滚日志 , 对于回滚日志后期进行详细的讨论 。
redo log(重做日志)是实现事务持久性必备要素 , 当一个事务提交后 , 并非直接修改数据库的数据 , 而是首先保证在 redo log中记录相关的操作 。
Innodb存储引擎中的redo log大小是固的 , 上图显示配置了一组两个文件 , 每个文件大小默认为48M , 使用innodb_log_file_size参数来控制单个文件大小 , 在MySQL5.6.8以及之后版本都默认为48M 。

然后redo log可以记录48M的操作 , redo log是一个闭环的循环写 。 所设定的文件个数和文件大小不再增加 。

write pos将记录当前位置 , 同时向后移动 , 在ib-log-file-3文件末尾后 , 然后返回ib-logfilg-0文件开始写 。
check point记录的是当前擦除的位置 , 要使文件循环写入 , 必须一边擦除 。 清除数据的前提是要将记录更新到数据文件 。
上面的绿色部分就是可写的部分 , 假设如果 writepos追上了 checkpoint , 那该怎么办?
你必须理解write pos的推进是因为在执行更新操作 , 这样就不能再执行更新操作 , 直到记录更新到数据文件 , 然后check point进行擦除后才可以继续执行更新操作 。
对于innodb_log_file_size的设置也是有一些计算规则的 , 下面将为你介绍 。
若innodb_log_file_size设置太小 , 将导致redo log文件频繁切换 , 频繁的触发数据库的检查点(check point) , 导致记录更新到数据文件的次数增加 , 从而影响IO性能 。
同样 , 如果有一个大的事务 , 并且所有 redo log日志都已写满 , 但是还没有完成 , 将导致日志无法切换 , 从而导致 MySQL直接堵死 。