Valkey）¶

版本基线： Keepalived 2.4.3（2026-07-20，新增 VRRP auth_hmac HMAC 认证）· HAProxy 3.4 LTS（2026-06-03 发布，最新 3.4.7，支持至 2031-Q2；3.2 LTS 至 2030-Q2；3.1 已于 2026-01 EOL）· LVS：内核模块 ip_vs（随内核，用户态工具 ipvsadm）· MySQL：当前 LTS 9.7（2026-04 GA），8.4 LTS 仍受支持 · PostgreSQL 18.6 / 17.11（2026-08-13 维护更新，跳过 18.5 回归版；19 为 Beta 3；14 于 2026-11-12 EOL） · Patroni 4.1.5（2026-08-12，MIT） · pg_auto_failover 2.2（2025-04，仓库已迁至 hapostgres 组织，仍活跃但发版慢） · repmgr 5.5.1（2026-11-05 安全修复，EDB 维护但发版稀疏） · Redis 8.10（8.10.3，2026-10；8.2 为 LTS 支持至 2030-09）· Valkey 9.1.3（2026-10-26，Linux 基金会 BSD-3；维护线 9.0.7/8.1.11/8.0.12/7.2.15） · KeyDB 6.3.x（Snap 收购后近三年未发新版，半停滞） · Dragonfly 2.1（2026-11-04，许可由 BSL 1.1 改为 DSAL，生产 ≤100 vCPU 免费；BSL 时代末版 1.40.1）（核对日期 2026-11-11，来源：官网/GitHub）

环境约束（本实验环境）： - 宿主机：Windows Server，2×Xeon Gold 6138（40 核 80 线程），256GB 内存 - 实验 VM：Ubuntu 22.04，Hyper-V 内由 Vagrant 管理（内部交换机 + NAT 双网卡） - 磁盘：F 盘 895G，剩余约 862G - 落盘约束：所有产物只存 F:\EricLiu\ 下；服务以 Docker 优先

本分册供 AI 助手在指导用户做高可用实验/故障演练时查阅。

1. 高可用概念速览¶

三级演进： - 单机：一台 VM 跑全部服务，故障即停机（SPOF）。 - 集群：多台承载同一服务分摊流量（水平扩展），但调度器/入口本身可能仍是 SPOF。 - 高可用（HA）：在集群之上消除单点——入口用 VRRP 虚拟 IP（Keepalived）或负载均衡多活（HAProxy/LVS），数据层用主从复制 + 自动故障转移（MySQL 主从/MGR、Redis 哨兵/Cluster）。目标：任何一台宕机，服务在秒级~分钟级自动恢复（RTO），数据尽量不丢（RPO）。

VRRP/VIP 原理（一段话）： 多台主机组成一个虚拟路由器，共享一个虚拟 IP（VIP）与虚拟 MAC；同一时刻只有 MASTER 节点持有 VIP 并周期性（默认 1s）发送 VRRP 通告，其余为 BACKUP；BACKUP 在通告超时（默认 3× 间隔 + 偏移）内收不到通告就抢占 VIP（发免费 ARP 告知网段），从而实现入口 IP 的秒级漂移。Keepalived = VRRP（VIP 管理）+ IPVS/LVS（四层负载）+ 健康检查（把故障节点从转发池剔除）+ BFD（毫秒级故障检测，可选）。

常用架构图（ASCII）：

                       客户端（宿主机浏览器/其他 VM）
                                |
                        VIP 192.168.56.100   ←—— 漂移入口（Keepalived VRRP）
                                |
                +---------------+---------------+
                |                               |
         LB-1 (MASTER)                    LB-2 (BACKUP)
    192.168.56.10 + HAProxy           192.168.56.11 + HAProxy
                |       (TCP:3306/6379, HTTP:80/443, check /health)
        +-------+--------+--------+-------+
        |                |                |
   App/Web 节点1      App/Web 节点2     App/Web 节点3
        |                |                |
        +-------- 数据层（主从+自动切换）---------+
        |                                 |
  MySQL-A (主) <—半同步复制—> MySQL-B (从)     Redis-Master(6379)
  MySQL-C/MGR 备选                        Redis-Replica + 3×Sentinel

