searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

Patroni简单介绍

2023-09-26 06:59:15
195
0

引言

高可用概念

高可用(High Availability)是系统所能提供无故障服务的一种能力。简单地说就是避免因服务器宕机而造成的服务不可用。

如果一台系统能够不间断的提供服务,那么这台系统的可用性是100%。如果系统运行100个时间单位内有1个时间单位无法提供服务,那么该台系统的可用性是99%。

在实现系统高可用的架构设计中,核心准则是:冗余。

通过冗余机制,可以保障集群所部署的服务在全天候24小时内不间断运行,即使其中某台机器宕机,可以通过集群中的其他机器接替提供服务。因此,冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。

故障场景

假设有两个数据库,一个primary,一个standby,主库通过流复制将日志传给备库,备库监控主库是否健康:

当发生连接故障时当发生连接故障时,备节点升主,此时主库对外访问正常,引起脑裂:

使用第三服务器witness,同时监控主库和备库,witness实时进行心跳确认,一旦主库出现问题,witness就能清楚的知道情况,然后做故障转移:

但当witness出现故障,无法发生切换:

另外一个情况就是主库和witness出现了网络问题,无法访问主库的情况下,witness也会提升备库,但是主库其实对外访问是正常的:

Patroni的介绍

Patroni是一个PostgreSQL高可用的分布式配置模板,实际使用中相当于一个守护程序,由Zalando研发,python开发的开源项目,能够通过分布式存储系统(Distributed configuration system, DCS)来检测存储数据库集群各个节点的状态和配置,并 且能够对数据库集群进行自动管理和故障切换。

一个高可用集群由patroni、DCS和数据库组成,DCS可以选用ZooKeeper、etcd、Consul或Kubernetes其中一个。

自动故障恢复

  • 集群中健康成员间的领导者选举竞争
  • 每个成员自主做出决策
  • 集群状态存储在一致性的分布式存储中
  • 领导者密钥通过原子性CAS操作进行更改
  • 对非合作节点或故障节点进行自动隔离

避免脑裂

  • 只有一名成员能够赢得领导者选举
  • 当无法更新领导者密钥时降级
  • Patroni可以与看门狗进行通信

DCS对Patroni的支持

  • 强一致性的分布式配置存储
  • 通过TTL和监控机制提供leader lock自动过期功能
  • 支持Etcd、Consul、Zookeeper和Kubernetes等部署DCS集群

DCS工作机制

最先获得leader lock的节点会被选举为Primary节点

在leader lock持续期间,其他节点会持续检测/leader,如果检测到leader lock释放,会立即尝试获取leader lock,成为新的Primary

为什么要是DCS集群数目基数节点? 假设三个节点,如果有两个节点同意我们的主要节点不可用,则这两个节点具有多数票。如果是四个节点,就必须获取到三个节点的票,才能获得多数票,如果是两票对两票则是平手,还需要再进行投票。所以基数在投票环节上具备天然的优势。

当主库发生故障后,由于某些原因导致leader lock未释放

则会遵循设置等到leader lock超过ttl时间后自动过期,然后其他存活节点尝试获取leader lock

在上图中,数据库是一主两从的流复制架构,节点A是主节点,B和C是从节点。节点A会定期向etcd发送请求以更新领导者密钥,默认情况是10s更新一次(这是由参数loop_wait控制),更新的时候带了一个TTL。这里面有一个公式:

TTL > = loop_wait + retry_timeout * 2

patroni进程每隔10秒(loop_wait)都会更新Leader key还有TTL,如果Leader节点异常导致patroni进程无法及时更新Leader key,则会重新进行2次尝试(retry_timeout)。如果尝试了仍然无效。这个时候时间超过了TTL(生存时间)。领导者密钥就会过期,然后触发新的选举。

存活的备库获取leader lock的机会并不一定是均等的

不均等:

  1. 备库recover进度不一样(wal_position数值大机会大)
  2. 无法正常访问到etcd
  3. 状态正常且recover进度最新的节点获得leader lock

均等:

  1. 备库recover进度一致(wal_position数值相等)
  2. 均可以正常访问到etcd
  3. 最先获得leader lock成为主节点

Patroni之间也通过REST API互相访问。他们首先会和曾经的领导者通信,会发现访问超时,然后他们通过REST API访问数据库知道自己的wal_position位置。假设节点b和节点c现在都处于相同的wal_position,都等于100,那么他们会同时访问etcd,发送创建密钥的请求,然后开始领导争夺战。

0条评论
0 / 1000
l****n
3文章数
0粉丝数
l****n
3 文章 | 0 粉丝
l****n
3文章数
0粉丝数
l****n
3 文章 | 0 粉丝
原创

