baiwfg2
commented
3 years ago Aurora
18年第二篇主要探讨的是Aurora 利用节点本地状态避免了分布式共识算法，简化了实现代价，也提高了性能。其中LSN 扮演重要角色
materialization
redo log 被下推到存储节点，如果不做某种形式的Checkpoint，那log chain 将会越来越长，按需读的性能也会变差。所以Aurora 存储节点有 materialization 过程，不过是否做materialization 与正确性无关； 而且，它只是对有大量修改的页做materialization，不像CP 对整个log chain 做。
但，materialize 出的page 是在存储节点的cache中吧，如果挂了，启动后又重新做materialization吗？那如果一个页的修改非常多，其log 很长，materialization 时间长呢？
在Fig3 ，主写redo log 到存储层同时，也将log & metadata 传给副本节点 （如果从主收到的log 在cache中没有对应的page，则丢弃此log，否则用log applicator 去apply。为什么计算层也有log applicator ?）； 但没有谈：副本如何协同处理来自主的log 和来自存储层的Log ?
crash recovery
传统的db，启动时，从最新的CP出发，replay 那个点之后的log，可能需要很久。但是Aurora 的replay是放在存储层持续性地、异步地做，因为启动恢复不需要做太多 (那启动时做到什么程度为止？)
LSN
每个log record 存储上一个record 的LSN，前一个segment LSN,和被修改的block （这里的block 指的是volume的block还是指数据库的page ?）的前一个LSN。
PGMRPL
这是PG 的最小读LSN，在这个点之后的log 是没有读请求访问的，因此可以被GC
计算节点来计算它，会告知存储节点，因此存储节点会推进 materialized pages on disk ，方式就是将older log 合并到pages中，此后log 可以被GC
也就意味着：存储节点不仅存 log，还存 materialized pages
一致性
使用 read view 来实现SI，它代表一个点，在这点之前所有change都能看到，在这点之后的改变看不到。
在3.1 节说Aurora 不做quorum reads，这我奇怪了，不是说读要读3份吗？怎么就不quorum 了？
说Aurora db 节点知道哪个segment 有数据块的最新持久版本，直接给那个存储节点发读请求就行了，顺便记下延时便于动态调整（尽可能向延时最低的节点发）
副本上的结构一致性
所谓structural consistency，貌似是指b-tree splits & merges. 3.3 节讲得不太清楚，没看懂。。目标就是保持副本节点的读是全局一致的
membership change
4 小节讲得还是不清楚，大概意思就是当存储节点挂掉时，如何保证read quorum, write quorum 是correct, safe, and reversible
目前行业产品有以下几种，都有论文，我来一一抛出一些问题。