1.1 选型对比表（组件级）¶

HA 不是"一个软件"，而是入口层 + 负载层 + 数据层的组合。

组件	定位	版本基线	许可证	CPU / 资源	推荐场景（适用范围）	主要限制（不适合/回避）
Keepalived	VRRP 虚拟 IP 漂移 + 健康检查（可挂 IPVS）	2.4.3（2026-07）	GPL-2.0	极低（单进程、MB 级内存）	入口 VIP 主备、LB 双机热备；Ubuntu 仓库直装	只做主备不做多活（多活要 LVS/ECMP/Anycast）；Hyper-V 必须开 VM 网卡 MacSpoofing 否则免费 ARP 被丢、VIP 不漂移；同网段 `virtual_router_id`/密码必须唯一；2.4.x auth_hmac 各小版本签名输入有变化，整组必须同步升级
HAProxy	四层/七层负载均衡 + 主动健康检查	3.4 LTS（2026-06，支持至 2031-Q2）	GPL-2.0	低（单核可跑，万级并发；多线程版按核扩展）	HTTP/TCP 反向代理、`/health` 探活、灰度与限流；与 Keepalived 组 VIP 双机	配置语法严格（改完必 `haproxy -c`）；无内置服务发现/配置下发（要 consul-template/Ansible）；3.1 已 EOL，别再用非 LTS 线
LVS / IPVS	内核态四层负载（DR/NAT/TUN 模式）	`ip_vs` 随内核 + ipvsadm	GPL-2.0	极低（内核转发，吞吐最高）	超高吞吐入口、多活 LB（DR 模式后端可直接回包）	仅四层、无应用层健康检查；DR 模式要求 RS 配 VIP 并抑制 ARP（`arp_ignore/arp_announce`），调试门槛高；NAT 模式回程必须过 LB，易成瓶颈
Nginx（开源）	七层反代 / 负载均衡	1.28.x stable	BSD-2-Clause	低	已有 Nginx 栈时顺带做 LB、静态资源与 TLS 终止	主动健康检查与企业级动态 upstream 属 NGINX Plus；改 upstream 需 reload；长连接调优比 HAProxy 繁琐
MySQL 9.7 LTS / 8.4 LTS	关系库 + 原生主从复制	9.7（2026-04 GA）；8.4 LTS 仍在支持	GPL-2.0（FOSS 例外）	中（建议 4C8G 起）	主从/半同步复制、读写分离（配合 HAProxy 只读池）	原生主从没有自动切主，切主靠脚本/Orchestrator/Patroni 或 MGR；8.4 起 `CHANGE MASTER TO` 已移除，旧教程会直接报错；大事务/DDL 造成从库延迟
PostgreSQL 18 / 17	关系库 + 流复制/逻辑复制	18.6 / 17.11（2026-08-13 维护更新）	PostgreSQL License（类 BSD/MIT，闭源内嵌商用无限制）	中（建议 4C8G 起）	流复制主从（同步/异步）、复杂查询/JSON/扩展生态（PostGIS、pgvector）；要自动切主叠加 Patroni/pg_auto_failover（见 §1.2）	原生同样没有自动切主，切主一律交给 Patroni 等编排器；复制槽 `wal_status=lost` 后从库只能重建；大版本升级需 `pg_upgrade` 演练
MySQL MGR（组复制）	Paxos 组复制，自动选主	随 MySQL 9.7/8.4	GPL-2.0	中高（≥3 节点，网络要求高）	要自动故障转移、RPO≈0 的核心库	至少 3 节点、多数派确认写入，跨机房延迟敏感；单主模式写入仍集中在一台；运维复杂度高于主从
Redis 8.x	缓存 + 哨兵/Cluster	8.10.x；8.2 为 LTS	RSALv2 / SSPLv1 / AGPLv3 三选一	低（哨兵与实例都很轻）	缓存、会话、队列；1 主 1 从 + 3 哨兵做自动切主	许可证限制商业转售/托管服务（自用无碍）；哨兵是异步复制，切主有秒级丢数据窗口（RPO>0）；哨兵必须 ≥3 且奇数，quorum=(N/2)+1
Valkey	Redis 的 BSD 分支（Linux 基金会）	9.1.3（2026-10-26）；9.0.7/8.1.11/8.0.12/7.2.15 各线均维护	BSD-3-Clause	低（同 Redis；9.x 重设计 I/O 线程模型，单机 210 万 QPS）	许可敏感、要嵌入商业产品的场景；RESP 协议兼容，`redis-cli`/redis-py/jedis 等客户端无缝直连，可直接替代 Redis	生态与云托管覆盖少于 Redis，部分 Redis 模块/新特性跟进滞后；与 Redis 8.x 新命令有少量差异，上线前需实测
KeyDB	Redis 多线程分支（2022 被 Snap 收购）	6.3.x（近三年未发新版，半停滞）	BSD-3-Clause	低-中（`server-threads` 多线程，spinlock 过高会内耗，官方建议 4）	仅限存量环境；特色是 Active Replication 双主互写	新部署回避：特性停留在 Redis 6.2.x 时代、无 Sentinel 支持，活跃度远低于 Valkey/Dragonfly；Snap 营销投入已沉寂
Dragonfly	多线程 Redis/Memcached 兼容内存库（shard-per-thread）	2.1（2026-11-04）；BSL 时代末版 1.40.1	⚠️ DSAL（源可用，非 OSI 开源）：2.1 起从 BSL 1.1 改为 DSAL；生产 ≤100 vCPU 免费，超出需商业授权，不得以它对外提供托管服务；1.x 各版本到期后自动转 Apache-2.0	中高（单实例吃满多核，本机 40 核可用 `--proactor_threads` 压满；io_uring、免 fork 快照）	单机多核高吞吐缓存（官方口径 25× Redis）、用一个节点替代分片 Redis 集群	许可顾虑点写明：非开源许可且 2.1 起不可再转 Apache（仅 1.x 有到期转换）；命令覆盖 ~185+，冷门命令/模块兼容需实测；HA 模型仅 primary-standby 异步复制，切主要自己做

