nginx 不能同步数据，因其仅为反向代理/负载均衡器，不感知、不管理业务数据；数据一致性须由应用层、数据库层（如mysql主从）、共享存储（如nfs）或对象存储（如oss）等上层机制保障。
Nginx 本身不负责业务数据存储，双机热备环境中的“数据同步”不是 Nginx 的职责，而是上层应用或后端服务需解决的问题。Nginx 在这里只承担流量接入与故障切换角色。真正的数据一致性必须在应用层、文件层或数据库层实现。
为什么不能靠 Nginx 同步数据
Nginx 是反向代理/负载均衡器，不是分布式存储系统。它不感知、不管理、也不复制后端的业务数据（如用户上传的图片、数据库记录、会话状态等）。即使配置了双机热备，若两台后端服务各自写本地磁盘或独立数据库，切换后必然出现数据不一致、丢失或覆盖。
常见业务场景对应的数据同步方案
静态资源（HTML/CSS/JS/图片等）
需确保主备节点的 Web 根目录内容完全一致：
- 使用共享存储（如 NFS、GlusterFS），让两台服务器挂载同一份文件系统
- 通过 rsync + inotify 或定时任务，将主节点更新自动推送到备节点
- 结合 CI/CD 流水线，发布时同时部署到两台机器（推荐用于中小规模）
动态数据（数据库记录、用户行为日志等）
由后端应用连接的数据库决定同步方式：
- MySQL 主从复制：主库写，从库读；Keepalived 切换 VIP 时，需配合脚本修改应用连接地址或使用中间件（如 ProxySQL）
- MySQL 主主复制（双写）：两节点均可读写，但需处理自增 ID 冲突、死锁等问题，运维复杂度高
- Redis 哨兵或 Cluster 模式：保障缓存高可用，避免会话丢失
- 应用层无状态化：将 session 存入 Redis 或数据库，而非本地内存，使任意节点可处理请求
用户上传文件（头像、附件等）
禁止保存在 Nginx 所在服务器本地：
- 统一上传至对象存储（如 MinIO、阿里云 OSS、腾讯云 COS），前后端直传，Nginx 仅作反向代理或 CDN 回源
- 若必须自建，采用分布式文件系统（如 FastDFS、Ceph）或 NAS 共享路径
Keepalived + Nginx 配合数据同步的关键点
即便数据已同步，仍需防止“VIP 漂移但服务未就绪”导致的请求失败：
- 在 Keepalived 中配置
vrrp_script，调用健康检查脚本（如检测 Nginx 进程 + 后端 DB 连通性 + 文件系统挂载状态） - 脚本返回非零值时，Keepalived 自动降低 priority，触发 VIP 切换
- 避免仅检查 Nginx 端口存活——进程在但数据库连不上，照样无法提供完整业务
不推荐的“伪同步”做法
以下方式看似简单，实则隐患大，生产环境应规避：
- 仅靠 Nginx 的
backup参数做上游容灾（如server 192.168.1.10:80 backup）：这属于负载均衡策略，不是双机热备，无 VIP，客户端 DNS 或 IP 直连无法自动切换 - 手动复制数据库文件或 tar 打包同步：易出错、不实时、无法保证事务一致性
- 依赖两台机器时间同步（ntpd/chrony）就认为数据一致：时间一致 ≠ 数据一致
