MySQL 15 日志相关问题追问

先放一下两阶段提交的图，在后续问题中会用到：

问题

在MySQL 02中，讲到为什么要使用两阶段提交时用的是反证法，说明了如果不使用两阶段提交，会导致MySQL出现主备数据不一致等问题。
那么如果在两阶段提交的不同瞬间，MySQL如果发生异常重启，是怎么保证数据完整性的呢？
如果在图中时刻A，也就是写入redo log后、写binlog前发生了崩溃，由于此时binlog还没写，redo log也还没提交，所以崩溃恢复的时候，该事务会回滚。因为binlog还没写，也不会传到备库。
如果在图中时刻B，也就是binlog写完，redo log还没commit前发送崩溃，会怎么样呢？
先看一下崩溃恢复时的判断规则：

• 如果redo log里的事务是完整的，也就是已经有commit标识，则直接提交；
  
• 如果redo log里的事务只有完整的prepare，则判断对应的事务binlog是否存在并完整：
  
  
  
  • 是，则提交事务；
    
  • 否，回滚事务。
    
  
  

因此，时刻B崩溃恢复过程中事务会被提交。
追问1：MySQL怎么知道binlog是完整的？

一个事务的binlog有完整的格式：

• statement格式的binlog，最后会有COMMIT语句；
  
• row格式的binlog，最后会有一个XID event作为标识。
  

在MySQL 5.6.2 版本后，还引入了binlog-checksum参数，用来验证binlog内容的正确性。对于binlog日志由于磁盘原因可能在日志中间出错的情况，MySQL可以通过校验该参数的结果来发现。
追问2：redo log和binlog是怎么关联起来的？

两者有一个共同的数据字段XID。崩溃恢复的时候，会按顺序扫描redo log：

• 如果碰到既有prepare，又有commit的redo log，就直接提交；
  
• 如果碰到只有prepare，而没有commit的redo log，就拿着XID去binlog找对应的事务。
  

追问3：为什么设计为，prepare的redo log+完整binlog，重启就能恢复？

这个问题也与数据与备份的一致性有关。在时刻B，binlog已经写完，之后会被从库使用，因此在主库上也要提交这个事务，才能做到一致性。
追问4：如果这样为什么还要两阶段提交？为什么不先把redo log写完，再写binlog。而等崩溃恢复要求两个日志都完整？

两阶段提交是经典的分布式系统问题，并不是MySQL独有的。如果必须要说明这样设计的原因，那就是事务的持久性问题。
对于InnoDB来说，如果redo log提交完成，事务就不能回滚。而如果redo log直接提交，然后binlog写入失败，InnoDB又无法回滚，那么数据和binlog又不一致了。
追问5：只用binlog来支持崩溃恢复可以吗？

即把流程改为：… -> 数据更新到内存 -> 写binlog -> 提交事务。
答案是不可以的。
从历史原因说，InnoDB不是MySQL的原生存储引擎，而MyISAM设计之初就没有支持崩溃恢复。
从实现上说，如果只用binlog：

如图，假如在binlog2写完但整个事务还没有commit时，MySQL发生crash，重启后引擎内部事务2会回滚，但对于事务1来说，系统认为已经提交完成，不会再应用一次binlog1。
如果InnoDB使用的是WAL技术，执行事务的时候，写完内存和日志，事务就算完成。如果之后崩溃，要依赖日志来恢复数据页。那么这种情况下，由于不应用binlog1，事务1也可能丢失，而且是数据页级别的丢失。此时，binlog里没有记录数据页的更新细节，是补不回来的。
追问6：那能只用redo log，不要binlog吗？

如果只从崩溃恢复的角度来说是可以的。
使用binlog主要是它有着redo log无法替代的功能：

• 归档。redo log是循环写，历史日志无法保留，起不到归档的作用。
  
• MySQL高可用的基础就是binlog复制。
  
• 很多公司有异构系统，这些系统靠消费MySQL的binlog来更新自己的数据。关掉binlog的话，这些下游系统就没法输入。
  

追问7：redo log一般设置多大？

如果redo log太小，会导致很快写满。
对于几个TB的磁盘，一般将redo log设置为4个文件，每个文件1GB。
追问8：正常运行的实例，数据写入后的最终落盘，是从redo log更新过来的还是从buffer pool更新过来的？

redo log并没有记录数据页的完整数据，所以它并没有能力自己去更新磁盘数据页，也就不存在“数据最终落盘，是由redo log更新过去”的情况。

• 如果是正常运行的实例，数据页被修改以后，跟磁盘的数据页不一致，称为脏页。最终数据落盘，就是把内存中的数据页写盘；
  
• 在崩溃恢复场景，如果一个数据页在崩溃恢复时丢失了更新，InnoDB会将其读到内存，然后让redo log更新内存内容。更新完成后，同上。
  

追问9：redo log buffer是什么？在写入时，是先修改内存，还是先写redo log文件？

redo log buffer是一块内存，是在事务还没commit时，先保存redo日志内容的。
真正把日志写到redo log文件（文件名为ib_logfile+数字），是在执行commit语句时候完成的。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！