PGSQL Standby Cluster 同步集群

同步集群 —— 整个集群作为另一个集群的物理备份集群，可用于灾备Switchover

备份集群

您可以使用 Standby Cluster 的方式，制作现有集群的克隆，使用这种方式，您可以从现有数据库平滑迁移至Pigsty集群中。

创建 Standby Cluster 的方式无比简单，您只需要确保备份集群的主库上配置有合适的 pg_upstream 参数，即可自动从原始上游拉取备份。

  1.     # pg-test是原始数据库
  2.     pg-test:
  3.       hosts:
  4.         10.10.10.11: { pg_seq: 1, pg_role: primary }
  5.       vars:
  6.         pg_cluster: pg-test
  7.         pg_version: 14
  8.         pg_users: [ { name: test , password: test , pgbouncer: true , roles: [ dbrole_admin ] } ]
  9.         pg_databases: [ { name: test } ]
  11.     # pg-test2将作为pg-test1的Standby Cluster
  12.     pg-test2:
  13.       hosts:
  14.         10.10.10.12: { pg_seq: 1, pg_role: primary , pg_upstream: 10.10.10.11 } # 实际角色为 Standby Leader
  15.         10.10.10.13: { pg_seq: 2, pg_role: replica }
  16.       vars:
  17.         pg_cluster: pg-test2
  18.         pg_version: 14          # 制作Standby Cluster时，数据库大版本必须保持一致！
  1. bin/createpg pg-test     # 创建原始集群
  2. bin/createpg pg-test2    # 创建备份集群

提升备份集群

当您想要将整个备份集群提升为一个独立运作的集群时，编辑新集群的Patroni配置文件，移除所有standby_cluster配置，备份集群中的Standby Leader会被提升为独立的主库。

  1. pg edit-config pg-test2  # 移除 standby_cluster 配置定义并应用

移除下列配置：整个standby_cluster定义部分。

  1. -standby_cluster:
  2. -  create_replica_methods:
  3. -  - basebackup
  4. -  host: 10.10.10.11
  5. -  port: 5432

修改备份集群上游复制源

当源集群发生Failover主库发生变化时，您需要调整备份集群的复制源。执行pg edit-config <cluster>，并修改standby_cluster中的源地址为新主库，应用即可生效。这里需要注意，从源集群的从库进行复制是可行的，源集群发生Failover并不会影响备份集群的复制。但新集群在只读从库上无法创建复制槽，可能出现相关报错，并存在潜在的复制中断风险，建议及时调整备份集群的上游复制源。

  1.  standby_cluster:
  2.    create_replica_methods:
  3.    - basebackup
  4. -  host: 10.10.10.13
  5. +  host: 10.10.10.12
  6.    port: 5432

修改 standby_cluster.host 中复制上游的IP地址，应用即可生效（无需重启，Reload即可）。

级连复制

题外话，如果您在集群内指定不同于主库的另一个从库IP作为pg_upstream，那么该从库将尝试从指定从库进行复制，而不是直接从主库进行复制。

在创建集群时，如果为集群中的某个从库指定 pg_upstream 参数（指定为集群中另一个从库），那么该实例将尝试从该指定从库构建逻辑复制。

在这种情况下，配置该参数的实例将成为一个 级联从库 ， 而其复制源实例 则被称为 桥接实例。

  1. pg-test:
  2.   hosts:
  3.     10.10.10.11: { pg_seq: 1, pg_role: primary }
  4.     10.10.10.12: { pg_seq: 2, pg_role: replica }  # 桥接从库，从主库接收WAL变更并转发至3号实例
  5.     10.10.10.13: { pg_seq: 2, pg_role: replica, pg_upstream: 10.10.10.12 } # 尝试从2号从库而非主库复制，级联从库。
  6.   vars:
  7.     pg_cluster: pg-test

通常情况下不建议使用级联从库，级联从库通常用于从库非常多的情况，例如1主30从的情况下，主库要同时发送30份WAL。 另一种更好的办法是，您可以在主库上挂1～3个直接的从库，然后挑选1～2个作为桥接从库，把其他20多个从库挂在桥接库上，让桥接库承担分发WAL的网络流量与负载。

延迟集群

如果您为备份集群配置一个显式的复制延迟，就可以制作 延迟集群。

高可用与主从复制可以解决机器硬件故障带来的问题，但无法解决软件Bug与人为操作导致的故障，例如：误删库删表。误删数据通常需要用到冷备份，但另一种更优雅高效快速的方式是事先准备一个延迟从库。

最后修改 2022-06-05: add pgsql/deploy document (34a3325)