详解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 相差并不远。
点击这里→了解更多精彩内容
详解GaussDB(for MySQL)服务：复制策略与可用性分析相关推荐
- 万字详解，解锁MySQL性能优化新姿势
1 MySQL总体架构介绍 1.1 MySQL总体架构介绍 MySQL是一个关系型数据库 应用十分广泛 在学习任何一门知识之前 对其架构有一个概括性的了解是非常重要的 比如索引.sql是在哪个地方执行 ...
- grep mysql_详解grep获取MySQL错误日志信息的方法
为方便维护MySQL,写了个脚本用以提供收集错误信息的接口.这些错误信息来自与MySQL错误日志,而 通过grep mysql可以获取error-log的路径. 以下是全部相关代码: #!/usr/b ...
- （完全详解）JavaScript 添加、复制、移除、移动、创建和查找节点
(完全详解)JavaScript 添加.复制.移除.移动.创建和查找节点 一.创建新节点 1.document.createDocumentFragment() //创建一个 DOM 片段 creat ...
- navicat for mysql命令行_详解 Navicat for MySQL 命令工具
Navicat for MySQL是一套管理和开发MySQL或MariaDB的理想解决方案,支持单一程序,可同时连接到MySQL和MariaDB.这个功能齐备的前端软件为数据库管理.开发和维护提供了直 ...
- 多维度详解redis以及原理实现，结构与应用分析
6个方面了解redis应用及其实现原理 1.redis数据存储概述 2.string结构以及应用 3.list结构以及应用 4.hash结构以及应用 5.set结构以及应用 6.zset结构以及应用 ...
- mysql 流复制_MySQL系列详解六：MySQL主从复制/半同步演示-技术流ken
前言 随着技术的发展,在实际的生产环境中,由单台MySQL数据库服务器不能满足实际的需求.此时数据库集群就很好的解决了这个问题了.采用MySQL分布式集群,能够搭建一个高并发.负载均衡的集群服务器.在 ...
- 【华为云技术分享】深度详解GaussDB bufferpool缓存策略
摘要:华为云GaussDB(for mysql)是华为云自主研发的最新一代云原生数据库,采用计算存储分离.日志即数据的架构设计.具备极致可靠.极致性价比.多为扩展.完全可信等诸多特性. 一 .Gaus ...
- MySQL系列详解六：MySQL主从复制/半同步演示-技术流ken
前言 随着技术的发展,在实际的生产环境中,由单台MySQL数据库服务器不能满足实际的需求.此时数据库集群就很好的解决了这个问题了.采用MySQL分布式集群,能够搭建一个高并发.负载均衡的集群服务器.在 ...
- DAMP环境搭建详解 DAMP----Debian Apache2 Mysql PHP5
DAMP环境搭建详解 DAMP----Debian Apache2 Mysql PHP5 1. 更新Debian apt-get update apt-get updgrade 2. 安装Samba服 ...
最新文章
- mysql 5.7.20 安装_MySql 5.7.20安装
- 开启注册丨NeurlPS 2021论文预讲会议题全公开，4大主题和25场报告等你来
- ResNet最强改进版来啦！ResNest在多项任务中达到SOTA
- webpack 配置文件.conf.js 浅理解
- PHP7CMS 无条件前台GETSHELL
- Java常见排序算法
- “抢滩”中高端酒店，新老玩家谁会更先跑出来？
- idea的pom变成橙色的xml文件
- 计算机原理及应用课程,课程介绍
- 关于html标签元素的data-*属性
- 打开Jupyter Notebook 时报错：EnvironmentLocationNotFound: Not a conda environment:
- tomcat服务器开启gzip功能的方法
- 二叉树的遍历-C++
- jQuery.ajax 调用 服务（.aspx，.asmx）
- 全网首发：(解决办法)MAC OS Xcode给应用设置沙箱(Enable App Sandbox)之后，运行报错Illegal instruction: 4
- Delphi实现文件下载UrlDownloadToFile
- matlab中uigetfile的使用
- WPF——自定义日历
- 微信小程序数据库操作之更新数据(转载)
- java到达时间后自动执行代码_java设置按时间自动执行
热门文章
- 惊艳的HTML5粒子动画特效
- java 插入数据 主键_JDBC插入数据返回数据主键代码实例
- centos7 python3安装numpy_centos下pip3安装numpy
- bullzip ms access to mysql_Bullzip MS Access To MySQL(Access转MySQL工具)
- VS2010 + C#4.0使用 async + await
- 一 python编程基础
- 一些移动端的ui框架
- [hdu2243]考研路茫茫——单词情结(AC自动机+矩阵快速幂)
- Android基础学习第二篇—Activity
- Android getResources的作用和需要注意点