论文理解

ZK的论文里面的东西感觉很多都是和ETCD相似的，之前也写过ZK的一些不同的点，原理上，毕竟其也是基于raft协议的，操作上相似感觉比较合理。

Aurora，这里面还是有很多东西的，不管是基于MySQL的改造（canal搬运log感觉很像），另外还有quorum因地制宜的使用，数据库服务与存储层服务的分层设计，简化副本复制，采用链式复制等，对这种大型服务的设计能力可见一斑。

论文总结

资料

思维导图文件：

https://pan.baidu.com/link/zhihu/79hWzOuMhjikTJ1ER3Xw1XZmQCW0JESwdsBT==

思维导图中有很多链接，以及我附带的一些文章附件，用于帮助理解。

论文翻译的地址：

Zookeeper论文翻译 - iswade’s blog

【译】Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 上篇https://link.zhihu.com/?target=https%3A//xie.infoq.cn/article/09849d56c3b18064af6c7f857)

Mysql binlog的理解

只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。

这两种日志有以下三点不同。

  1. redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。
  2. redo log是物理日志，记录的是“在某个数据页上做了什么修改”( a1 — > a2 )；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。
  3. redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。

图中浅色框表示是在innodb内部执行的，深色框表示是在执行器中执行的。

MySQL执行流程

两阶段提交是指redo log类似于事务写日志的方式，只有在确认binlog 被实际落盘时，才会出现提交redo log的情况。

分阶段失败

1 prepare阶段 2 写binlog 3 commit

当在2之前崩溃时

重启恢复：后发现没有commit，回滚。 备份恢复：没有binlog 。

结果：一致

当在3之前崩溃

重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。

备份：有binlog。

结果： 一致

binlog用于备份，redolog则保证binlog的正确性，提供crash-safe能力，redo log循环写，不持久保存，binlog则进行“归档”。

MySQL中undo的内容会被记录到redo中吗？会的

比如一个事务在执行到一半的时候实例崩溃了，在恢复的时候先恢复redo，再根据redo构造undo回滚宕机前没有提交的事务

数据被修改一般会积累再内存中(如图上)，累积一段后再刷入磁盘，如果这个时候崩溃，也不会出现什么问题，重启时会扫描binlog，没有写入磁盘的数据也会在此时被写入。