PG集群的高可用性涉及流复制、自动故障转移、备份与恢复、监控和警报等诸多方面。本文从网络中收集常用的高可用架构的知识，进行一个的学习归纳，包括：Patroni、Repmgr、Pgpool-II、基于共享存储的方案。
Patroni
Patroni是一个开源的pg集群管理工具，它提供了自动化的高可用性和故障切换解决方案。它基于zooKeeper、etcd或consul等分布式协调服务，通过监控主库的状态并自动执行故障切换操作，确保pg集群的高可用性和连续性。可通过pg + etcd + patroni + haproxy + keepalived来实现pg的高可用集群。
-
etcd本质上是一个k-v数据库。在该架构中，主要用于保存集群配置信息、成员信息等内容。
-
haproxy主要用于负载均衡，但使用时会出现单点问题或者服务多个ip的问题。
Haproxy一般会与keepalived的主从相结合共同使用，即haproxy+keepalived（主从）。keepalived虽然采用了主从结构，但是对外表现为一个虚拟IP，主服务器会发送特定的消息给从服务器，当从服务器收不到这个消息的时候，即主服务器宕机的时候，从服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。
整个高可用集群的结构如下图所示：
用户的请求首先会经过keepalived和haproxy这一层，经过负载均衡后进行相应的转发。每一个patroni监控和控制对应的pg，把该pg的信息状态写入etcd 。另外，patroni能够通过读取etcd获取其它pg的信息状态,会判断所对应的pg是否可以作为主库。如果可以，paroni试图选举自己的pg作为主库。
以该结构图为例说明其故障检测机制的原理，在这个图中，数据库是一主两从结构，库A是主库，B和C是从库。这个机制为，主库的patroni进程会定期，一般为10秒(loop_wait)，更新Leader key（领导者密钥）和TTL（生存时间），如果主库异常导致patroni进程无法及时更新，则会重新进行2次尝试（retry_timeout）。如果尝试了仍然无效，并且时间超过了TTL（生存时间）。Leader key就会过期，然后触发新的选举。
库B和库C的patroni首先会和曾经的主库通信，发现访问超时；随后，然后他们会获取自己的wal_position位置。假设库B和库C现在都处于相同的wal_position，那么他们会访问etcd，发送创建密钥的请求。如果Node C率先创建了密钥。Node C上面就执行promote，成为了新的主库，Node B将成为新的从库。
Repmgr
Repmgr是一个用于管理和监控基于流复制的pg集群的工具。其本质上是一个运行在pg库上的进程。它在每个pg库上都需要运行一个repmgrd进程来管理和监控库的状态、复制关系以及执行故障检测和切换等操作。
Repmgr 主要提供了 repmgr 和 repmgrd 两个工具。
-
repmgr：是一个执行管理任务的命令行工具，方便进行 pg服务器集群的管理。具有设置备用服务器、promote 备库、主从切换、显示复制集群中服务器的状态等功能。
-
repmgrd：是一个守护进程，它主动监控数据库状态并支持以下任务：监控和记录复制集群信息、故障检测、故障转移、集群中事件的通知（需要自定义脚本接受通知）。
在主库宕机时，备库在尝试多次连接主库失败后，repmgrd 会在所有备库中选举一个候选备库提升为新主库，其他备库去对接到该新主上，形成一个新的集群。
Repmgr 选举候选备库按照以下顺序选举：LSN > Priority > Node_ID
-
系统将优先选举一个 LSN 较大的库；
-
若 LSN 一样，会根据 Priority 优先级进行比较（该优先级是在配置文件中进行参数配置，如果 Priority 为 0，则代表该库被禁止提升为主库）；
-
若优先级也一样，会比较库的 Node ID，小者会优先选举。
Pgpool-Ⅱ
Pgpool-II是一个位于客户端和pg数据库之间的中间件，可以提供管理和优化数据库连接，提供高可用性、扩展性和负载均衡等功能。
可以看出其实就是在客户端和pg集群中间又加了一层，来对请求进行进一步处理。另外，pgpool也是一个主从架构。其相关功能原理如下：
-
连接池：Pgpool-II维护一个连接池，用于管理和复用与数据库的连接。当应用程序请求连接时，Pgpool-II可以从连接池中获取一个现有的连接，而不是为每个请求创建新的连接。这可以减少连接的创建和销毁开销，提高性能和资源利用率。
-
负载均衡：Pgpool-II分发客户端请求到多个后端数据库，以实现负载均衡。它可以根据不同的负载均衡策略将请求分发到不同的库，以平衡数据库服务器的负载。这样可以提高整体的查询吞吐量和响应性能。
-
高可用性：Pgpool-II提供了高可用性功能，以确保数据库集群的连续可用性。它可以监测数据库的状态，并在主库故障时自动切换到备份库。这种故障切换可以通过心跳检测和自动故障检测机制来实现。另外，对于自身而言，也通过watchdog机制进行故障的自动检测与切换。
-
并行查询：Pgpool-II支持并行查询，允许将一个查询分发到多个数据库并行执行。这可以提高查询性能和响应时间，特别是对于处理大量并发查询的场景。
-
语句重写和查询缓存：Pgpool-II具有语句重写和查询缓存功能，它可以通过缓存查询结果来减少对数据库的访问。当相同的查询被多次执行时，Pgpool-II可以根据缓存的结果直接返回，而不需要再次执行查询。
基于共享存储
SAN存储
SAN（Storage Area Network），是专为存储系统而设计的可以实现高速可靠访问的专用网络。
从该架构图看，两台数据库服务器共享一块或多块从存储上划出的磁盘；数据库的数据文件就存在此文件系统上。在主/备库上都可以看到此共享磁盘，主库上此磁盘上的文件系统是挂起来的，备库上此文件系统没有挂起。当主库发生故障时，备库的文件系统被挂起，然后再在备库上启动数据库即完成了切换。另外，在高可用切换时，为避免两台机器同时挂起，从而都会对文件系统进行写操作，导致文件系统的损坏，可以采用主机重启的方式。
实际上进行高可用切换时，并不像上面所说的这么简单。当主库发生故障时，可能只是主库与外部的网络断开了，它与存储设备的连接还是好的，同时文件系统还挂着，如果此时把文件系统在另一台机器上挂起来，像Ext3、Ext4、xfs等文件是不能同时在两台机器上挂起来的，同时挂起时，两台机器都会对文件系统进行写操作，这就会导致文件系统的损坏。为避免此问题，最常用的方式就是让主库重启。
DRBD存储
DRBD(Distributed Replicated Block Device)，即分布式复制块设备，是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。简单说DRBD是实现主库储数据变更后自动复制到备用库相应存储位置的软件，是一种数据块级别的物理复制。
根据架构图可以看到DRBD需要运行在各个库上，主库与备库的数据可以保证同步。当主库出现故障时,备库上还会保留有一份相同的数据,可以继续使用。即，当主库接收到数据后，DRBD会检查数据，当发现接收到的数据是发往到自己管理的存储位置，就复制另一份，一份存储到本机的DRBD存储设备，另一份就发给另外一台库进行存储。
如果主库宕机，备库可以在集群中成为新主库，把接收到的数据先存储到本地，对外提供服务。当原主库恢复上线时，再新主库把其原主库宕机后变动的数据镜像到原主库。镜像过程完成后还需要返回成功/失败的回应消息，这个回应消息可以在传输过程中的不同位置返回，如图上的A/B/C标识位置，可以分为三种复制模式：
-
A：Async，异步：本地写成功后立即返回，数据放在发送buffer中，可能丢失，但传输性能好。
-
B：Semi sync，半同步：对方接收到数据后，但还没有落盘前返回。
-
C：Sync，同步：本地和对方写成功落盘确认后返回，数据可靠性高，生产系统一般都采用这种方式。
