应调高 net_read_timeout（如120–300秒），因其控制建连后读取响应超时，跨境链路抖动易触发该超时；connect_timeout可适度提高至30秒但不宜过大；客户端需同步配置socketTimeout。
MySQL 连接超时后重试失败，connect_timeout 和 net_read_timeout 哪个该调？
跨可用区甚至跨国的 mysql 连接，真正卡住你的往往不是首次建连慢，而是建连成功后读取响应时突然断开——这时候 connect_timeout 已经生效完毕，真正起作用的是 net_read_timeout。它默认 30 秒，但跨境链路抖动时，一个大查询或长事务可能卡在传输中间，触发这个超时并直接断连。
实操建议：
-
net_read_timeout必须调高（比如 120–300），尤其当应用会执行SELECT大结果集、或依赖LOAD DATA等网络密集型操作 -
connect_timeout可适度提高（如从 10 改为 30），但不宜过大，否则连接池等待失败连接的时间拉长，掩盖真实网络故障 - 服务端调参后，客户端也要同步：JDBC 需显式加
socketTimeout=300000，否则驱动层自己先超时抛异常 - 注意
wait_timeout和interactive_timeout是空闲超时，和传输过程无关，别误调它们来“解决延迟”
PostgreSQL 的 tcp_keepalives_idle 在跨境链路中为什么必须设？
云厂商的 NAT 网关或中间防火墙，通常 5–15 分钟就会静默回收空闲 TCP 连接。跨境链路更易触发这种“假断连”：连接看起来还活着，但发包时才发现底层已失效，导致下一次查询直接报 server closed the connection unexpectedly。
实操建议：
- 必须设置
tcp_keepalives_idle=60（单位秒），配合tcp_keepalives_interval=10和tcp_keepalives_count=3，让连接在空闲 60 秒后主动探测 - 只设服务端参数没用——PostgreSQL 客户端（如
psycopg2）默认不开启 keepalive，需在连接字符串里加keepalives=1&keepalives_idle=60 - 不要依赖操作系统级
/proc/sys/net/ipv4/tcp_keepalive_time，容器或托管服务里不可控，且粒度太粗
Redis 跨区域主从同步延迟突增，repl-timeout 和 repl-ping-replica-period 怎么配才不脑裂？
主从跨地域部署时，网络延迟波动会让 Redis 误判从节点失联，过早触发 failover 或强制断连，造成写丢失或数据不一致。关键不是把超时设得“足够大”，而是让心跳探测频率和容忍窗口匹配真实 RTT 分布。
实操建议：
- 先用
redis-cli -h 主库 -p 6379 --latency测出 P99 延迟（比如 85ms），再把repl-ping-replica-period设为该值的 3–5 倍（如 300ms），避免频繁 ping 扰乱带宽 -
repl-timeout应 ≥repl-ping-replica-period × 3（如 900），留出重传和排队缓冲时间，但别超过 30 秒，否则主节点会长时间阻塞写入 - 禁用
min-replicas-to-write类强一致性配置——跨境链路无法稳定满足，强行启用只会让写请求大面积失败 - 监控
master_repl_offset - slave_repl_offset差值，比看connected_slaves更早发现同步积压
应用层重试遇到 Connection reset by peer，该重试还是该熔断？
这个错误在跨境数据库访问中高频出现，但它本身不区分是瞬时丢包、NAT 超时、还是服务端 OOM 杀进程。盲目重试会放大雪崩风险，简单熔断又可能错过真实可恢复故障。
实操建议：
- 仅对
Connection reset by peer+Broken pipe+EOF这三类底层 I/O 错误做**最多 1 次**重试，且必须换新连接（不能复用旧连接对象） - 对
timeout、read timeout、connect timed out等明确超时类错误，**禁止重试**——大概率是链路持续劣化，重试只是把压力传导给下游 - 在连接池层面记录每个 endpoint 的最近 5 次失败类型，若
Connection reset by peer出现 ≥3 次，自动降级到备用区域或返回缓存数据 - 别信“重试 3 次能解决 99% 问题”——跨境链路的失败模式是持续性而非瞬时性，重试逻辑必须带退避和上下文感知
跨境数据库的延迟不是靠堆参数能压下去的，真正要盯住的是每次失败背后的真实链路状态：是丢包？是 NAT 超时？还是服务端资源瓶颈？同一套配置，在新加坡到东京和法兰克福到圣保罗的表现可能差十倍。参数调得再细，没配套的链路指标采集，就只是在猜。