1.2 PostgreSQL 高可用方案与 MySQL 选型对比¶

PG 原生流复制（物理复制：primary_conninfo + 复制槽 + pg_basebackup 建从库）与 MySQL 主从同层次：复制本身免费可靠，但不带自动切主，切主一律交给编排器。三个主流方案（2026-11-11 活跃度核实）：

方案	最新版本	架构	活跃度 / 维护方	适用场景	主要注意
Patroni	4.1.5（2026-08-12）	每节点 Patroni sidecar + DCS（etcd/Consul/K8s）持有 leader key；REST API（默认 8008，`/primary` `/replica`）供 HAProxy 做健康检查路由	MIT，非常活跃（Zalando 起家，4.1 线 2026 年连续发版，4.1.5 已适配 PG 14.24~18.6）；事实标准	生产首选；开同步复制 quorum 可做 RPO≈0	需 ≥3 节点 DCS；支持 PG 10~18；ttl/loop_wait 默认 30s/10s，VM 环境抖动可调大
pg_auto_failover	2.2（2025-04-03；仓库已由 citusdata 迁至 hapostgres，仍活跃但发版慢）	PG 扩展 + monitor 节点状态机，两数据节点 + 1 monitor 即可起步	Citus/微软系出身，活跃度中等	想少组件、小集群（1 主 1 备）的自动切主	单 monitor 是薄弱点（可加二级 monitor）；社区版发版节奏慢
repmgr	5.5.1（2026-11-05，通知命令安全修复；上一版 5.5.0 是 2024-11）	repmgrd 守护进程 + 可选 witness 节点，无外部 DCS	EDB 维护，发版稀疏（近两年仅两版）；支持 PG 13~18	已有 repmgr 存量运维；简单主从 + 事件通知脚本做 VIP/DNS 切换	不自带 fencing：旧主不会停机，防脑裂要自己写脚本；新集群优先 Patroni

