1. PostgreSql高可用介绍

高可用解决方案的探讨本质上探讨的是低宕机时间解决方案，可以理解为高可用的反面是不可用，绝大部分情况下数据库宕机才会导致数据库的不可用。那么在那些情况下会导致PostgreSql数据库宕机, 不可用.

引起宕机的因素中，运行环境时排名第一的故障，运行环境主要指操作系统、网络以及硬盘等引起的问题引起PostgreSql数据库宕机，最普遍的问题比如存储PostgreSql数据目录的磁盘空间耗尽导致数据库宕机；性能问题紧随其后，大概也占到35%左右，常见的是运行很糟糕的SQL语句引起宕机，以及糟糕的Schema和索引设计等都可能引起宕机；然后是复制，通常是由于主备数据不一致导致。最后剩下的大概10%包括各种类型的数据丢失或损坏以及其他问题等，比如Drop Table的误操作导致数据丢失问题。

2. 基于存储的高可用

3. 流复制架构

PostgreSql流复制模式分为同步流复制和异步流复制。

同步流复制：要求主库上提交的事务会等待至少一个备库接受WAL日志流并返回确认后主库才向客户端返回成功，因此同步流复制模式下，主库、备库的数据理论上是一致的。这种模式高可用方案只需要提供一个VIP做高可用IP,通常该VIP绑定在主库主机上，当主库出现异常时，讲VIP漂移到备库主机上即可，同步流复制写性能损耗较大。生产环境很少使用。

异步流复制：主库上提交的事务不会等待备库接受WAL日志流并返回确认信息后主库才向客户端返回成功，因此异步流复制模式下，主库、备库的数据存在一定的延迟、延迟的时间受各种因素影响，比如主库压力，主备库性能，网络带宽等影响，当主库不是很忙并且主备库主机压力不是很大时，主备数据延迟通常在毫秒级，因此异步流复制制定高可用方案时需要考虑的是主备库的延迟因素

以下介绍业界常用的高可用架构。

4.1. PostgreSql主从架构

介绍

PostgreSql流复制是其自带的功能，无需借助第三方工具，其核心原理是主库将预写日志WAL日志流发送到备库，备库接收到WAL日志流后，进行重做。PostgreSql 默认采用异步复制方式，从节点可以复制主数据库中的所有数据库。

工作原理

复制原理:

从上图我们可以看到流复制中日志提交的大致流程为：

1、事务commit后，日志在主库写入wal日志，还需要根据配置的日志同步级别，等待从库反馈的接收结果。

2、主库通过日志传输进程将日志块传给从库，从库接收进程收到日志开始回放，最终保证主从数据一致性。

流复制同步级别

PostgreSQL通过配置synchronous_commit (enum)参数来指定事务的同步级别。我们可以根据实际的业务需求，对不同的事务，设置不同的同步级别。

synchronous_commit = off                # synchronization level;  

                                        # off, local, remote_write, or on  

remote_apply：事务commit或rollback时，等待其redo在primary、以及同步standby(s)已持久化，并且其redo在同步standby(s)已apply。

on：事务commit或rollback时，等待其redo在primary、以及同步standby(s)已持久化。

remote_write：事务commit或rollback时，等待其redo在primary已持久化; 其redo在同步standby(s)已调用write接口(写到 OS, 但是还没有调用持久化接口如fsync)。

local：事务commit或rollback时，等待其redo在primary已持久化;

off：事务commit或rollback时，等待其redo在primary已写入wal buffer，不需要等待其持久化;

优缺点

1.架构简单:

配置简单,当一个节点损坏时，因有其他高可用节点，可以方便提供服务。

2.负载均衡,读写分离
避免所有客户端都访问一个节点，有了主从模式后，查询操作就可以通过查询从节点来完成。需要使用额外的组件或者设置JDBC的targetServerType

3.数据实时备份
不影响主库性能的情况下，进行实时备份。

4. 架构扩展
随着系统中业务访问量的增大，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。

5. 自动切换

在主库异常宕机的情况下，该架构模式无法自动切换，需要手动介入。

延伸架构

1）一主多从架构

PostgreSql数据库自身提供的主从复制里延伸实现多从的拓展。通过实现读写分离还能进一步提升数据库的负载性能。下图就描述一个多个数据库间主从复制与读写分离的模型。master数据库进行写操作，多个slave数据库进行读操作，

当从库增加过多的时候，主库和从库之间的传输WAL日志，过度频繁，占用大量的网络资源。 延迟现象明显。建议最多3个从库,一般情况下一主两从即可。

4.2. PG+PGPOOL高可用架构

介绍

pgpool-II 是一个位于 PostgreSQL 服务器和 PostgreSQL 数据库客户端之间的中间件

主要提供以下一些功能：连接池、复制、负载均衡、连接限制、看门狗、缓存

