恐怖网站代码,网站设计的优点,wordpress最好的插件,合同模板网日志模块有两个redo log和binlog#xff0c;redo log 是引擎层的日志#xff08;负责存储相关的事#xff09;#xff0c;binlog是在Server层#xff0c;主要做MySQL共嗯那个层面的事情。redo log就像一个缓冲区#xff0c;可以让当更新操作的时候先放redo log中#xf…日志模块有两个redo log和binlogredo log 是引擎层的日志负责存储相关的事binlog是在Server层主要做MySQL共嗯那个层面的事情。redo log就像一个缓冲区可以让当更新操作的时候先放redo log中等系统不忙的时候或redo log 满了的时候再写到磁盘中redo log的大小是固定的。·这样也可以保证即使中途数据库重启也可以依照redo log把未完成写入磁盘的内容完成更新。这个能力叫做crash-safe。
redo log 是InnoDB引擎特有的而Binlog是MySQL的Server层实现的所有引擎都可以使用。
binlog会用“追加写”的形式记录所有的逻辑操作所以binlog文件写到一定大小会切换到下一个并不会覆盖以前的日志。
接下来看一下执行器和InnoDB引擎在执行一个见到的update语句时的内部流程
执行器先找引擎取 ID2 这一行。ID 是主键引擎直接用树搜索找到这一行。如果 ID2 这一行所在的数据页本来就在内存中就直接返回给执行器否则需要先从磁盘读入内存然后再返回。执行器拿到引擎给的行数据把这个值加上 1比如原来是 N现在就是 N1得到新的一行数据再调用引擎接口写入这行新数据。引擎将这行新数据更新到内存中同时将这个更新操作记录到 redo log 里面此时 redo log 处于 prepare 状态。然后告知执行器执行完成了随时可以提交事务。执行器生成这个操作的 binlog并把 binlog 写入磁盘。执行器调用引擎的提交事务接口引擎把刚刚写入的 redo log 改成提交commit状态更新完成。
关于最后三步就是我们所说的两阶段提交把redolog差写成了两个步骤prepare和commit
两阶段提交是为了让两份日志之间的逻辑一致。
如果不是两阶段提交无论是先写完 redo log 再写 binlog或者采用反过来的顺序。在两个中间MySQL进程异常重启都会发生字段的值与原库的值不同。
不只是误操作后会恢复数据当需要扩容的时候多搭建备库来增加系统的读能力的时候都需要全量备份加上应用binlog实现如果出现数据库状态“不一致”就会导致线上出现主从数据库不一致的情况。
这里借用一下别人的图如果在两阶段中间发生了crash怎么情况
如果时刻A的话binlog都没写redo log 不完整所以直接事务回滚
如果时刻B的话先判断binlog是否完整一个事务的 binlog 是有完整格式的
statement 格式的 binlog最后会有 COMMITrow 格式的 binlog最后会有一个 XID event。
完整了那就补充redo log然后恢复数据如果binlog不完整那就事务回滚。
它们有一个共同的数据字段叫 XID。崩溃恢复的时候会按顺序扫描 redo log
如果碰到既有 prepare、又有 commit 的 redo log就直接提交如果碰到只有 parepare、而没有 commit 的 redo log就拿着 XID 去 binlog 找对应的事务。
我们可以查看binlog是否完整却还是把redo log分为两阶段是因为redo log是在事务中的内容如果不分两个阶段的话完成redo log 事务就不能再回滚了这个·时候binlog写入是啊比InnoDB又回滚不了数据和binlog日志就又不一致了。
redo log存储的是数据页的更新细节binlog是更新内容。只是binlog无法实现崩溃恢复只是redo log 没法实现归档因为它是循环写。而且mysql系统还有很多地方都依赖于binlog
两个日志有相似的功能也有相异的所以两个日志都要存在所以要想同时发挥作用两阶段提交必不可少。