与 MySQL 的选型对比（本环境）：

维度	MySQL 9.7 / 8.4 LTS	PostgreSQL 18 / 17
复制机制	主从/半同步；组复制 MGR（Paxos）	流复制（同步/异步）+ 逻辑复制；MGR 的对应物是 Patroni + DCS
自动切主	MGR（≥3 节点）或 Orchestrator	Patroni（生态最成熟）/ pg_auto_failover
许可证	GPL-2.0（FOSS 例外）	PostgreSQL License（类 BSD，闭源内嵌无顾虑，最宽松）
优势场景	运维团队熟悉度高、云托管配套多、教程生态厚	复杂查询/JSONB/扩展（PostGIS、pgvector 做 RAG 向量库）
本环境结论	团队已熟、维持现状 → MySQL 主从（自动切主再上 MGR）	新项目要许可宽松或向量检索 → PG 18 流复制 + Patroni，HAProxy 按 `/primary` `/replica` 端点路由读写

1.3 推荐结论（本环境）¶

首选 = Keepalived 2.4.3 + HAProxy 3.4 LTS：GPL、Ubuntu 仓库直装、配置可全部进 Ansible/git，VIP 秒级漂移 + /health 探活即可覆盖入口层高可用。
数据层首选 = MySQL 9.7 LTS（或 8.4 LTS）主从 + Redis 8.x 哨兵（3 哨兵）：实验/内网足够；要自动切主再上 MGR（≥3 节点）或 Orchestrator/Patroni。PG 路线 = PostgreSQL 18.6 流复制 + Patroni 4.1.5（etcd 3 节点）：适合需要类 BSD 许可、pgvector 向量检索或更复杂查询的项目（部署模板见 §2.3 补充说明）。
缓存替代品结论 = 自用/许可敏感首选 Valkey 9.1.3（Linux 基金会 BSD-3，RESP 兼容，客户端无缝）；单机要把 40 核压满的高吞吐场景选 Dragonfly 2.1（shard-per-thread 多线程；⚠️ 许可顾虑点：DSAL 源可用许可，生产 ≤100 vCPU 免费、禁止对外托管转售，非 OSI 开源）；KeyDB 新部署回避（Snap 收购后近三年无新版，特性停在 Redis 6.2.x 时代）。
选配 = LVS/IPVS（超高吞吐或多活入口）、Nginx（已有栈顺带做七层）、pg_auto_failover/repmgr（PG 小集群/存量环境）。
回避 = 裸 MySQL 主从当"高可用"（无自动切主，主挂了要人工介入）；裸 PG 流复制同理（切主靠 Patroni）；商用转售/托管场景直接嵌 Redis 8.x（RSALv2/SSPL 限制，改用 Valkey）；新部署 KeyDB；Hyper-V 不开 MacSpoofing 就上 Keepalived（VIP 永远不漂移，是最常见的假故障）。

2. 安装与配置模板¶

2.1 HAProxy（apt 或 Docker；四层/七层模板）¶

sudo apt install -y haproxy          # Ubuntu 22.04 仓库版；新版本可加 haproxy PPA
haproxy -v                            # 确认版本

# /etc/haproxy/haproxy.cfg 核心模板（七层 HTTP + 健康检查 + /health）
global
    log /dev/log local0
    maxconn 4096
    daemon

defaults
    mode    http
    log     global
    option  httplog
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend web_fe
    bind *:80
    default_backend web_be

