确保高可用性 Patroni 设置的可靠性和质量对于保持持续的数据库操作并最大限度地缩短停机时间至关重要。本页面提供了有关测试 Patroni 集群的详尽指南,涵盖各种故障场景、复制一致性和故障切换机制。
测试 Patroni 设置
连接到您的任何 Patroni 实例(
alloydb-patroni1
、alloydb-patroni2
或alloydb-patroni3
),然后前往 AlloyDB Omni Patroni 文件夹。cd /alloydb/
检查 Patroni 日志。
docker compose logs alloydbomni-patroni
最后的条目应反映 Patroni 节点的相关信息。您应该会看到如下所示的内容。
alloydbomni-patroni | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock
连接到与主 Patroni 实例
alloydb-patroni1
建立网络连接的任何运行 Linux 的实例,并获取有关该实例的信息。您可能需要通过运行sudo apt-get install jq -y
来安装jq
工具。curl -s http://alloydb-patroni1:8008/patroni | jq .
您应该会看到如下所示的内容。
{ "state": "running", "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00", "role": "master", "server_version": 150005, "xlog": { "location": 83886408 }, "timeline": 1, "replication": [ { "usename": "alloydbreplica", "application_name": "patroni2", "client_addr": "10.172.0.40", "state": "streaming", "sync_state": "async", "sync_priority": 0 }, { "usename": "alloydbreplica", "application_name": "patroni3", "client_addr": "10.172.0.41", "state": "streaming", "sync_state": "async", "sync_priority": 0 } ], "dcs_last_seen": 1715870011, "database_system_identifier": "7369600155531440151", "patroni": { "version": "3.3.0", "scope": "my-patroni-cluster", "name": "patroni1" } }
在 Patroni 节点上调用 Patroni HTTP API 端点会公开有关由 Patroni 管理的特定 PostgreSQL 实例的状态和配置的各种详细信息,包括集群状态信息、时间轴、WAL 信息,以及指示节点和集群是否已启动并正常运行的健康检查。
测试 HAProxy 设置
在装有浏览器并与 HAProxy 节点建立网络连接的机器上,访问以下地址:
http://haproxy:7000
。或者,您也可以使用 HAProxy 实例的外部 IP 地址,而不是其主机名。您应该会看到类似以下屏幕截图的内容。
图 1. 显示 Patroni 节点健康状况和延迟时间的 HAProxy 状态页面
在 HAProxy 信息中心内,您可以查看主 Patroni 节点
patroni1
以及两个副本patroni2
和patroni3
的健康状况和延迟时间。您可以执行查询来检查集群中的复制统计信息。从 pgAdmin 等客户端,通过 HAProxy 连接到主数据库服务器,然后运行以下查询。
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;
您应该会看到类似下图的内容,展示
patroni2
和patroni3
正在从patroni1
进行流式传输。图 2. 展示 Patroni 节点复制状态的 pg_stat_replication 输出。
测试自动故障切换
在本部分中,我们将在包含三个节点的集群中,通过停止已附加的正在运行的 Patroni 容器来模拟主节点上的服务中断。您可以停止主节点上的 Patroni 服务来模拟服务中断,也可以强制执行一些防火墙规则来停止与该节点的通信。
在主 Patroni 实例上,前往 AlloyDB Omni Patroni 文件夹。
cd /alloydb/
停止容器。
docker compose down
您应该会看到类似以下输出的内容。该内容应能验证容器和网络已关停。
[+] Running 2/2 ✔ Container alloydb-patroni Removed ✔ Network alloydbomni-patroni_default Removed
刷新 HAProxy 信息中心,查看故障切换是如何发生的。
图 3.展示从主节点到备用节点的故障切换的 HAProxy 信息中心。
patroni3
实例成为新的主实例,而patroni2
是唯一剩余的副本实例。之前的主实例patroni1
会关停,无法通过健康检查。Patroni 通过将监控、共识和自动化编排相结合来执行和管理故障切换。一旦主节点未能在指定的超时时间内租约,或者报告故障,集群中的其他节点就会通过共识系统来识别此情况。其余节点会协调选择最合适的副本节点,以将其提升为新的主节点。选择候选副本节点后,Patroni 会通过应用必要的更改(例如更新 PostgreSQL 配置和重放所有未处理的 WAL 记录)将此节点提升为主节点。然后,新的主节点会使用其状态更新共识系统,其他副本节点会重新配置自身以遵循新的主节点,包括切换其复制来源,并可能与任何新事务保持同步。HAProxy 会检测新的主节点并相应地重定向客户端连接,以确保最大限度地减少中断。
从 pgAdmin 等客户端,通过 HAProxy 连接到您的数据库服务器,并在故障切换后检查集群中的复制统计信息。
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;
您应该会看到类似下图的内容,展示现在只有
patroni2
正在进行流式传输。图 4. 展示故障切换后 Patroni 节点的复制状态的 pg_stat_replication 输出。
包含三个节点的集群可以另外承受一次服务中断。如果您停止当前的主节点
patroni3
,系统会再进行一次故障切换。图 5. 展示从主节点
patroni3
到备用节点patroni2
的故障切换的 HAProxy 信息中心。
回退注意事项
回退是指进行故障切换后恢复之前的源节点的过程。在高可用性数据库集群中,通常不建议采用自动回退,因为可能会导致一些严重问题,例如恢复不完整、有风险发生脑裂情况以及复制延迟。
在 Patroni 集群中,如果您启动用于模拟服务中断的两个节点,它们会以备用副本的形式重新加入集群。
Figure 6. 展示 patroni1
和 patroni3
恢复为备用节点的 HAProxy 信息中心。
现在,patroni1
和 patroni3
正在从当前主节点 patroni2
复制数据。
图 7. 展示回退后 Patroni 节点的复制状态的 pg_stat_replication 输出。
如果您想手动回退到初始主节点,可以使用 patronictl 命令行界面执行此操作。选择手动回退可确保恢复流程更加可靠、一致且经过全面验证,从而保障数据库系统的完整性和可用性。