mysql中图片用什么数据类型_MySQL的redolog和binlog有什么用？

良心公众号

关注不迷路

01

MySQL架构概述

在之前的文章中&＃xff0c;菜鸡曾经总结过MySQL各层级之间的关系&＃xff0c;其基本架构可以用下面这张图来大致概括&＃xff1a;

02

binlog和redo log简介

通过上面这张图&＃xff0c;我们可以轻松地描述出一次MySQL的读操作在其背后所经历的步骤。而写操作则稍许复杂&＃xff0c;因为其涉及到两个极其重要的日志&＃xff1a;binlog和redo log。

了解binlog和redo log这两个日志的作用和原理&＃xff0c;对我们恢复误操作的数据&＃xff0c;数据库横向扩容&＃xff0c;以及一些特殊需求(比如业务上要求增量写&＃xff0c;则可以通过分析一定时间段内的binlog来实现增量写)有很大的指导意义。不仅如此&＃xff0c;这两个日志相辅相成&＃xff0c;其背后的设计思想是可以借鉴到日常的开发过程中的。

话不多说&＃xff0c;接下来我们来具体看一下这两种日志。

在MySQL的Server层中&＃xff0c;有一个极其重要的归档日志&＃xff0c;称为binlog。而在InnoDB存储引擎中&＃xff0c;也有一个同样重要的重做日志称为redo log。

为什么如此强调其重要性呢&＃xff1f;

• 首先&＃xff0c;binlog作为归档日志&＃xff0c;它存储了语句的原始逻辑&＃xff0c;其主要有两种模式&＃xff1a;statement模式和row模式。statement模式记录的是原始sql语句&＃xff0c;而row模式记录的是数据行的内容。这意味着&＃xff0c;如果需要回滚数据库表&＃xff0c;或者进行数据库扩容&＃xff0c;binlog将起到重要的作用。binlog写的方式是“追加写”的。

• 其次&＃xff0c;redo log作为重做日志&＃xff0c;其记录了在某个数据页所做的修改&＃xff0c;通过顺序写代替随机写&＃xff0c;降低了IO开销&＃xff0c;同时保证了即便数据库崩溃&＃xff0c;也不会丢失之前的数据&＃xff0c;也即具备了crash-safe的能力。redo log写的方式是“循环写”的。

通过上述的总结&＃xff0c;可以得出三点结论&＃xff1a;

• 首先&＃xff0c;如果不采用InnoDB存储引擎&＃xff0c;则不具备redo log的相关功能&＃xff0c;而binlog是属于MySQL的server层的&＃xff0c;与选取何种存储引擎无关。

• 其次&＃xff0c;两种日志的侧重点是不一样的&＃xff0c;而且其中一个无法完全替代另一个。

• 进一步地思考&＃xff0c;通过binlog和redo log的结合&＃xff0c;我们可以将MySQL的状态恢复到这两个日志所保存的任意时间点的状态。之所以能够完成这个目标&＃xff0c;是因为同一个写操作的写binlog和写redo log在同一个事务里&＃xff0c;也就是说&＃xff0c;二者的状态始终能够保持一致。

03

更新操作的流程

我们可以以下面这条MySQL更新语句为例&＃xff0c;讲述一下在执行一次更新操作的过程中&＃xff0c;binlog和redo log在一次MySQL更新操作中所进行的步骤。

 mysql> update table set count &＃61; count &＃43; 1 where id &＃61; 10244201;

运行上面这条sql语句&＃xff0c;将会依次经过如下步骤&＃xff1a;

• 连接器&＃xff1a;客户端与数据库建立连接

• 分析器&＃xff1a;通过“词法分析”和“语法分析”得到这是一条查询语句

• 优化器&＃xff1a;使用id主键索引

• 执行器&＃xff1a;验证更新权限&＃xff0c;调用存储引擎接口&＃xff0c;找到这一行&＃xff0c;然后更新

在此过程中的最后一步&＃xff0c;又可以细分为如下步骤&＃xff1a;

• 执行器首先调用存储引擎接口&＃xff0c;查询到id &＃61; 10244201的这一行数据

• 将获取到的行数据对应的count字段加1&＃xff0c;得到新的行数据&＃xff0c;然后调用存储引擎的接口&＃xff0c;写入这条更新后的行数据

• 引擎将新的行数据更新到内存中&＃xff0c;同时将这个更新操作记录到redo log里面&＃xff0c;然后告知执行器执行结果&＃xff0c;此时redo log处于prepare状态

• 执行器生成该更新操作的binlog&＃xff0c;并将binlog写入磁盘

• 执行器调用引擎的提交事务接口&＃xff0c;引擎将redo log改成提交状态&＃xff0c;更新完成

上面执行器与存储引擎交互的这个过程中&＃xff0c;redo log的这个先prepare后commit的操作&＃xff0c;称为两阶段提交&＃xff0c;正是这个两阶段提交&＃xff0c;保证了binlog和redo log不会因为数据库崩溃等特殊原因而造成恢复数据不一致的问题。

我们如果用一张图对上面的两阶段提交过程加以概括&＃xff0c;大致如下&＃xff1a;

在了解了这个过程之后&＃xff0c;对于binlog和redo log所发挥的作用应该会有一个更加深刻的认识&＃xff0c;从而能够在日常工作中更加有效地利用它们。

本篇关于binlog和redo log的总结就到这里了。

欢迎大家一起讨论技术&＃xff0c;共同成长&＃xff01;

04

推荐阅读

学习 | 工作 | 分享

?长按关注“有理想的菜鸡”