backend web_be
    balance roundrobin
    # 七层健康检查：GET /health 期望 2xx/3xx
    option httpchk GET /health
    http-check expect status 200
    server app1 192.168.56.20:8080 check inter 2s fall 3 rise 2
    server app2 192.168.56.21:8080 check inter 2s fall 3 rise 2
    # 本机统计页（观察用，只绑内网）
listen stats
    bind *:8404
    stats enable
    stats uri /stats

# 四层 TCP（数据库/Redis 走只读转发示例）
listen mysql_ro
    mode tcp
    bind *:3307
    option tcp-check
    server mysql_a 192.168.56.30:3306 check
    server mysql_b 192.168.56.31:3306 check backup   # backup 角色：主故障才启用

haproxy -c -f /etc/haproxy/haproxy.cfg   # 语法检查（必做）
sudo systemctl restart haproxy

2.2 Keepalived（主备模板：VRRP + VIP + track_script）¶

sudo apt install -y keepalived ipvsadm

# /etc/keepalived/keepalived.conf —— LB-1（MASTER），LB-2 把 state 改 BACKUP、priority 改 100
global_defs {
    router_id lb1
    script_user root
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"   # haproxy 挂了就降级
    interval 2
    weight -30
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth1                  # 内部交换机那块网卡（ip a 确认）
    virtual_router_id 51            # 主备必须一致
    priority 150                    # MASTER 高，BACKUP 低（100）
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass S3cre7HA          # ≥8 字符，两台一致
    }
    virtual_ipaddress {
        192.168.56.100/24 dev eth1  # VIP：客户访问的入口
    }
    track_script {
        chk_haproxy
    }
}

sudo systemctl enable --now keepalived
# 现状核实（2026-11）：Keepalived 2.4.x 引入 auth_hmac 扩展（对抗通告伪造/重放），
# 实验环境用经典 PASS 认证即可，但注意同网段 ID/密码唯一，防止与其它 VRRP 组冲突。

2.3 MySQL 主从最小配置要点¶

# 主库 /etc/mysql/conf.d/replication.cnf
[mysqld]
server-id        = 1
log_bin          = mysql-bin
binlog_format    = ROW
# 8.0+ 默认已含 gtid_mode; 半同步（可选，MySQL 8.4 起半同步插件已内置为 source 复制选项）
# gtid_mode = ON / enforce_gtid_consistency = ON

-- 主库：建复制账号
CREATE USER 'repl'@'192.168.56.%' IDENTIFIED BY '<强密码>';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.56.%';

-- 从库：指向主库（GTID 方式最简）
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.56.30', SOURCE_USER='repl', SOURCE_PASSWORD='<强密码>',
  SOURCE_AUTO_POSITION=1;
START REPLICA;
SHOW REPLICA STATUS\G          -- 看 Replica_IO_Running / Replica_SQL_Running / Seconds_Behind_Source

要点：server-id 全局唯一；复制账号只给 REPLICATION SLAVE 权限；只读从库设 super_read_only=ON；MySQL 9.x LTS 可用，实验环境 8.4 LTS 亦可（8.4 中 CHANGE MASTER TO 已移除，统一用 CHANGE REPLICATION SOURCE TO）。

补充：PostgreSQL 流复制最小要点（对应 §1.2 PG 路线）：

# 主库 postgresql.conf
listen_addresses = '*'
max_wal_senders  = 10
wal_level        = replica
# pg_hba.conf 放行从库：host replication repl 192.168.56.0/24 scram-sha-256
sudo -u postgres psql -c "CREATE ROLE repl REPLICATION LOGIN PASSWORD '<强密码>';"
# 从库（空目录）一键拉取基础备份并接管：
pg_basebackup -h 192.168.56.30 -U repl -D /var/lib/postgresql/18/main -R -X stream -P
# -R 自动写入 primary_conninfo 并以 standby 模式启动；主库验证：
sudo -u postgres psql -c "SELECT client_addr, state, replay_lag FROM pg_stat_replication;"

