主备切换时内存暴涨引发oom的核心是资源争抢、状态重建与缓存/连接双倍加载导致瞬时内存尖峰，需从预热、限流、释放、隔离四方面入手，结合cgroup与内核参数兜底防护。

主备切换时内存暴涨引发OOM，核心不是切换动作本身，而是切换过程中资源争抢、状态重建与缓存/连接双倍加载导致的瞬时内存尖峰。关键要区分是“主库切备库”还是“负载均衡器切后端节点”，但共性在于：旧连接未优雅释放 + 新连接批量建立 + 元数据/缓存重复加载 + 健康检查探测激增。解决需从预热、限流、释放、隔离四方面入手。

切换前做资源预热与连接收敛

避免切换瞬间全量重建连接和缓存：

• 主库在切换前主动降低连接保活时长（如 MySQL 的 wait_timeout 设为 30s），促使客户端提前断连或复用；
• 备库启动后、切流前，用轻量 SQL（如 SELECT 1）或小批量查询预热查询计划缓存、InnoDB buffer pool（若支持 warmup）；
• LB 层（如 HAProxy/Nginx）启用 graceful shutdown，对老 worker 进程设 maxconn=0 并等待连接自然退出，不立即 kill。

切换中限制并发与连接数

防止新流量洪峰压垮刚接管的节点：

• 在 LB 或服务发现层加 连接速率限制（conn_rate） 和 并发连接硬限（maxconn），例如 HAProxy 的 rate-limit sessions；
• 应用层使用连接池（如 HikariCP）并设置 maximumPoolSize ≤ 物理内存 × 0.6 / 单连接平均开销，避免池子撑爆；
• 暂停或降频健康检查（如将探针间隔从 5s 拉到 30s），避免切换窗口内大量 probe 请求触发重复建连。

切换后快速释放残留内存

主备角色反转常导致旧连接残留、slab 对象堆积、page cache 冗余：

• 检查 /proc/meminfo 中 SUnreclaim 是否异常高，若是，说明 dentry/inode/sk_buff 等内核对象未释放，可临时执行 echo 2 > /proc/sys/vm/drop_caches（仅清 dentries/inodes）；
• 确认备库是否启用了与主库一致的 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，避免冷启动后全量加载卡顿；
• 对 Java 类备库，添加 JVM 参数 -XX:+AlwaysPreTouch 提前触碰堆内存页，减少切换后首次分配时的 major fault 压力。

用 cgroup 与内核参数做兜底防护

即使预判失败，也要阻止单节点 OOM 波及集群：

• 将数据库或 LB 进程运行在独立 cgroup v2 下，设 memory.max（如 4G）和 memory.high（如 3.5G），触发 memory.high 时内核自动回收，不等耗尽才 OOM；
• 调大 vm.min_free_kbytes（如设为物理内存 3%），让内核更早开始 page reclaim，避免 lowmem 耗尽触发 oom-killer；
• 禁用非关键进程的 OOM 杀手权重：echo -1000 > /proc/PID/oom_score_adj，确保 DB/LB 进程比监控脚本、日志 agent 更难被杀。