关于数据库:阿里云数据库开源重磅发布PolarDB三节点高可用的功能特性和关键技术

33次阅读

共计 3514 个字符,预计需要花费 9 分钟才能阅读完成。

简介:在 3 月 2 日的阿里云开源 PolarDB 企业级架构发布会上,阿里云数据库技术专家孟勃荣 带来了主题为《PolarDB 三节点高可用》的精彩演讲。三节点高可用性能次要为 PolarDB 提供金融级强一致性、高可靠性的跨机房复制能力,基于分布式共识算法同步数据库物理日志,主动 failover,任意节点故障后数据零失落。本议题次要介绍 PolarDB 三节点高可用的性能个性和关键技术。

在 3 月 2 日的阿里云开源 PolarDB 企业级架构发布会上,阿里云数据库技术专家孟勃荣带来了主题为《PolarDB 三节点高可用》的精彩演讲。三节点高可用性能次要为 PolarDB 提供金融级强一致性、高可靠性的跨机房复制能力,基于分布式共识算法同步数据库物理日志,主动 failover,任意节点故障后数据零失落。本议题次要介绍 PolarDB 三节点高可用的性能个性和关键技术。

直播回顾视频:https://developer.aliyun.com/…
PDF 下载:https://developer.aliyun.com/…

以下依据发布会演讲视频内容整顿:

PolarDB for PostgreSQL 三节点高可用性能次要是将物理复制与一致性协定相结合,为 PolarDB 提供金融级强一致性以及高牢靠的跨机房复制能力。

PG 原生的流复制反对异步 / 同步 /Quorum 三种同步形式。

同步复制的次要指标是保证数据不失落,但它同时也会带来三个问题:

① 无奈满足可用性的要求,备库呈现故障或网络链路抖动的时候,会影响主库的可用性,这对生产环境是不可承受的。其次它不能齐全保证数据不失落,同步复制保证数据不失落的计划是当备机没有齐全长久化 RW 日志前,主库的事务不能提交。在某种极其状况下,比方主库曾经写入了 WAL 日志,期待备库同步 WAL 日志的过程中主库产生了重启,那么在重启的过程中,日志回放的过程是不期待备库长久化的。所以回放实现后,有可能备库没有长久化,而日志在主库上回放完之后曾经对外可见了。

② 不具备故障主动切换的能力。主动切换、可用性探测等能力都依赖于内部的组件。

③ 旧的主库在故障复原之后,可能无奈间接退出到集群。比方当事务在主库上的 WAL 日志曾经长久化,而备库还未收到日志或者还未长久化。此时如果主库呈现了故障,备库切换成主库后,旧的主库从新运行后,因为在重启之前有多余的 WAL 日志,所以无奈间接从主库上拉取日志,必须依赖于其余工具对其一致性进行解决后能力退出到集群里。

异步复制相比于同步复制,性能比拟好,可用性也更高,因为备机的故障或网络链路的抖动不会影响主库,但它最大的问题是丢数据。比方原来在主库上能看到的数据,产生切换之后在备库上不存在。其次,它也不具备主动故障切换和主动探测的能力,切换后的主库无奈主动退出到集群里。

Quorum 复制应用了多数派的计划之后,可能也能保障不丢数据,但它并没有波及到当主机产生故障时如何选取新的主机;其次,每个节点的日志不统一时,如何确保日志的一致性;第三,集群产生变更的时候,如何保障集群状态最终的一致性。针对以上问题,Quorum 复制没有提供残缺的解决方案。所以实质上来说,PG 的 Quorum 复制并不是一个残缺的、不丢数据的高可用计划。

咱们的计划是将阿里外部的一致性协定 X-Paxos 引入进来协调物理复制。X-Paxos 在阿里外部和阿里云的多个产品上曾经稳固运行了很长时间,因而它的稳定性得以保障。它的的一致性协定的算法和其余的协定是相似的。

整个高可用计划是一个单点写入、多点可读的集群零碎。Leader 节点作为单点写入节点对外提供读写服务,产生了 WAL 日志后向其余节点同步。Follower 次要是承受来自于 Leader 节点的 WAL 日志,并进行回放,对外提供只读服务。

那么它的次要能力是包含以下三个方面:

保障集群内数据的强一致性,即 RPO=0。当多数派节点的 WAL 日志写入胜利后,才认为此日志在集群层面曾经提交胜利。产生故障时,其余 Follower 节点会主动与 Leader 节点对齐日志。

主动 failover。在高可用集群中,只有半数以上的节点存活,就能保障集群失常对外提供服务。因而当多数 failover 故障或多数节点网络不通的时候,并不会影响集群的服务能力。