自动切主按 §1.2 选 Patroni（Docker 跑 etcd 3 节点 + 每节点 Patroni，REST API 8008 交给 HAProxy 健康检查路由），小集群可用 pg_auto_failover（1 主 1 备 + 1 monitor）。

2.4 Redis 哨兵最小配置要点（Docker 优先）¶

# docker-compose 最小拓扑：1 主 + 1 从 + 3 哨兵（示意其中哨兵 1）
services:
  redis-master:
    image: redis:8.2.11            # 8.2 为 LTS
    command: redis-server --requirepass <强密码>
  redis-replica:
    image: redis:8.2.11
    command: redis-server --replicaof redis-master 6379 --masterauth <强密码> --requirepass <强密码>
  sentinel1:
    image: redis:8.2.11
    command: redis-server /etc/sentinel.conf --sentinel
    volumes:
      - ./sentinel1.conf:/etc/sentinel.conf

# sentinel1.conf（3 个哨兵各一份，端口区分）
port 26379
sentinel monitor mymaster 192.168.56.40 6379 2     # 2 = quorum：≥2 个哨兵判定主观下线才切主
sentinel auth-pass mymaster <强密码>
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

要点：哨兵必须 ≥3 且为奇数；quorum 用 (N/2)+1；客户端一律走 Sentinel API 而非直连 IP；Redis ≥7.4 许可证为 RSALv2/SSPLv1/AGPLv3 三选一（自用无碍，商业转售受限制，BSD 衍生版可考虑 Valkey 9.1.3——把镜像换成 valkey/valkey:9.1.3、命令换成 valkey-server --sentinel 即可，哨兵逻辑一致）。

3. 高频命令¶

# ---- LVS / IPVS ----
sudo modprobe ip_vs && lsmod | grep ip_vs        # 加载/确认内核模块
sudo ipvsadm -Ln                                  # 查看虚拟服务与真实服务器表（-L -n）
sudo ipvsadm -Lnc                                 # 连接表
sudo ipvsadm -Ln --stats                          # 转发统计

# ---- HAProxy ----
haproxy -c -f /etc/haproxy/haproxy.cfg            # 配置语法检查（改完必跑）
sudo systemctl reload haproxy                     # 平滑重载（不断连接）
echo "show stat" | socat stdio /var/run/haproxy.sock  # 动态看后端状态（如配置了 socket）
# 统计页：http://192.168.56.10:8404/stats

# ---- VIP 漂移观察 ----
ip addr show eth1 | grep 192.168.56.100           # 谁挂着 VIP
sudo tcpdump -i eth1 vrrp                          # 抓 VRRP 通告（看 MASTER 心跳/切换瞬间免费 ARP）
journalctl -u keepalived -f                        # 跟踪主备切换日志

# ---- MySQL 主从状态 ----
mysql -uroot -p -e "SHOW REPLICA STATUS\G"         # 从库视角：IO/SQL 线程、延迟秒数
mysql -uroot -p -e "SHOW BINARY LOG STATUS"        # 主库视角（8.4+，替代 SHOW MASTER STATUS）
mysql -uroot -p -e "STOP REPLICA; START REPLICA;"  # 重启复制（修复中断后）

# ---- Redis 哨兵 ----
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster   # 当前主库地址
redis-cli -p 26379 SENTINEL masters | head -40                 # 监控目标概要
redis-cli -h 192.168.56.41 -p 6379 INFO replication            # 从库角色与偏移量
redis-cli -p 26379 SENTINEL failover mymaster                  # 手动强制切换（演练用）

4. 故障演练设计¶

三类演练，每次演练先做 Hyper-V 快照（Checkpoint-VM），演练后记录 RTO/RPO。

演练一：kill 实例（应用层故障） 1. 在 app 节点 pkill nginx（或 docker stop <容器>）； 2. 观察 HAProxy stats 页：该节点 check 变 DOWN，流量 2~6s 内切到其余节点； 3. systemctl start nginx 恢复，观察自动 UP 回池。 - Redis：docker stop redis-master，观察哨兵 quorum 判定 → failover → 新主选出。

