摘要：本文通过介绍 GaussDB(for MySQL)读写门路，剖析其可用性。
简介
数据持久性 和服务可用性 是数据库服务的要害特色。
在实践中，通常认为领有 3 份数据正本，就足以保障持久性。
然而 3 份正本，对于可用性的要求是不够的。保护 3 份统一的正本意味着，这些正本必须同时在线，零碎能力保障可用。当数据库跨多个节点分片时，某些节点不可用的概率会随着节点数量的减少而呈指数增长。
在 GaussDB(for MySQL) 中，咱们针对日志和数据采纳不同正本策略，并采纳一种新鲜的复原算法，来解决可用性的问题。
上面首先介绍写门路，而后介绍读门路，最初剖析实践上的可用性预计，并与其它正本策略进行比拟。
写门路
写门路如上图所示，上面对每一个步骤进行阐明。
1）用户事务导致对数据库页面的更改，从而生成形容更改的日志记录（redo log，上面简称 redo）。
2）将 redo 写入到 Log Stores。写入 3 份正本，并且采纳 强一致性，即 3 份均写入胜利才算胜利。
3）将事务标记为已提交（committed）。
只有集群中有三个或以上的 Log Stores 可用，该数据库就能够进行写操作（因为写入只须要抉择可用的节点即可，并不规定肯定要写入某个节点）。对于成千上万个节点的群集，这实际上意味着 100% 的写入可用性。
4）redo 写入 Log Stores 之后，会将此 redo 放入到 SAL 的 write buffer 中，之后将此 buffer 写入到治理对应 slice 的 Page Store 上。
5）当 任何一个 Page Store 正本返回胜利，此写入胜利，SAL 的 write buffer 被开释。
6）不同的 Page Store 正本之间应用 gossip 协定检测和修复缺失的日志。
空间回收
数据库运行过程中，会源源不断地产生 redo 日志。如果不将不须要的 redo 删除，能够预感，最终必定会耗尽磁盘空间。在胜利将 redo 写入所有 Slice 正本，并且所有数据库的读正本（read replica）都能够看到该记录之后，就能够将该日志从 Log Store 中删除。独立地跟踪每条 redo 的持久性很费资源，因而咱们抉择基于 LSN 来跟踪持久性。
对于 Page Store 的每个 slice，都有一个 persistent LSN，它的含意是 slice 接管到的所有日志记录中，保障间断（没有空洞）的最大 LSN。（譬如某个 slice 接管到 LSN 为 1 的 redo log 后，persistent LSN 变为 1，此时如果接管到 LSN 为 3 的 redo log，persistent LSN 仍然为 1。之后如果接管到 LSN 为 2 的 redo log，即补齐了空洞之后，persistent LSN 变为 3）。
7）SAL 能够通过定期调用 api 或者在读写接口中获取每个 slice 的 persistent LSN（在复原中也会应用）。
8）SAL 也会跟踪每个 PLog 的 LSN 范畴。如果 PLog 中的所有 redo 的 LSN 都小于数据库 persistent LSN（3 正本中最小 persistent LSN），该 PLog 可被删除。
通过下面的机制，咱们可能保障每条 redo 都至多会有三个节点上存在正本（一开始在 Plog Store 节点上有 3 正本，保障在 Page Store 节点上有 3 正本之后，将 Plog Store 节点上的正本删除，以回收磁盘资源）。
读门路
数据库前端以 page 粒度读取数据。
读取或者批改数据时，相应的 page 必须在 buffer pool 中。当 buffer pool 已满，咱们又须要引入一个 page 时，必须将某些页面从 buffer pool 中淘汰。
咱们对淘汰算法进行了批改，保障只有当所有相干 redo 日志都写入至多 1 个 Page Store 正本后，脏页能力被淘汰。因而，在最新的 redo 记录达到 Page Store 之前，保障相应的页面可从 buffer pool 中取得。之后，能够从 Page Store 中读取页面。
对于每一个 slice，SAL 保留最新 redo log 的 LSN。主节点读取 page 时，读申请首先达到 SAL，SAL 会应用上述 LSN 下发读申请。读申请会被路由到时延最低的 Page Store。如果被抉择的 Page Store 不可用或者还没有收到提供 LSN 之前的所有 redo，会返回谬误。之后 SAL 会尝试下一个 Page Store，遍历所有正本，直到读申请能够被正确响应。
可用性剖析
quorum replication
目前业界最宽泛应用的强一致性复制技术基于 quorum replication。如果每份数据在 N 个节点上存在正本，每个读取操作必须从 NR 个节点接管响应，并写入 NW 个节点。
为了保障强一致性，必须满足 NR + NW > N。业界许多零碎应用 quorum replication 的不同组合形式。例如，
1）RAID1 磁盘阵列中通常应用 N = 3，NR = 1，NW = 3；
2）PolarDB 中，N = 3，NR = 2，NW = 2；
3）Aurora 中，N = 6，NR = 3，NW = 4。
上面的剖析中，仅思考节点独自呈现不可用的场景（不思考譬如因为断点导致所有节点不可用的场景）。
假如 1 个节点不可用的概率为 x，则当 N – NW + 1 到 N 个节点同时不可用时，写申请会失败。即一个写申请失败的概率可用如下公式计算：
同理，一个读申请失败的概率计算公式如下：
GaussDB(for MySQL)
写
在后面的写门路一节中曾经提到，GaussDB(for MySQL) 的写 redo，不须要写到特定的 Log Store 上，所以公式 (1) 并不实用。对于写申请，只有当所有 PLog Store 都不可用时，才会失败。如果集群中 Log Store 足够多，这个概率简直靠近于 0。
读
对于读，每个 Page Store 节点都能够基于其 persistent LSN 决定是否能够为读提供服务。如果不能，它将返回谬误，通知 SAL 尝试另一个节点。在极少数状况下，因为级联故障，没有节点能够提供读服务（并非节点不可用），SAL 会辨认这种状况并应用 Log Store 来修复数据。在这种状况下，性能可能降落，然而存储层依然可用。
SAL 无奈复原的惟一状况是，蕴含 Slice 正本的所有 Page Store 都不可用，这样的概率是 x^3。
下表比照了 GaussDB(for MySQL) 和几种典型 quorum replication 场景的可用性：
论断
1）对于写，GaussDB(for MySQL) 总是可用的，优于 quorum replication 计划；
2）对于读，除了 x = 0.01 且 quorum 的节点个数为 6 的状况，GaussDB(for MySQL) 总是能提供比 quorum replication 雷同或更好的的可用性。并且在下面的场景下，提供的可用性曾经足够高，与 quorum replication 相差并不远。
点击关注，第一工夫理解华为云陈腐技术~