Nginx TCP代理不保障数据库同步稳定性，仅透明转发连接；同步依赖数据库自身机制（如GTID、半同步）和运维体系，需通过主动健康检查、内核调优及智能路由协同提升可靠性。
Nginx 的 TCP 代理本身不参与、也不保障数据库等后端服务的数据同步稳定性。它只做透明的连接转发，真正的同步稳定性必须由数据库自身机制和外围运维体系共同承担。
明确角色边界：代理只管连，不管同步
Nginx stream 模块工作在传输层，对 MySQL、Redis 等 TCP 流量不做协议解析、不读取 binlog、不干预复制过程。它既不会检测主从延迟，也不会自动切换同步源。只要后端节点 TCP 端口可达，Nginx 就会把连接转过去——哪怕该节点数据已滞后数分钟。
- 同步是否正常，取决于 MySQL 的 GTID/半同步配置、Redis 的 replica-ack 机制或 PostgreSQL 的逻辑复制状态
- Nginx 只能配合这些机制“暴露”状态，比如通过健康检查接口返回同步延迟值，但不执行修正动作
- 若主库写入卡顿而从库仍可读，Nginx 可按策略将读请求分发过去；但它无法让从库“追上”主库
用健康检查联动真实同步状态
默认 passive 检查（靠连接失败触发剔除）不足以识别“假存活”：实例进程在、端口通，但复制线程已停、延迟飙升。需主动探测同步指标：
- 为 MySQL 从库部署 /health?check=replication 健康端点，返回 Seconds_Behind_Master < 5 才标记为 healthy
- 在 Nginx stream 块中启用 health_check，并指向该端点（需搭配 http 模块或外部 probe 工具）
- 结合 Prometheus 抓取同步延迟指标，用 Alertmanager 触发 Nginx 配置热更新，动态摘除高延迟节点
连接层优化减少同步链路抖动
TCP 代理若自身连接不稳定，会放大后端同步链路的异常表现。重点调优内核与 Nginx 协同参数：
- 开启 tcp_tw_reuse = 1，避免代理频繁建连导致本地端口耗尽，影响与主库的稳定通信
- 增大 net.core.somaxconn 和 tcp_max_syn_backlog，防止突发连接请求被丢弃，造成同步客户端重试风暴
- 设置合理的 proxy_timeout（如 timeout 30s），避免因网络抖动长时间挂住连接，阻塞后续同步事务
路由策略辅助同步架构落地
当同步机制已就绪，Nginx TCP 代理可通过智能路由提升整体可用性：
- 按标签区分主从：upstream mysql_master { server 10.0.1.10:3306; }，upstream mysql_slave { server 10.0.2.20:3306; }
- 写请求固定打向 master，读请求按权重或 least_conn 分发至 slave，降低主库压力，间接利于同步稳定性
- 配置 backup 节点，在主库不可达时自动切到异地灾备主库，配合 DTS 或双写方案维持业务连续性