演练二：断网（节点级故障） 1. 在 LB-1（VIP 持有者）上模拟断网：Vagrant/Hyper-V 断开内部交换机网卡，或 sudo ip link set eth1 down； 2. 在 LB-2 上 3×advert 间隔内观察 ip addr 出现 VIP，tcpdump vrrp 可见 LB-2 开始发通告； 3. 从客户端持续 curl VIP（while true; do curl -s -o /dev/null -w "%{time_total}\n" http://192.168.56.100/health; sleep 0.5; done）记录中断窗口； 4. 恢复网卡，观察 LB-1 是否抢占回来（默认抢占）。

演练三：重启 VM（整机故障） 1. Hyper-V 直接重启 LB-1 VM； 2. 记录从 VM 停止到 VIP 在 LB-2 生效、服务恢复的总时长； 3. VM 起来后核对 keepalived/haproxy 自启动（systemctl is-enabled）。

RTO/RPO 记录表模板：

演练编号	日期	类型	故障注入方式	服务	检测到故障时刻	服务恢复时刻	RTO	数据丢失（RPO）	观察备注	快照恢复 ✔
DR-01	2026--	kill 实例	pkill nginx	Web	::__	::__	__s	无	check 3 次失败才剔除	✔
DR-02		断网	ip link set eth1 down	VIP/HA			__s		免费 ARP 广播生效
DR-03		重启 VM	Hyper-V Restart-VM	全栈			__s
DR-04		kill 实例	docker stop redis-master	Redis			__s	未落盘写入	哨兵 failover 全程

5. 排障¶

症状	原因与排查
VIP 不漂移	① `journalctl -u keepalived` 报 "receive an invalid packet"：两台 `virtual_router_id`/密码不一致或同网段撞组；② Hyper-V vSwitch 默认开 MAC 欺骗防护，VM 发免费 ARP（VIP 的源 MAC）被丢弃——宿主机 PowerShell 执行 `Set-VMNetworkAdapter -VMName <VM> -MacSpoofing On`（所有 HA 节点都要开）；③ `interface` 名写错（Vagrant 网卡常是 eth1，`ip a` 确认）；④ 防火墙拦 VRRP 协议号 112：`ufw` 下需放行或临时关闭验证
脑裂（两台都持 VIP）	通常由断网期间两台互收不到通告+都认为自己是 MASTER 造成；`tcpdump vrrp` 看是否双通告；处理：恢复网络后以 priority 高的一台为准，另一台 `systemctl restart keepalived`；根治：加独立心跳链路（本环境可用第二块 NAT 网卡做 unicast 心跳：`unicast_src_ip`/`unicast_peer`），并用 `net.ipv4.conf.all.arp_ignore/arp_announce` 调整 ARP 行为
健康检查误判	① 检查超时太短（`inter 2s fall 3` 被网络抖动触发）→ 加大 inter/fall；② `option httpchk GET /health` 但应用 /health 返回非 200 → `http-check expect status` 匹配实际码；③ 七层检查连通但应用假死 → 换更深的检查（查特定路径/连接后端 DB）；④ tcp mode 下 tcp-check 端口写错
主从延迟（Seconds_Behind_Source 持续>0）	① 从库单线程追不上：MySQL 8.0+ 开 `replica_parallel_workers`（基于 WRITESET：`binlog_transaction_dependency_tracking=WRITESET`）；② 大事务/DDL 期间避免演练；③ `SHOW REPLICA STATUS\G` 看 Last_Errno 是否报错卡住（先修错误再 START REPLICA）；④ 半同步复制下网络抖动会退化为异步，观察 `Rpl_semi_sync_*` 状态变量
PostgreSQL 主从延迟（`pg_stat_replication.replay_lag` 持续增长）	主库看 `SELECT client_addr, write_lag, flush_lag, replay_lag, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication;`：① 大事务/`VACUUM FULL`/批量导入期间延迟属正常，等回放追平再演练；② 从库 IO 瓶颈（Hyper-V 虚拟盘）→ 看从库磁盘负载与 `wal_receiver_status_interval`；③ 复制槽 `wal_status=lost` 说明 WAL 已被主库回收，从库只能 `pg_basebackup` 重建（防止丢失：主库调大 `max_slot_wal_keep_size`）；④ Patroni 管理的集群里副本延迟超 `ttl` 会被判不健康触发切主，先调大 `ttl`/`loop_wait` 再排查
Patroni 不切主 / 反复切主	① 逐节点 `curl http://<节点>:8008/primary`（/replica /health）确认 REST API，HAProxy 检查超时要 > Patroni 判定窗口，否则会误摘健康节点；② DCS（etcd）多数派挂掉时 Patroni 整体拒绝切主（防脑裂，设计如此）——`patronictl list` 看成员状态，先修 etcd；③ 反复切主常见于 `ttl` 太小（默认 30s）或 VM 网络抖动，Hyper-V 环境可调 `ttl: 60` / `loop_wait: 15` 观察；④ 旧主恢复后 Patroni 默认不会自动把它拉回主位（避免数据回退），需 `patronictl reinit` 重建该副本；⑤ 手动演练用 `patronictl switchover`（受控）而非 kill 进程
哨兵反复切换（抖动）	`down-after-milliseconds` 太短；quorum 与哨兵数不匹配；主库瞬时网络抖动被判定主观下线——调大超时、检查 VM 网卡是否被限速

