全量同步卡在RDB传输中途且master_sync_left_bytes下降极慢，根本原因常是中间设备（防火墙/安全组/负载均衡）拦截或重组TCP分包，而非带宽不足；需抓包分析重传、检查MTU一致性、禁用SACK、调大repl-timeout与TCP keepalive，并排查conntrack表溢出及云厂商SLB超时设置。
全量同步卡在 RDB 传输中途，master_sync_in_progress 长时间为 1 且 master_sync_left_bytes 下降极慢
这不是网络带宽不足的典型表现，而是 TCP 分包被中间设备（如防火墙、云厂商安全组、负载均衡器）拦截或重组失败导致的。Redis 主节点通过 socket 直接流式发送 RDB 文件，一旦某次 TCP segment 被丢弃或延迟超时，整个传输会卡住——因为 Redis 没有重传机制，也不做应用层分块校验。
实操建议：
- 在主节点抓包验证：
tcpdump -i any port 6379 -w redis-sync.pcap，然后在从节点触发同步，用 Wireshark 打开 pcap，过滤tcp.stream eq 0，观察是否有大量 retransmission、duplicate ACK 或 zero window - 检查链路两端 MTU 是否一致：在主、从节点分别执行
ip link show | grep mtu；跨云厂商或混合云场景下，常见主节点 MTU=1500，但中间防火墙只允许 1400 或 1300 的 IP 包通过，导致 TCP 分片后被丢弃 - 临时绕过防火墙测试：在主节点执行
redis-cli CONFIG SET repl-diskless-sync yes（启用无盘同步），再重启从节点连接——若此时同步变快，基本锁定是防火墙对大包的拦截行为
Background transfer terminated by signal 10 错误频繁出现
Signal 10 是 SIGUSR1，Redis 主进程收到该信号会强制终止当前 bgsave 或 RDB 传输。它通常不是人为发送的，而是内核或中间设备因“异常包”向进程发的中断信号——比如防火墙检测到 TCP 校验和错误、IP 分片不完整、或 TLS 插件（如有）解密失败后 fallback 触发的清理动作。
实操建议：
- 确认是否启用了任何网络中间件：如 Istio sidecar、云厂商的“智能网关”、WAF、或自研代理。这类组件常默认开启 TCP 优化（如 segment 合并、乱序重排），与 Redis 的 raw socket 流式传输不兼容
- 禁用 TCP 优化项（需 root 权限）：
echo 0 > /proc/sys/net/ipv4/tcp_sack和echo 0 > /proc/sys/net/ipv4/tcp_dsack，再试同步——SACK 机制在分包异常时易引发信号中断 - 检查系统日志：
dmesg -T | grep -i "segfault\|drop\|firewall"，看是否有内核级丢包或模块拦截记录
从节点 INFO replication 显示 master_link_status:down，但 ping 和 telnet 均通
Telnet 只验证 TCP 三次握手成功，不代表应用层数据能稳定收发。Redis 主从同步依赖长连接持续写入，而某些状态防火墙（尤其是企业级 NGFW）会基于“连接空闲时间”或“单包大小阈值”主动 reset 连接，表现为：telnet 瞬间通，但 redis-cli -h master -p 6379 PING 偶尔超时，INFO replication 中 master_last_io_seconds_ago 突然跳到 60+ 秒（触发 repl-timeout 断连）。
实操建议：
- 调大
repl-timeout：主节点执行CONFIG SET repl-timeout 600，避免因短暂 IO 卡顿被误判断连 - 启用 TCP keepalive：
echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time（60 秒后开始探测）、echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl（每 10 秒探一次）、echo 6 > /proc/sys/net/ipv4/tcp_keepalive_probes（连续 6 次失败才断） - 在防火墙策略中显式放行 Redis 复制流量：协议选 TCP，端口为 Redis 主节点端口，连接状态设为 “ESTABLISHED,RELATED”，并关闭“深度包检测（DPI）”或“应用识别”功能
为什么改 MTU 不一定能彻底解决问题？
MTU 是链路层限制，但 Redis 全量同步卡顿的根因常在更高层：防火墙的连接跟踪表（conntrack）溢出、NAT 设备对长连接的 timeout 设置过短、或云厂商 SLB 的“健康检查间隔”与 Redis 心跳冲突。单纯把 MTU 从 1500 改成 1400，可能只是让原本被丢弃的包变成被截断，反而引发更多重传和超时。
真正要盯住的是三个数字：
-
net.netfilter.nf_conntrack_max：检查 conntrack 表是否打满（conntrack -L | wc -l对比该值） -
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established：默认常为 432000 秒（5 天），但某些云环境会改成 300 秒，导致主从连接被提前回收 -
repl-timeout与tcp_keepalive_time的关系：后者必须显著小于前者，否则 keepalive 探测来不及触发就已断连
这些参数不显眼，却决定着全量同步能否安静跑完——而不是在最后 10% 时突然静默卡死。