pgpool-II 使用 PostgreSQL 的前后台程序之间的协议，并且在前后台之间传递消息。 因此，一个（前端的）数据库应用程序认为 pgpool-II 就是实际的 PostgreSQL 数据库， 而后端的服务进程则认为 pgpool-II 是它的一个客户端。 因为 pgpool-II 对于服务器和客户端来说是透明的， 现有的数据库应用程序基本上可以不需要修改就可以使用 pgpool-II 了

工作原理

pgpool也和postgresql一样是多进程的，主要分为父进程，子进程,pcp进程。

父进程主要是health check和消息中转，

子进程负责与postgresql通讯，接收用户发送过来的SQL请求，然后根据规则发送到底层数据库上，

pcp进程负责与其它的pgpool进程通讯和用户名密码的检查，pcp之间的通讯全是用一个字母代表语义，

这个通讯协议还需要看看是不是采用的是postgresql中的通讯协议，在pcp目录下面，还保存了一些用户管理pgpool的工具

worker进程：负责检查底层数据库之间的复制延迟

优缺点

优点：

1：数据是同步的，数据强一致性

2：自动Failover

3：提供连接池功能

4：读可以负载均衡

5：可以在线恢复，不需要停止pgpool就可以在线修复或增加后端数据库节点

6：容易配置

缺点：

1：写性能不会很好，有写性能下降

2：不支持部分查询。一些随机函数、序列号，直接在不同的后端数据库上执行SQL将产生不同的结果集，在复制模式下，不能使用此类函数和序列号

3：节点之间需要互信，这对一些安全要求高的环境可能不太适用

4：连接数增加pgpool性能会下降

5：pg_terminate_backend()可能会导致自动切换

4.3. VIP+REPMGR高可用架构

介绍

repmgr是一个开源工具套件，用于管理PostgreSQL服务器集群中的复制和故障转移。它使用工具来增强PostgreSQL的内置热备份功能，以设置备用服务器，监控复制以及执行管理任务，例如故障转移或手动切换操作，但是repmgr不支持vip，需要设置虚拟vip对外提供服务。设置虚拟IP的方法包括网卡上直接设置或者使用keepalive功能

工作原理

集群节点部署完成后，每个节点都可通过 repmgrd 守护进程来监控节点数据库状态；每个节点元数据表可独立维护，这些元数据表将记录所有集群节点的信息

选举原理

在发生 Auto Failover 时，备节点在尝试多次连接主节点失败后（尝试次数及尝试间隔可以通过 repmgr.conf 配置文件修改），repmgrd 会在所有备节点中选举一个候选备节点（选举机制参考下文）提升为新主节点，其他备节点去 Follow 到该新主上，形成一个新的集群。

repmgr 选举候选备节点按照以下顺序选举：LSN > Priority > Node_ID

系统将优先选举一个 LSN 较大的节点，作为候选备节点；

若 LSN 一样，会根据 Priority 优先级进行比较（该优先级是在配置文件中进行参数配置，如果 Priority 为 0，则代表该节点被禁止提升为主节点）；

若优先级也一样，会比较节点的 Node ID，小者会优先选举。

Keepalived 负责产生虚拟 ip 和虚拟 ip 漂移,数据库发生主备切换或者节点故障后，访问地址对上层不变。

进程介绍

repmgr 是一个执行管理任务的命令行工具，方便进行 PostgreSQL 服务器集群的管理。具备以下功能特点：

1：设置备用服务器 2：promote 备主从切换 3：显示复制集群中服务器的状态

repmgrd 是一个守护进程，它主动监视复制集群中的服务器并支持以下任务：

1：监控和记录复制集群信息2：故障检测、故障转移3：集群中事件的通知（需要自定义脚本接受通知）

优缺点

优点：

1.故障切换快

   在主从复制集群中，只要从库在复制上没有延迟，repmgr通常可以在数秒内实现故障切换

2.master故障不会导致数据不一致

3.无需修改当前的数据库设置

4.分布式管理，易扩展，可在线动态增删集群节点

5.无性能下降,repmgr是一种轻量级的开源软件，配置安装简单

6：社区活跃度很高，目前还在更新中

缺点：

1：需开通SSH，权限账号，在某些安全性要求比较高的地方，可能无法使用

2：只提供故障切换能力

3：在和vip 搭配只使用过程中，可能会出现VIP漂移失败的情况，更多情况下建议使用JDBC轮询的方式判断主库

4：无负载均衡的能力。

5：无连接池

  6：目前有hg_repmgr增强版可以提供VIP，以及解决部分repmgr使用过程中的bug问题

4.4. PG_AUTO_FAILOVER高可用架构

介绍

pg_auto_failover解决方案旨在提供一种易于设置且可靠的自动化故障转移解决方案。该解决方案包括由软件驱动的决策，以决定何时在生产中实施故障转移,请注意只提供自动化故障转移方案

