海南省住房建设厅网站,数据分析一般用什么软件,询盘网站,安徽省城乡建设信息网MySql系列整体栏目 内容链接地址【一】深入理解mysql索引本质https://blog.csdn.net/zhenghuishengq/article/details/121027025【二】深入理解mysql索引优化以及explain关键字https://blog.csdn.net/zhenghuishengq/article/details/124552080【三】深入理解mysql的索引分类覆盖索引(失效)回表MRRhttps://blog.csdn.net/zhenghuishengq/article/details/128273593【四】深入理解mysql事务本质https://blog.csdn.net/zhenghuishengq/article/details/127753772【五】深入理解mvcc机制https://blog.csdn.net/zhenghuishengq/article/details/127889365【六】深入理解mysql的内核查询成本计算https://blog.csdn.net/zhenghuishengq/article/details/128820477【七】深入理解mysql性能优化以及解决慢查询问题https://blog.csdn.net/zhenghuishengq/article/details/128854433【八】深入理解innodb和buffer pool底层结构和原理https://blog.csdn.net/zhenghuishengq/article/details/128993871【九】深入理解mysql执行的底层机制https://blog.csdn.net/zhenghuishengq/article/details/128100377【十】深入理解redologundolog和binlog的底层原理https://blog.csdn.net/zhenghuishengq/article/details/129183623【十一】深入理解mysql集群的高可用机制https://blog.csdn.net/zhenghuishengq/article/details/126239652【彩蛋篇】深入理解顺序io和随机iohttps://blog.csdn.net/zhenghuishengq/article/details/129080088深入理解redologundolog和binlog的底层原理和关系一 深入理解Redolog日志底层原理1innodb引擎底层事务原理1.1WAL2redolog日志文件2.1为什么要redolog日志文件2.2redolog的内部结构2.3redolog的刷盘时机2.4Log Sequence Number2.5innodb_flush_log_at_trx_commit3undolog日志3.1undolog回滚的方式3.2undolog事务id形成机制3.3插入操作3.4删除操作3.5更新操作3.5.1不更新主键3.5.2更新主键4事务的整体执行流程5redolog和binlog的关系5.1为什么用redolog恢复数据而不用binlog5.2binlog和redolog如何保证数据的一致性一 深入理解Redolog日志底层原理
再看本篇文章之前可以结合【9】深入理解mysql执行的底层机制 这篇文章来了解mysql内部执行sql的过程。
1innodb引擎底层事务原理
事务的四大特性主要是是acid分别是原子性、一致性、隔离性和持久性。其原子性是 通过这个undolog 来保证的持久性是 通过redolog 来实现的隔离性是通过事务的 读写锁mvcc机制 来实现的。在这四大特性中一致性C是最重要的他是最终目的只有其他三个实现了才有可能实现这个一致性即 一致性是最终目的其他三个就是实现的手段 。
1.1WAL
在事务的具体实现的机制中mysql是通过这个WAL(Write-ahead logging)即预写日志的方式来实现的。
举个基本的例子假设一个转钱的操作如果A给B转钱此时A减了100而在B在加100的时候突然断电了那么在数据库重启的时候就得恢复他断电前的状态此时就需要一个日志来记录他事务操作前的状态了通过这个日志中的记录来恢复之前的状态判断其是否需要回滚操作还是需要重做等操作。而实现这个WBL机制主要是通过这个redolog和undolog这两种日志的方式实现。
mysql中除了使用这种主流的WAL机制之外还会使用一些Commit Logging丶Shadow Paging等。mysql默认使用这个WAL机制。
2redolog日志文件
2.1为什么要redolog日志文件
依旧拿一个更新语句举例如下图redolog是发生在第4步和第5步在数据在buffer pool中进行数据更新之后会把具体的逻辑语句如哪一页哪一行要更新的字段以及更新的值是啥先加入到redolog buffer中随后再然后通过追加的方式持久化到磁盘上的redolog文件中再不考虑server层的操作即跳过67步那么就会启动一个后台线程进行一个落盘的操作。 这里假设innodb内部没有这个redolog这个日志文件就是在数据更新之后直接从buffer pool将数据给落盘如果在落盘的时候数据页没有发生损坏那么双写机制就触发不了就没有换页的操作此时发生断电那么还没来的及落盘的数据就会直接丢失了这就会影响数据的安全性和持久化。
除了断电这个问题还有可能因为一个小小的更新语句就直接将整页数据给进行落盘操作这样就很浪费成本或者遇到一个sql很复杂需要涉及的表很多并且数据量很大那么就需要更改很多页目录的数据如果这些页目录在磁盘上的分布是随机的那么在刷盘写数据的时候就会产生大量的随机io因此也很影响内部的执行效率和浪费空间。
所以为了解决数据的安全性以及innodb的执行效率就引入了这个redolog日志文件就是在落盘时先写一份到redolog中并且写数据是顺序写在redolog写成功之后再进行落盘操作如果出现断电问题就用这个redolog这个文件进行数据的重做。
2.2redolog的内部结构
redolog主要是记录了哪些数据做了什么修改因此这个redolog有一个通用的格式如下图 keyvaluetype就是值数据的类型类型总共有53种Space ID表空间id即修改的对应表空间的idpage Number当前页的页号data要修改的内容
2.3redolog的刷盘时机
在innodb的体系结构中可以发现在左边的内存结构中是有一个Log Buffer的缓冲区的该缓冲区就是对应的redolog缓冲区在该缓冲区中其默认大小为16M并且内部分成了多个小块每一块的大小空间为512kb。在数据写入这个redolog的缓冲区的时候会从头到尾的以追加的方式将数据写入这些块中如果后面的块快写满那么会将前面头部的块的数据删掉然后再从头到尾开始存储数据磁盘上面的redolog页结构和这个一样。 而这个缓冲区刷盘的情况有好几种如下
1log buffer空间不足时虽然说redolog缓冲区数据存满会将前面的数据删除再重新存储但是删除之前也是要考虑数据的持久化的innodb内部认为当数据量达到redolog缓冲区空间的一半大小时就需要强制的进行一次刷盘操作从而把日志落盘到磁盘上。
2事务提交时在事务提交时也是需要将缓冲区中对应的那些日志数据刷新到磁盘的
3后台默认线程后台也是会启动一个默认的线程进行一个刷盘操作的如每一秒刷新一次
4服务器手动关闭在服务器关闭时也是需要将未刷盘的数据全部的进行一次刷盘操作。
2.4Log Sequence Number
简称LSN顾名思义这个就是一个日志序列号。和undolog一样在执行一条更新或者插入语句的时候就会生成一个事务id这里的序列号和undolog的事务id的作用是一样的主要是是保证数据的唯一性。该值是一个自增的序列号初始大小为8704后面每增加一条数据其对应的序列号的值就会加1。即LSN的值越小那么其事务产生的越早。
除了这个日志之外innodb内部还有其他的LSN用来记录已经刷盘的事务id。可以通过具体的命令来查看系统中各种LSN的值
SHOW ENGINE INNODB STATUS\GkeyvalueLog sequence number已经写入redolog buffer的日志量(累加值)Log flushed up to已经写入磁盘的redo日志量
2.5innodb_flush_log_at_trx_commit
在数据进行刷盘的时候数据也不是直接的从redolog缓冲区将数据直接刷到磁盘内部而是需要调用操作系统通过操作系统进行一个落盘的操作。在操作系统中会有一个操作系统的缓冲区数据会先在缓冲区中存放然后再通过操作系统的调度将数据进行一个落盘的操作。
这个系统变量的名称就是innodb_flush_log_at_trx_commit可以提供给外部调用如kafkamysql都对这个变量进行了调用。这个变量总共有三个参数分别是0、1、2不同的参数代表着不同的含义
该值为0时表示在事务提交时不立即向磁盘中同步redo日志这个任务是交给后台线程做的。
该值为1时表示在事务提交时需要将redo日志同步到磁盘可以保证事务的持久性这个是mysql设置的系统默认值当事务提交时会进行一个强制刷盘的操作。
该值为2时表示在事务提交时需要将redo日志写到操作系统的缓冲区中但并不需要保证将日志真正的刷新到磁盘。如果数据还在操作系统缓存中突然断电那么未落盘的数据也会丢失。
3undolog日志
上面主要了解redolog日志redolog主要是为了保证这个数据的持久性ACID中的D就是靠这个redolog来保证的。而接下来要讨论的undolog日志undolog日志主要是为了保证数据的原子性在mvcc那篇https://blog.csdn.net/zhenghuishengq/article/details/127889365中也详细的分析了这个undolog也详细的描述了undolog日志版本链路和readview结合来保证事务的隔离性接下来再对这个undolog分析一波。
3.1undolog回滚的方式
undolog日志中主要是记录被修改或者新增的值的记录当需要回滚时则将这个存储undolog的值用来回滚。其回滚情况主要有如下几种
1当插入一条记录时需要把这条记录的主键值记下来回滚的时候只需要把这个主键值对应的记录删掉。
2当删除了一条记录需要要把这条记录中的内容都记下来回滚时再把由这些内容组成的记录插入到表中。
3当修改了一条记录需要要把修改这条记录前的旧值都记录下来回滚时再把这条记录更新为旧值。
3.2undolog事务id形成机制
在mysql中主要有只读事务和读写事务。在只读事务中普通的表是不能进行增删改操作的而临时的表是可以进行增删改的而读写事务中是都可以进行增删改操作的。同时在只读事务中由于临时表可以进行增删改因此只读事务的临时表中也是可以产生这个事务id的。
undolog产生的事务id和这个LSN这个序列号是一样的也是一个自增的全局变量id在innodb中每一行数据都会有一个存储这个事务id的地方在之前的行格式中也谈到过这些隐藏聚簇索引id事务id回滚指针等都存储在这些行格式中。如下图中的row_id,trx_id,roll_ptr等 3.3插入操作
在数据进行插入的操作时如果此时表中有着二级索引那么此时除了向主键索引所在的B树中存放整行数据还要向二级索引中存放对应的列以及主键id这个字段。如果出现数据回滚的情况那么不仅要删除主键索引中的数据也要删除二级索引中对应的数据但是这个id即存在一级索引中也存在二级索引中因此undolog在记录这个插入操作的数据的时候直接将该行数据的主键id值存放在这个undolog的版本链路中如果出现回滚的话是那么直接通过id删除就能把数据全部回滚回去了。
3.4删除操作
在数据进行删除时 会需要用到行格式中的一个delete_mask 字段这个字段在记录头信息里面如果该字段为0则表示没有删除该字段为1表示已经删除。 在innodb中为了保证mvcc的多版本并发控制机制redolog在删除时引入了一个中间状态即在删除时先引用逻辑删除将delete_mask这个字段将值变为1随后在事务提交之后再通过后台启动一个线程通过轮询方式去收集这个字段为1的那些行数据然后再将值给删除。
由于所有的数据都是通过双向链表的方式串在一起因此在删除的时候只需要将链表的前驱和后继修改即可并且会将这个需要删除的数据挂载这个Page Free页的上面。Page Free页面上的数据表示该空间上面的页面可以被重复利用。
3.5更新操作
在update方面就会相对的比新增和删除两种方式更加的麻烦一些主要分为更新主键和不更新主键。
3.5.1不更新主键
在不更新主键时又分为就地更新和物理删除再插入。如果在对某个字段做更新时其要更新的值的长度不变那么就会直接选择就地更新如原来的值为张三现在将值改为李四改变的值的长度不变那么就不会影响整页数据的结构其选择就地更新如果更新值的长度和原来的长度不一样如原来是一个张三现在变成了张三丰他的值很明显不一样那么就会选择先删除旧记录再插入新的记录。换句话说就是看空间大小是否发生改变不变则就地更新变则先删除后插入。
3.5.2更新主键
更新主键操作和删除操作有点类似为了保证mvcc机制也是通过记录头信息中的delete mask字段来作为一个中间状态即将这个字段的值改为1然后再事务提交之后再将这条数据删除。删除之后再新增一条数据根据新的主键值在B树中找到新的定位然后将数据新增到此地。就是更新主键可以看成是两步操作先delete操作再insert操作因此在更新主键时就会产生两条undo日志。
4事务的整体执行流程
通过上面的redolog和undolog的可知redolog是为了保证事务的持久性他具有重做的功能undolog是为了保证事务的原子性他具有撤回的功能。因此在开启一个事务时可以总结一下各个日志中的作用已经整个事务的执行流程。
1以一个更新语句为例在开启事务之后会将磁盘中要更新的数据以页的方式加载到buffer pool缓冲区中
2在执行更新语句时会通过undolog记录被修改的值。在innodb中为了保证undolog日志本身的持久性因此也会通过一个redolog日志来记录里面新增的记录如undolog的版本控制链路新增一个结点时redolog就会记录在这条链表的什么位置加入了哪个结点记录完之后将记录加入到Redolog的缓冲区中再通过一定的方式进行刷盘持久化所以在整个事务的过程中redolog比undolog先刷盘。随后将要改变的值加入到buffer pool中
3在buffer pool中执行sql的更新将要更新逻辑语句也加入到Redolog缓冲区中此时也会有一个redolog刷盘操作。
4 在提交事务时也会让对应的redolog日志记录进行一个刷盘操作。
5随后undolog会进行刷盘操作buffer pool中的数据也会通过后台的线程进行一个数据刷盘的操作。
6在undolog日志和redolog日志数据页全部刷盘完成之后事务执行完毕。
5redolog和binlog的关系
从下图来看redolog是属于引擎层的即属于innodb存储引擎特有的而binlog是属于server层的即所有的引擎层共有innodb有MyIsam也有。从整个流程来看binlog和redolog都是对一份数据进行的存储并且在存储过程中需要通过事务标记来保证两个日志中记录的值一样。 5.1为什么用redolog恢复数据而不用binlog
1binlog 会记录表中所有更改操作包括更新删除数据更改表结构等等主要用于人工恢复数据如开了binlog删库也不用跑路而redolog主要是mysql内部使用的在数据库突然崩溃mysql内部会自动的通过这个redolog进行一个重做的操作。
2redolog是Innodb引擎层特有的binlog是Server层实现的
3redolog记录的是物理日志如在哪一页哪一行哪个字段做了什么修改其效率更高binlog就是原始的逻辑和原来的sql差不多
4redolog默认大小为48M其内存是有限的因此其内部是通过循环写的方式去保存数据并且其内部只记录为刷盘的数据已刷盘的数据会自动的从这个redolog中删除binlog采用的是追加写所有的记录都会保存。而在恢复数据的时候只需要恢复这部分未刷盘的即可不需要全部就行一个对比再操作。
5如果再一个事务中出现两条相同的sql如set age age 1 where id 2如果binlog一条刷盘成功一条刷盘失败那么他是不能区分这两条是有没有全部刷盘成功或者失败的换句话说就是由于已经有一条成功了那么就不能保证是第一条成功了还是第二条成功了因此不管是全部恢复还是全部不恢复内部的数据肯定不对而redolog就不一样了只需要把redolog内部未刷盘的进行一个刷盘操作就好了。
5.2binlog和redolog如何保证数据的一致性
mysql中主要使用2pc两阶段提交来保证数据的一致性。第一阶段就是先做一个准备工作开启一个事务提交器让所有的资源准备好然后会去收集所有的资源状态当所有资源的状态都准备好了之后再进入第二阶段发出一个commit的命令所有的资源进行一个commit提交。
