网站建设包括哪些部分,简历网免费,公司要建设网站需要那些程序,seo公司哪家好用此文章为《MySQL 实战 45 讲》的学习笔记#xff0c;其课程链接可参见#xff1a;MySQL实战45讲_MySQL_数据库-极客时间 目录 一、日志系统 1、重做日志#xff1a;redo log#xff08;引擎层#xff09; 2、归档日记#xff1a;binlog#xff08;Server层#xff09; … 此文章为《MySQL 实战 45 讲》的学习笔记其课程链接可参见MySQL实战45讲_MySQL_数据库-极客时间 目录 一、日志系统 1、重做日志redo log引擎层 2、归档日记binlogServer层 3、redo log 与 binlog 的区别 4、执行器和InnoDB引擎执行update语句时的内部流程 5、两阶段提交 6、小结 7、思考题 一、日志系统 根据上一讲所讲的内容我们可以知道一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块最后到达存储引擎。 问题那么一条更新语句的执行流程又是怎样的呢 Ⅰ、首先可以确定的是查询语句的那一套流程更新语句也是同样会走一遍 Ⅱ、但是与查询流程不一样的是除了查询流程之外更新流程还涉及到了两个重要的日志模块【redo log重做日志】以及【 binlog归档日志】。 1、重做日志redo log引擎层 以酒店记账为例酒店常有两个账本一个用于快速记录当天账目的粉板一个用于记录所有账目的账簿。而粉板和账本配合的这个过程其实就是MySQL中经常说到的WAL技术。 具体来说就是当有一条记录需要更新的时候InnoDB引擎就会先把记录写到redo log粉板里面并更新内存这个时候更新就算完成了。同时InnoDB引擎会在适当的时候将这个操作记录更新到磁盘里面而这个更新往往是在系统比较空闲的时候做这就像打烊以后掌柜做的事。 那么这样的话又会出现另外一种情况即某天赊账的特别多粉板写满了又该怎么办呢 这个时候掌柜只好放下手中的活儿把粉板中的一部分赊账记录更新到账本中然后把这些记录从粉板上擦掉为记新账腾出空间。 在MySQL中也是如此InnoDB的redo log是固定大小的数据库将头开始写入数据写到末尾就又回到开头循环写其过程如下图所示 write pos是指当前记录的位置一边写一边后移写到末尾就会重新回到开头。 checkpoint是指当前要擦除的位置也是往后推移并且循环的擦除记录前要把记录更新到数据文件。 有了redo logInnoDB就可以保证即使数据库发生异常重启之前提交的记录都不会丢失这种能力被称为crash-safe。 【补充说明】 WAL技术WAL的全称是Write-Ahead Logging「预写式日志」是数据库系统中常见的一种手段用于保证数据操作的原子性和持久性它的关键点就是先写日志再写磁盘也就是先写粉板等不忙的时候再写账本。 crash-safe崩溃安全crash-safe功能是 MySQL 5.6 关于复制的一个重大改进可以解决之前版本中系统异常断电可能导致的 SQL thread 信息不准确的问题。 详细内容可参考[1] MySQL 的 crash-safe 原理解析 [2] mysql的crash-safe 2、归档日记binlogServer层 从MySQL的整体架构来看一共只有两块内容一块是Server层它主要做的是MySQL功能层面的事情还有一块是引擎层负责存储相关的具体事宜。redo log是InnoDB引擎特有的日志而Server层也有自己的日志称为binlog。 问题为什么会有两份日志这不是多次一举吗 不然这其实是历史遗留问题最开始MySQL里并没有InnoDB引擎。而MySQL自带的引擎是MyISAM但是MyISAM没有crash-safe的能力binlog日志也只能用于归档。InnoDB则是另一个公司以插件形式引入到MySQL当中的所以InnoDB只能是使用另外一套日志系统redo log来实现crash-safe能力。 3、redo log 与 binlog 的区别 Ⅰ、redo log是InnoDB引擎特有的binlog是MySQL的Server层实现的所有引擎都可以使用。 Ⅱ、redo log是物理日志记录的是“在某个数据页上做了什么修改”binlog是逻辑日志记录的是这个语句的原始逻辑比如“给ID2这一行的c字段加1 ”。 Ⅲ、redo log是循环写的空间固定会用完binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个并不会覆盖以前的日志。 4、执行器和InnoDB引擎执行update语句时的内部流程 更新语句如下所示 // 表的创建语句一个主键ID和一个整型字段c mysql create table T(ID int primary key, c int); // 将ID2这一行的值加1 mysql update T set cc1 where ID2; 如上图所示浅色框表示是在InnoDB内部执行的深色框表示是在执行器中执行的 步骤如下 Ⅰ、执行器先找引擎取ID2这一行。ID是主键引擎直接用树搜索找到这一行。如果ID2这一行所在的数据页本来就在内存中就直接返回给执行器否则需要先从磁盘读入内存然后再返回 Ⅱ、执行器拿到引擎给的行数据把这个值加上1比如原来是N现在就是N1得到新的一行数据再调用引擎接口写入这行新数据 Ⅲ、引擎将这行新数据更新到内存中同时将这个更新操作记录到redo log里面此时redo log处于prepare状态。然后告知执行器执行完成了随时可以提交事务 Ⅳ、执行器生成这个操作的binlog并把binlog写入磁盘 Ⅴ、执行器调用引擎的提交事务接口引擎把刚刚写入的redo log改成提交commit状态更新完成。 5、两阶段提交 两阶段提交其实就是将 redo log 的写入拆成了两个步骤prepare和commit。 问题来了为什么日志需要“两阶段提交”呢 这是为了让两份日志之间的逻辑一致。 如果没有两阶段提交那么假设执行update语句过程中在写完第一个日志后第二个日志还没有写完期间发生了crash会出现什么情况呢 Ⅰ、先写redo log后写binlog。由于binlog没写完就crash了这时候binlog里面就没有记录这个语句。由于这个语句的binlog丢失这个临时库就会少了这一次更新恢复出来的这一行c的值就是0与原库的值不同。 Ⅱ、先写binlog后写redo log。如果在binlog写完之后crash由于redo log还没写崩溃恢复以后这个事务无效所以这一行c的值是0。所以在之后用binlog来恢复的时候就多了一个事务出来恢复出来的这一行c的值就是1与原库的值不同。 总结如果不使用“两阶段提交”那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。简单说redo log和binlog都可以用于表示事务的提交状态而两阶段提交就是让这两个状态保持逻辑上的一致。 6、小结 物理日志redo log用于保证crash-safe能力。innodb_flush_log_at_trx_commit这个参数设置成1的时候表示每次事务的redo log都直接持久化到磁盘。这个参数建议设置成1这样可以保证MySQL异常重启之后数据不丢失。 逻辑日志binlogsync_binlog这个参数设置成1的时候表示每次事务的binlog都持久化到磁盘。这个参数也建议设置成1这样可以保证MySQL异常重启之后binlog不丢失。 详细内容可参考[1] MySQL实战 | 02-MySQL 如何恢复到半个月内任意一秒的状态 7、思考题 问题定期全量备份的周期“取决于系统重要性有的是一天一备有的是一周一备”。那么在什么场景下一天一备会比一周一备更有优势呢或者说它影响了这个数据库系统的哪个指标 答案一天一备跟一周一备的比它的好处在于“最长恢复时间”更短。在一天一备的模式里最坏情况下需要应用一天的binlog。比如你每天0点做一次全量备份而要恢复出一个到昨天晚上23点的备份。一周一备最坏情况就要应用一周的binlog了。 系统的对应指标指的是RTO恢复目标时间因为更频繁全量备份需要消耗更多存储空间所以这个RTO是成本换来的这就需要你根据业务重要性来进行取舍与评估。