使用pgautofailover时，将部署多个活动代理来跟踪Postgres数据库：

主要角色：监控节点，主节点和备节点

监视器是一个本身具有pg_auto_failover扩展名的Postgres数据库，它注册并检查活动Postgres节点的运行状况。

在pg_auto_failover监视器中注册的每个Postgres节点也必须运行本地代理pg_autoctl运行服务。

每个受管理的Postgres服务在同一个组中有两个设置在一起的Postgres节点。一个监视器设置可以根据需要管理多个Postgres组。

通过这样的部署，监控器会定期连接到每个已注册的节点（默认为20秒），并在其pgautofailover.node表中注册成功或失败。

除此之外，每个Postgres节点上的pg_autoctl运行服务还会检查Postgres是否正在运行，并监视其他节点的pg_stat_replication统计信息。

此Postgres系统视图使我们的本地代理能够发现主节点和备用节点之间的网络连接。

本地代理定期每隔5s向监视器报告每个节点的状态，除非需要进行转换，然后立即进行。

pg_auto_failover监视器根据集群中两个节点的已知状态做出决策，并且仅遵循我们精心设计以确保节点收敛的有限状态机。

特别是，只有在pg_autoctl代理报告成功实现了确定的过渡到新状态后，FSM才取得进展。

关于故障转移逻辑的体系结构包含FSM的映像，我们使用这些映像来确保pgautofailover中的自动故障转移决策。

工作原理

Monitor也叫状态机是pg_auto_failover的核心机制。最简单的理解就是通晓各个节点当下的状态。首先各个节点的守护进程会发送事件给状态机，状态机根据发送过来的事件信息，为每个节点分配当前状态和目标状态。节点的当前状态是其功能的有力保证。而目标状态是告诉我们将要尝试的转换。

当使用多个standby时，通过设置上述三个参数，

number_sync_standbys该参数意味着当主库提交事务后，需要等待多少备用节点同步成功后才能完成提交。该参数是此架构的一个重要设置是number_sync_standbys=1，

因为 Monitor的编队中只有两个节点注册时，我们有一个主节点和一个从节点。那么 number_sync_standbys只能设置为零。

当向 pg_auto_failover 组添加第二个从节点 时，监视器会自动number_sync_standbys增加到 1，

如上图所示。该参数意味着主节点在提交事务后需要等待多少个备节点同步成功后才能完成提交。

这种架构将 始终保留两份同步数据，一个是当前主节点 A，另一个是首先确认交易的备库 (图中的任意一个节点 B或节点 C)。

为了具有良好的可用性，pg_auto_failover 需要 number_sync_standbys + 1个备节点参与流复制仲裁：这样允许任何一个备节点发生故障而不会影响系统复流制仲裁的能力。

因为还有一个备库，仍然可以保 证数据有2份。而如果两个备用库都不可用，就不能再保证进行复制仲裁了。主节点在此时被阻止写入，

主节点将等待至少一个备用节点恢复，确认本地提交的 事务才会变成可写状态

当standby节点被检测为不可用，或者当其lag延迟高于定义的阈值（promote_wal log _threshold）时,Monitor会在主节点上的synchronous_standby_names设置中移除该不可用节点;

在standby节点恢复正常监控之前，不允许进行failover和switchover 操作，从而防止数据丢失;当standby节点已恢复或WAL赶上到定义的阈值内时，同步热备将自动恢复。

优缺点

优点：

1.高可用架构灵活，支持单节点，多节点架构，提高资源利用率提升；

2.同步复制，没有复制延迟；

3.安装配置简单，在安装过程中同时也优化了postgresql.conf参数；

4.容错率，故障转移能力更强，通过灵活设置参数，提升数据库高可用性

增强了业务连续性；

5.原生postgresql架构模式，无代理，几乎无性能损失；

缺点：

1.只支持故障转移

2.至少3个节点

3.社区活跃度不是很高。

4.需要配合其他组件完成整体的高可用架构，比如JDBC轮询

6. 总结

以上4中方案复制技术是现在互联网行业常用的架构，也是最成熟的方案，对于方案的选择，因业务特性进行考虑。

建议现阶段选择 PostgreSql主从复制 和 VIP+REPMGR高可用架构。

其他：

当然PostgreSql的高可用架构模式不止是以上的几种，还有基于Patroni的高可用架构（适用于分布式数据库）,基于Pacemaker的架构，该架构组件比较多，比较复杂，对人工运维成本较高，多主架构基于BDR，但是该架构的bug比较多，使用者比较少

开源去o的第三步-数据库物理资源评估 https://www.modb.pro/db/246594

开源去o的第二步-数据库规划设计 https://www.modb.pro/db/242694

开源去o的第一步-关系数据库选型 https://www.modb.pro/db/239808