本文将简诉PostgreSQL容灾方案，新型两地三中心的方案

PostgreSQL容灾方案

容灾可以选择同步或是异步模式。同步模式下无丢失数据风险，会损失一点点性能。异步模式下，会少量丢失数据，不会损失性能。

通常的方案（同步/异步模式均可）：

1. 一主一备流复制

2. 一主多备流复制

3. 一主 x 备（quorum based）流复制

   # n1, n2, n3 表示application_name.
   
   synchronous_standby_names = 'ANY 1 (n1, n2, n3)' 
   # Wal 复制到 n1, n2, n3中的任意一个备节点便算成功
   
   synchronous_standby_names = 'ANY 2 (*)'    
   # Wal 复制到任意的2个备节点便算成功
   

4. PITR（ recovery_target 的各种方案）类方法

5. 逻辑备份还原

6. 逻辑复制

两地三中心概念

两地三中心 ： 是指 同城双中心 加 异地灾备 一种商用容灾备份解决方案；

两地 是指同城、异地；

三中心 是指生产中心、同城容灾中心、异地容灾中心。（生产中心、同城灾备中心、异地灾备中心）

三中心的缺点是需要三个同等规模的集群环境，而其中一个中心的数据几乎永远用不到，通过合理的设计可以减少将近30%的成本。

PostgreSQL新型两地三中心

PostgreSQL新型两地三中心，指在减少同城灾备中心的集群规模，缺点是会增加一点点的RTO，而RPO依然是保持零。

理论：

​ 同城的备机（延迟低）以同步模式接受WAL，保障数据不丢失便可以，而回放需要很大的集群资源，这个资源可以不用，只有WAL日志就可以。

​ 灾难发生时，异地中心（异步模式WAL不完整，同步模式也可以，异步性能更好）获取备机的WAL（WAL完整无丢失）来达到RPO为零的目标。这个过程会消耗一点RTO的时间（根据数据量通常是秒级）。数据恢复后，异地中心提供主服务。

​ 灾难发生后，可以自行定制方案，并尽快恢复至灾难发生前的集群角色和状态。

异地灾备中心，可以接管生产中心进行业务处理，这只是应急保障方案，而非生成中心，生产中心才是真正的业务核心。
网络延迟的解决，通过架设私网，延迟可以降低到很低的，或如5G技术的超低延迟。
PostgreSQL提供此种方案的选择，而构建系统的因素还需要很多其他考量，需要综合考虑起来分析并选择，数据库能力只是其中的一个因素。
每个方案都有各自的优缺点，企业也都有各自的参量标准，凡事没有绝对，再只考虑接管能力和可用性的情况下原两地三中心方案是最好的。
在主要考虑成本时还要实现两地三中心提供的核心服务能力时，新型两地三中心不是最佳的，结合PITR更好。

新型三中心的概念：
三中心 是指生产中心、同城数据安全中心、异地容灾中心。

异地中心，结合PITR机制，也可以减少集群资源，但是会增加一些RTO的时间。

实践：

​ 新型两地三中心的关键是同城灾备中心是如何只处理WAL的接收。我们可以使用 pg_receivewal 便可以实践这一功能。

synchronous_standby_names = 'pg_receivewal' 添加到生产中心的postgresql.conf

./pg_receivewal --create-slot -S rwal -p 8888 创建slot
./pg_receivewal -D kk -p 8888 -S rwal --synchronous 启动接收WAL

oracle很早的时候便有了此种方案，全球使用量就不知道了。又或是用于其他解决方案的处理。

如果你有其他方案或是建议，可私信我进行补充修订。
pg_receivewal还能构建很多其他解决方案，根据各自业务和环境特点进行组合使用非常强大。