Nginx四层代理不负责数据库同步，仅透明转发TCP连接；它为已配置好的跨机房同步架构（如MySQL主从、Redis Cluster）提供无感路由，支持按策略将读写请求分发至本地或异地节点，并依赖健康检查与外部监控联动保障可用性。
四层代理本身不解决数据库同步问题，它只负责TCP连接的透明转发。跨机房数据库同步是数据复制层面的事，Nginx四层代理能做的是让应用无感地访问异地数据库节点，为同步架构提供网络层支撑。
明确角色分工：代理 ≠ 同步
Nginx stream模块不读取、不解析、不修改数据库协议内容（如MySQL的binlog、Redis的RESP），它只做端口级流量搬运。真正的数据同步需依赖数据库自身机制：
- MySQL：主从复制（GTID/半同步）、MHA、Orchestrator 或云厂商的DTS服务
- Redis：主从+哨兵、Cluster模式、或RedisShake等第三方同步工具
- PostgreSQL：逻辑复制、BDR、pglogical
四层代理的作用，是在这些同步机制已就绪的前提下，把客户端请求智能路由到“当前最优”的数据库实例上，比如读流量走从库、写流量走主库、故障时自动切到备用机房。
典型跨机房代理架构配置
假设华东（sh）和华南（gz）两个机房各有一套MySQL主从集群，且已通过异步复制完成数据同步。你希望应用统一连接db-proxy.example.com:3306，由Nginx按策略分发：
- 正常情况下，读请求打到本地从库（低延迟）
- 本地从库不可用时，自动降级到异地从库
- 写请求始终打到本机房主库（避免跨机房写放大）
关键配置示例（stream块内）：
upstream mysql_sh_master {
server 10.1.1.10:3306 weight=10 max_fails=3 fail_timeout=30s;
}
upstream mysql_sh_slave {
server 10.1.1.20:3306 weight=5;
server 10.1.1.21:3306 backup; # 华南从库作为备选
}
upstream mysql_gz_master {
server 10.2.1.10:3306 weight=10;
}
upstream mysql_gz_slave {
server 10.2.1.20:3306 weight=5;
server 10.1.1.20:3306 backup; # 华东从库作为备选
}
<p>server {
listen 3306;
proxy_pass mysql_sh_master; # 默认写入华东主库
proxy_timeout 1s;
proxy_responses 1;
}</p><p>server {
listen 3307;
proxy_pass mysql_sh_slave; # 读请求走华东从库，失败则用backup
}配合健康检查提升可用性
单纯靠max_fails不够可靠，建议启用TCP健康检查（需Nginx 1.23+）：
- 在upstream中添加
health_check interval=3 fails=2 passes=2 - 配合自定义TCP探针脚本（如用
nc -z检测3306端口+简单MySQL握手） - 避免将流量导向已同步延迟过大或复制中断的从库
注意：健康检查必须与数据库复制监控联动。例如，当Seconds_Behind_Master > 60时，应主动剔除该从库，这需要外部脚本调用nginx -s reload或使用动态upstream模块（如nginx-upstream-check-module）。
安全与可观测性要点
跨机房代理对安全和排查提出更高要求：
- 所有代理节点间通信必须启用TLS（
proxy_ssl+ssl_certificate），防止中间人窃取数据库凭证 - 开启
access_log /var/log/nginx/stream.log，记录源IP、目标后端、连接耗时，便于定位慢查询源头 - 限制源IP范围：
allow 10.0.0.0/8; deny all;，避免数据库端口被意外暴露 - 设置
proxy_buffer_size 4k和proxy_buffering off，避免大结果集缓存导致内存堆积