当 Leader 节点故障或与多数派节点网络不通的时候,会主动触发集群从新选主流程,由新主对外提供读写服务。另外 Follower 节点也会主动从新的 Leader 节点上同步 WAL 日志,并且主动与新的 Leader 日志对齐。此时如果 Follower 上的日志比新 Leader 上多,则会主动从新 Leader 上对齐 WAL 日志。

在线集群变更能够反对在线增删节点、手动切换、角色变换,比方从 Leader 切到 follower 角色。此外还能反对所有节点设置选举权重,选举权重高的节点会优先被选为主。同时,集群变更操作不影响业务的失常运行,此能力的实现由一致性协定来保障。最终集群内配置达成统一,不会因为集群配置过程中的异常情况导致状态不统一的问题。

三节点高可用性能中减少了一个新的角色:Learner 节点。它没有多数派的决策权,但可能提供只读服务。

Learner 节点的日志同步状态与 Leader 无关,也不会影响 Leader,它的次要作用有两点:

① 作为加节点的中间状态。比方新加的 Leader 节点提早比拟大,如果间接将其退出到多数派里,会影响多数派的提交。因而,先以 learner 的角色退出到集群来同步数据,当它的数据根本追上 Leader 之后,再升为 follower 节点。

② 作为异地灾备节点。它不会影响主库的可用性,产生 Leader 切换之后,它能主动从新的账号同步日志,不须要内部的染指。

在集群部署方面,可能反对跨机房和跨域的部署,包含同机房三正本、同城三机房三正本,以及两地三机房五正本、三地三机房五正本等。另外跨域也能够利用 Learner 节点进行灾备,不会影响 Leader 节点的可用性。

此外,它兼容了 PG 原生的流复制和逻辑复制,可能保障上游的生产不受影响,保障上游不会呈现未提交的数据。

从前文的介绍中能够看到,在 PolarDB 的高可用计划中,至多要存储三份数据,存储老本会有所增加。针对这个问题,咱们提供了两个方面的解决方案:

首先,进步资源的利用率。Follower 节点能够作为只读节点来提供读服务,从而减少整个集群的读扩大能力;此外,反对跨节点的并行查问能力,能够充分利用各个基节点的资源。

其次,引入了日志节点,缩小资源的占用。日志节点自身不存储数据,它只存储实时的 WAL 日志,仅作为日志长久化的多数派节点之一。此日志节点自身也具备残缺的日志复制能力,能够兼容原生的流复制和逻辑复制,能够将其作为上游日志生产的源,从而缩小 Leader 节点的日志传输压力。能够依据上游日志生产的需要,来定制日志节点的网络规格或者其余资源。

一致性协定复制的基本原理次要蕴含三个方面:

① 通过原生的异步流复制来传输或同步 WAL 日志。

② 由一致性协定来推动集群的提交位点。

③ 针对主动 failover 的问题,依据一致性协定层面本身状态的变动,来驱动数据库层面的状态变动。比方心跳超时之后,可能会主动降级。

具体实现上,以 Consensus Log 为载体来推动提交位点。针对每一段 WAL 日志生成相应的 Consensus Log Entry,外面记录了 WAL 日志的完结 LSN。而后引入一个长久化依赖,保障每个 Log Entry 长久化的时候,本节点上相应位点的 WAL 日志曾经长久化胜利。

引入上述两个机制后,如果一致性协定层面认为 Consensus Log 曾经提交胜利,则意味着 Consensus Log 曾经在多数派上长久化胜利,相应位点的 WAL 日志必定也曾经长久化胜利。

以上图为例,Leader 上曾经长久化了三段 WAL 日志,在 Follower 1 节点上,尽管 log entry 的 WAL 日志曾经长久化胜利,但它对应的 Consensus Log 还未长久化胜利,所以一致性协定就认为此 Consensus Log 也没有长久化胜利。Follower 2 上 Log Entry 和 Consensus Log 没有长久化,它的 WAL 日志只继续化了一段,它的 WAL 日志段也没有长久化胜利。因而,依据一致性协定,以后 LogIndex 2 的日志在多数派节点上曾经写入胜利,以后 Consensus Log 的 CommitIndex 就是 2,对应的那 Commit LSN 就是 300。

上图为 tpmC 测试过程中 RTO 的状况。tpmC 达到 30 万左右的时候,进行 kill 主库的操作。能够看到,不到 30 秒,新的主库曾经复原了写的能力,并且复原到切换之前的程度。

原文链接
本文为阿里云原创内容,未经容许不得转载。

正文完
 0