通过复制恢复和备份设置将 PostgreSQL + Patroni 生产集群迁移和强化到 Ubuntu

初始情况
目前在 SaaS 生产中使用 PostgreSQL 14（多租户，峰值高达 1200 rps，约 900 GB 数据）。 Hetzner Cloud 中 Ubuntu 20.04 上的集群 3 个节点（2 个主/备用 + 见证），由 Patroni+etcd 管理。在发生一系列事件后，我们注意到：脑裂的周期性故障转移、副本滞后长达 20-40 分钟、酒保备份有时会损坏、操作系统和 Postgres 更新被延迟。该计划是以最短的停机时间迁移到 Ubuntu 22.04 和 PostgreSQL 16，并带来可观察性和安全操作的秩序。

技术环境
- 3 个虚拟机（Hetzner 云）、NVMe、1 Gbps 网络
- Ubuntu 20.04 -> 22.04
- PostgreSQL 14 -> 16
- Patroni、etcd、HAProxy
- PITR 的酒保
- Prometheus + node_exporter已经有了，有些地方配置了postgres_exporter
- 访问：通过密钥 SSH，空闲时间限制 - 最终切换时不超过 10 分钟

任务及预期结果
1) 分析当前的 HA 配置 (Patroni/etcd/HAProxy/Postgres) 并确定裂脑和复制滞后的原因。将发现的问题和建议的更改记录在简短的报告中。
2) 准备计划并执行到 PostgreSQL 16 和 Ubuntu 22.04 的迁移，保留 Patroni 集群并通过 HAProxy 对应用程序进行透明切换。
3) 配置备份和恢复验证，以保证PITR 和备份的定期验证。
4）加强安全性和运行可靠性：限制网络访问、纠正内核/限制参数、日志轮转、不狂热的基本强化措施。
5) 将监控置于可以明显看到复制延迟、故障转移状态、磁盘满度、长时间运行的事务和 WAL 增长的状态。

限制
- 您无法更改应用程序和数据库架构（仅限服务器部分和 Postgres/Patroni/HAProxy 参数）。
- 您不能使用托管数据库，所有内容仍保留在当前提供商上。
- 生产的访问受到限制：黄金时间的工作只是根据商定的窗口进行读取和诊断、更改和切换。
- 文件必须对于完成工作后维护系统的工程师来说是可以理解的。

验收标准（可测量）
- 最终切换到新的主数据库需要 10 分钟，对服务产生总影响。
- 正常模式下的复制：平均负载（根据指标）时延迟备用 < 5 秒，并且没有 WAL 累积。
- 脑裂已被消除：正确的 quorum/ttl/loop_wait/retry_timeout 设置并在展台上或在商定的窗口中检查网络/节点丢失情况。
- 备份：每日完整备份或基本备份以及连续归档 WAL、成功的 PITR 测试程序，并在指定时间之前恢复到单独的虚拟机。
- 监控：Prometheus 中提供 Postgres 指标（包括复制延迟、WAL、长时间运行的查询），至少有 5 个警报（磁盘、延迟、节点不可用、错误增加、停止备份）。
- 工件传输：当前的 Patroni/HAProxy/Postgres 配置、更新和灾难恢复说明、所做更改列表。

执行步骤
- 审核和记录当前状态，收集指标和日志，诊断事件。
- 设计目标方案和回滚迁移计划。
- 新虚拟机的部署、配置的传输、Patroni/etcd/HAProxy 的配置。
- 数据迁移（pg_basebackup/pg_upgrade 或商定的方法），运行检查。
- 调酒师设置和 PITR 测试。
- 设置监控和警报、最终验证和文件传输。

您需要的专业工具
- patrictl、etcdctl、psql、pgBackRest 或 barman、pgbench（或用于运行的类似物）、Prometheus 导出器、tcpdump/ss、journald/rsyslog、Ansible（最好）以实现可重复性。

重要的
我们需要的是基础设施方面的实际工作，包括分析和仔细的迁移，而不是一般性的咨询。