postgresql/lightdb patroni高可用搭建与测试

  之前我们讲述了repmgr,这一篇我们来看patroni的高可用实现(不管是哪种高可用方案,底层都是基于流复制,这才是核心,上面只是尽可能自动化,异常时兜底能力仍然是最重要的,无之一)。对于patroni,cybertec的评价如下:

What does Patroni do?

Basically, everything you need to run highly available PostgreSQL clusters!
Patroni creates the cluster, initiates streaming replication, handles synchronicity requirements, monitors liveliness of primary and replica, can change the configuration of all cluster members, issues reload commands and restarts selected cluster members, handles planned switchovers and unplanned failovers, rewinds a failed primary to bring it back in line and reinitiates all replication connections to point to the newly promoted primary.

Patroni is engineered to be very fault tolerant and stable; By design, split-brain scenarios are avoided. Split-brain occurs when two members of the same cluster accept writing statements.
It guarantees that certain conditions are always fulfilled and despite the automation of so many complex tasks, it shouldn’t corrupt the database cluster nor end in a situation where recovery is impossible.
For example, Patroni can be told never to promote a replica that is lagging behind the primary by more than a configurable amount of log.

It also fulfils several additional requirements; for example, certain replicas should never be considered for promotion if they exist only for the purpose of archiving or data lake applications and not business operations.

The architecture of Patroni is such that every PostgreSQL instance is accompanied by a designated Patroni instance that monitors and controls it.

All of the data that Patroni collects is mirrored in a distributed key-value store, and based on the information present in the store, all Patroni instances agree on decisions, such as which replica to promote if the primary has failed.
The distributed key-value store, for example etcd or consul, enables atomic manipulation of keys and values. This forwards the difficult problem of cluster consensus (which is critical to avoid the split-brain scenario) to battle tested components, proven to work correctly even under the worst circumstances.

Some of the data collected by Patroni is also exhibited through a ReST interface, which can be useful for monitoring purposes as well as for applications to select which PostgreSQL instance to connect to.

  简单地说,patroni把pg高可用所需的一切都准备好了。相比repmgr而言,它更加强大、也更加复杂,比如要依赖etcd(事实上的标配推荐,在Golang 社区中, etcd 则是唯一一个可以媲美ZooKeeper 的组件, 在有些方面, etcd 甚至超越了ZooKeeper,比如性能。)或其它分布式选举方案作为DCS。

  对于repmgr和patroni的对比,可以部分参考https://cloud.tencent.com/developer/article/1882210?from=15425https://cloud.tencent.com/developer/article/1882209,还是比较客观,它是一个系列,并没有明显说patroni更好,只能说是更加接近云原生派系。简单总结如下:

   这里就不重复阐述。

原理和部署架构

  对于patroni高可用架构来说,etcd三个副本,这个通常无歧义(因为需要三个节点,所以一般来说大规模集群比较划算,etcd(etcd半官方GUI,支持所有etcd特性,https://etcdmanager.io/,也可以考虑etcdv3-browser)集群共享,单集群用patroni是不划算的)。但是postgresql本身应该采用三个副本还是2个副本,其实观点是不同的。vmware推荐的是3个节点,1主2从,cybertec则是统一采用1主1从。如下:

 

 vmware推荐架构

 

 

 

 cybertec标准双中心架构(因为很多时候无法准备三中心)

  所以两副本还是三副本技术上都可以,patroni本身对此无限制(技术上来看,1个单机etcd+2个patroni单服务器都可以实现伪集群架构https://www.cybertec-postgresql.com/en/patroni-setting-up-a-highly-available-postgresql-cluster/),要求通常更多的取决于业务。比如主机房主备,灾备机房再加一个副本,但是灾备机房副本永不自动拉起(很像mysql的orchestrator)。

  从工作原理上来看,patroni需要的元数据存储在etcd中,如果etcd全挂了,patroni会停止整个pg集群,所以etcd会影响运行时,本质上就是个单点。patroni依赖etcd或其他dcs的原因是需要有个地方集中式的存储状态定时检查以确定节点是否活着。具体流程如下:

  • Each Patroni instance monitors the health data of a PostgreSQL instance.
  • The health data needs to be stored somewhere where all other Patroni instances can access it.
  • Based on this data, each Patroni instance decides what actions have to be taken to keep the cluster as a whole healthy.
  • A Patroni instance may decide that it needs to promote its PostgreSQL instance to become a primary, because it registered that there is currently no primary.
  • That Patroni instance needs to be sure that while it attempts to promote the database, no other Patroni instances can try to do the same. This process is called the “leader-race”, where the proverbial finish line consists of acquiring the “leader” lock. Once a Patroni instance has acquired this lock, the others cannot acquire it unless the new leader gives it up, or fails to extend its time to live.

https://www.cybertec-postgresql.com/en/patroni-setting-up-a-highly-available-postgresql-cluster/  quickstart部署示例,演示目的

https://www.cybertec-postgresql.com/en/introduction-and-how-to-etcd-clusters-for-patroni/ 标准化的部署架构入门,离GA还远着

https://developer.aliyun.com/article/775030 基于Patroni的Citus高可用环境部署

https://www.bilibili.com/video/BV1pZ4y1N77s/?vd_source=7deb4834c073e6c8ac7542a68f05760b  基于Patroni的Citus高可用环境部署

https://zhangeamon.top/postgres/patroni02/

https://blog.csdn.net/weixin_46199817/article/details/119821946

https://www.modb.pro/issue/14280

https://www.percona.com/blog/creating-a-standby-cluster-with-the-percona-distribution-for-postgresql-operator/

 

posted @ 2022-10-20 22:20  zhjh256  阅读(155)  评论(0编辑  收藏  举报