Patroni简单介绍

2023-09-26 06:59:15
195
0

引言

高可用概念

高可用(High Availability)是系统所能提供无故障服务的一种能力。简单地说就是避免因服务器宕机而造成的服务不可用。

如果一台系统能够不间断的提供服务,那么这台系统的可用性是100%。如果系统运行100个时间单位内有1个时间单位无法提供服务,那么该台系统的可用性是99%。

在实现系统高可用的架构设计中,核心准则是:冗余。

通过冗余机制,可以保障集群所部署的服务在全天候24小时内不间断运行,即使其中某台机器宕机,可以通过集群中的其他机器接替提供服务。因此,冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。

故障场景

假设有两个数据库,一个primary,一个standby,主库通过流复制将日志传给备库,备库监控主库是否健康:

当发生连接故障时当发生连接故障时,备节点升主,此时主库对外访问正常,引起脑裂:

使用第三服务器witness,同时监控主库和备库,witness实时进行心跳确认,一旦主库出现问题,witness就能清楚的知道情况,然后做故障转移:

但当witness出现故障,无法发生切换:

另外一个情况就是主库和witness出现了网络问题,无法访问主库的情况下,witness也会提升备库,但是主库其实对外访问是正常的:

Patroni的介绍

Patroni是一个PostgreSQL高可用的分布式配置模板,实际使用中相当于一个守护程序,由Zalando研发,python开发的开源项目,能够通过分布式存储系统(Distributed configuration system, DCS)来检测存储数据库集群各个节点的状态和配置,并 且能够对数据库集群进行自动管理和故障切换。

一个高可用集群由patroni、DCS和数据库组成,DCS可以选用ZooKeeper、etcd、Consul或Kubernetes其中一个。

自动故障恢复

  • 集群中健康成员间的领导者选举竞争
  • 每个成员自主做出决策
  • 集群状态存储在一致性的分布式存储中
  • 领导者密钥通过原子性CAS操作进行更改
  • 对非合作节点或故障节点进行自动隔离

避免脑裂

  • 只有一名成员能够赢得领导者选举
  • 当无法更新领导者密钥时降级
  • Patroni可以与看门狗进行通信

DCS对Patroni的支持

  • 强一致性的分布式配置存储
  • 通过TTL和监控机制提供leader lock自动过期功能
  • 支持Etcd、Consul、Zookeeper和Kubernetes等部署DCS集群

DCS工作机制

最先获得leader lock的节点会被选举为Primary节点

在leader lock持续期间,其他节点会持续检测/leader,如果检测到leader lock释放,会立即尝试获取leader lock,成为新的Primary

为什么要是DCS集群数目基数节点? 假设三个节点,如果有两个节点同意我们的主要节点不可用,则这两个节点具有多数票。如果是四个节点,就必须获取到三个节点的票,才能获得多数票,如果是两票对两票则是平手,还需要再进行投票。所以基数在投票环节上具备天然的优势。

当主库发生故障后,由于某些原因导致leader lock未释放

则会遵循设置等到leader lock超过ttl时间后自动过期,然后其他存活节点尝试获取leader lock

在上图中,数据库是一主两从的流复制架构,节点A是主节点,B和C是从节点。节点A会定期向etcd发送请求以更新领导者密钥,默认情况是10s更新一次(这是由参数loop_wait控制),更新的时候带了一个TTL。这里面有一个公式:

TTL > = loop_wait + retry_timeout * 2

patroni进程每隔10秒(loop_wait)都会更新Leader key还有TTL,如果Leader节点异常导致patroni进程无法及时更新Leader key,则会重新进行2次尝试(retry_timeout)。如果尝试了仍然无效。这个时候时间超过了TTL(生存时间)。领导者密钥就会过期,然后触发新的选举。

存活的备库获取leader lock的机会并不一定是均等的

不均等:

  1. 备库recover进度不一样(wal_position数值大机会大)
  2. 无法正常访问到etcd
  3. 状态正常且recover进度最新的节点获得leader lock

均等:

  1. 备库recover进度一致(wal_position数值相等)
  2. 均可以正常访问到etcd
  3. 最先获得leader lock成为主节点

Patroni之间也通过REST API互相访问。他们首先会和曾经的领导者通信,会发现访问超时,然后他们通过REST API访问数据库知道自己的wal_position位置。假设节点b和节点c现在都处于相同的wal_position,都等于100,那么他们会同时访问etcd,发送创建密钥的请求,然后开始领导争夺战。

文章来自个人专栏
PostgreSQL数据库
3 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
1
1