双机热备不承担负载分担，其节点负载趋势不可用于预判扩容；扩容决策应基于业务层真实压力，如qps/tps上升、慢查询增多、同步延迟增大等指标。
双机热备系统本身不直接承担负载分担任务，它的核心目标是高可用——主节点运行服务，备节点待命同步。因此，**不能靠“双机热备节点的负载趋势”来预判扩容需求**。真正需要分析的是上游或后端的实际业务系统（比如应用服务器集群、数据库读写流量、API网关请求量等）的负载趋势。把热备节点当“负载指标看板”，容易误判。
明确双机热备与扩容的逻辑边界
双机热备（如金仓KES Active/Standby）中，备节点长期处于空闲或极低负载状态，仅做WAL日志回放和数据同步。它的CPU、内存使用率稳定偏低，不代表系统容量充足；主节点负载升高，也不代表要给热备系统“加机器”，而往往意味着背后的数据写入压力、查询并发或事务吞吐已逼近瓶颈。
- 热备架构解决的是“故障时能否秒级接管”，不是“当前能不能撑住更多用户”
- 扩容决策依据应来自业务层真实压力：数据库QPS/TPS持续上升、慢查询比例增加、连接池频繁打满、归档延迟增大等
- 若主节点长期CPU >80%、WAL生成速率翻倍、同步延迟超过秒级，说明数据层已承压，需评估是否升级单节点配置，或转向多节点集群（如读写分离+分库分表）
用负载趋势反推真实扩容窗口
虽然热备节点自身负载无参考价值，但可结合其同步行为间接判断底层压力变化：
- 同步延迟趋势上升：主库WAL产生速度 > 备库重放速度，说明写入洪峰来临，可能是批量导入、报表生成或IoT设备集中上报所致
- 备库WAL堆积量持续增长：监控pg_stat_replication视图中的pg_wal_lsn_diff或KES对应指标，连续3天增长超20%，提示主库I/O或备库磁盘性能已达临界
- 主库检查点频率异常增高：反映WAL循环压力大，常伴随checkpoint_timeout被频繁触发，需结合pg_stat_bgwriter分析，这是扩容前典型征兆
搭配容量规划工具做闭环验证
单看热备指标不够，必须叠加主动容量评估：
- 用POne或MeterSphere对核心业务链路做阶梯式压测，观察数据库在不同并发下的响应时间拐点
- 采集过去90天的SQL执行耗时P95、全表扫描次数、索引命中率，识别劣化趋势
- 将业务增长预测（如医保平台参保人数年增12%）映射为数据库日均写入量、归档空间月增需求，反推存储与计算资源余量
- 若预测6个月内主节点磁盘使用率将超85%，或连接数达max_connections的90%，即触发扩容流程
扩容动作必须绕开热备层直接落地
确认扩容必要后，操作对象不是热备对本身，而是支撑它的基础设施：
- 主备节点硬件升级（如SSD换NVMe、内存从128G扩至256G），需确保两端配置一致，避免同步异常
- 数据库层扩容：启用读扩展（KES支持只读备节点分担查询）、调整shared_buffers与work_mem参数
- 上移一层扩容：在应用与数据库之间加Redis缓存层，降低热备主库直连压力
- 彻底转型：当单主架构成为瓶颈，可将Active/Standby升级为KES集群版（多协调节点+数据节点分片），此时才真正进入“多机集群模式”
