执行Patroni集群的备用数据中心升级

与标准的多节点Postgres复制集群不同，当由Patroni管理时，所有故障转移都是自动执行的。然而，在处理跨数据中心故障转移时，情况就不同了，例如当备用数据中心必须接管故障的主数据中心时。以下描述了在这种情况下执行此类过程所需的机制。

本文描述了两种机制，这两种机制都管理集群的DCS：

通过patronictl执行故障转移
通过Patroni的REST API执行故障转移

关于patronictl

这是允许对DCs进行更改的基础命令。

1

patronictl -c /etc/patroni/config.yml edit-config --help

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Usage: patronictl edit-config [OPTIONS] [CLUSTER_NAME]

编辑集群配置

选项：
  --group INTEGER  Citus组
  -q, --quiet      不显示更改
  -s, --set TEXT   设置特定的配置值。可以多次指定
  -p, --pg TEXT    设置特定的PostgreSQL参数值。是-s postgresql.parameters的简写。可以多次指定
  --apply TEXT     从文件应用配置。使用-表示stdin。
  --replace TEXT   从文件应用配置，替换现有配置。使用-表示stdin。
  --force          在任何时候都不要求确认
  --help           显示此消息并退出。

关于REST API

Patroni的REST API对于Patroni的领导者选举过程至关重要，用于故障转移、切换、重新初始化、重启和重新加载等操作。它也可以被像HAProxy这样的负载均衡器用于HTTP健康检查以及监控。通常在使用REST API执行操作时使用CLI curl和jq。

设置

为了文档目的，假设以下情况：两个数据中心，每个数据中心包含一个3节点复制集群。法兰克福当前配置为PRIMARY，阿姆斯特丹分别配置为STANDBY数据中心。

1
2
3
4
5
6
7


+ Cluster: Frankfurt (7546601820334116441) ------+----+-----------+
| Member  | Host           | Role    | State     | TL | Lag in MB |
+---------+----------------+---------+-----------+----+-----------+
| fradb1v | 10.108.134.168 | Leader  | running   |  2 |           |
| fradb2v | 10.108.134.113 | Replica | streaming |  2 |         0 |
| fradb3v | 10.108.134.150 | Replica | streaming |  2 |         0 |
+---------+----------------+---------+-----------+----+-----------+

1
2
3
4
5
6
7


+ Cluster: Amsterdam (7546601820334116441) -+-----------+----+-----------+
| Member  | Host           | Role           | State     | TL | Lag in MB |
+---------+----------------+----------------+-----------+----+-----------+
| amsdb1v | 10.108.134.211 | Standby Leader | streaming |  2 |           |
| amsdb2v | 10.108.134.235 | Replica        | streaming |  2 |         0 |
| amsdb3v | 10.108.134.29  | Replica        | streaming |  2 |         0 |
+---------+----------------+----------------+-----------+----+-----------+

备用领导者升级

升级备用领导者需要两个步骤：

升级当前备用领导者
删除远程连接的主节点使用的槽

版本1：使用patronictl

升级备用领导者

这两种变体之间的唯一区别是一个是交互式的，另一个不是。

变体A

1
2


# 交互式；在提交前询问
patronictl -c /etc/patroni/config.yml edit-config --set standby_cluster=null

变体B

1
2


# 强制执行
patronictl -c /etc/patroni/config.yml edit-config --set standby_cluster=null --force

创建新槽

这可以被视为一项可选活动，其中明确创建了一个复制槽，并理解将要配置一个新的备用数据中心，即故障的主数据中心。

1
2


patronictl -c /etc/patroni/config.yml edit-config 
           --set slots.standby_cluster.type=physical --force

注意：此命令和前面的命令可以合并为一个命令。仅出于文档目的，它们被分成两个独立的命令。

版本2：使用REST API

这种方法的好处是，它可以从任何可以访问集群中由Patroni管理的端口8008的主机执行。

升级备用领导者

主机被升级，恢复完成并变为读写模式。

1

curl -s -XPATCH -d '{"standby_cluster":null}' http://localhost:8008/config | jq .

创建新槽

根据先前演示的示例，在新的Leader上创建了一个新槽，用于复制到备用Leader。

1
2
3
4


curl -s -XPATCH -d 
'{
  "slots":{"standby_cluster":{"type": "physical"}}
}' http://localhost:8008/config | jq .

将已弃用的主数据中心重新配置为新的备用数据中心

以下说明与先前的说明有些相似。在Patroni集群"Frankfurt"中执行以下操作。

版本1：patronictl

配置新的备用领导者

1
2
3
4
5
6


patronictl -c /etc/patroni/config.yml edit-config 
    --set standby_cluster.host='amsdb1v,amsdb2v,amsdb3v' 
    --set standby_cluster.port=5432 
    --set standby_cluster.primary_slot_name=standby_cluster 
    --set standby_cluster.create_replica_methods=basebackup 
    --force

删除旧槽

除非有紧急原因需要该槽保留在新升级的Leader上，否则应将其删除。

1

patronictl -c /etc/patroni/config.yml edit-config --set slots=null --force

注意：尝试使用名为pg_drop_replication_slot的postgres函数删除槽将失败，因为patroni会简单地将其放回。

版本2：REST API