Hyper-V 网络兼容注意（本环境专属）： - 内部交换机为二层广播域，VRRP 组播/通告与免费 ARP 理论可达，但必须开启 VM 网卡 MAC Spoofing（见上），这是 Hyper-V 上 Keepalived 最常见坑。 - 宿主机访问 VIP：内部交换机网段宿主机有对应接口 IP，可直接访问 VIP；但宿主机重启后 vSwitch 绑定顺序变化可能导致 ARP 缓存残留，arp -d * 清缓存再试。 - NAT 网卡（默认出口）不要承载 VIP 与 VRRP，只做外网更新。

6. AI 操作守则（AI 助手指导操作时必须遵守）¶

演练前 snapshot：任何故障演练/切主操作前，对相关 VM 全部做 Hyper-V 检查点（Checkpoint-VM），并记录快照名；演练完成验证服务正常后再合并/删除快照（磁盘余量足，862G，但仍及时清理）。
生产红线：若目标环境是真实生产系统——禁止直接 STOP REPLICA 后不做 GTID 核对就切主；禁止对运行中的主库执行 RESET REPLICA ALL/FLUSH LOGS 级操作；禁止在无 VIP/双入口情况下"顺手"重启负载均衡全部节点。
变更走 git：keepalived.conf、haproxy.cfg、MySQL 配置、sentinel.conf 一律进 Ansible + git 管理；面板（Portainer/1Panel）内手改仅限应急，24h 内回写。
凭据不落明文：repl 账号密码、Redis requirepass 用 Ansible vault/密钥库，文档中一律 <强密码> 占位。
端口与网络：HA 组件管理端口（HAProxy stats 8404、MySQL 3306、Sentinel 26379）只绑内部交换机网段；宿主机之外的访问一律拒绝。
版本升级：Keepalived 2.4.x 的 auth_hmac 各点版本（2.4.1/2.4.2/2.4.3）签名输入有变化，整组节点必须同步升级；HAProxy 升级先 haproxy -c 验证新配置；MySQL/PostgreSQL/Redis 大版本升级前必须先演练主从重建；Dragonfly ≥2.1 许可从 BSL 1.1 变为 DSAL，升级前重新核对授权条款（生产 ≤100 vCPU 免费）。
演练后必留痕：填写第 4 节 RTO/RPO 记录表并把结果提交 git，作为下次改进基线。