如何利用MySQL复制功能实现数据库的异地灾备_配置压缩协议减少公网带宽-mysql教程-PHP中文网

mysql 8.0+主从复制启用zstd压缩需在change master to中显式指定compression_algorithm='zstd'和compression_level=3，并强制启用master_ssl=1；仅服务端配置无效，且须配合心跳、半同步及max_allowed_packet调优才能真正提升公网复制稳定性。

如何利用mysql复制功能实现数据库的异地灾备_配置压缩协议减少公网带宽

MySQL 8.0+ 主从复制启用 zstd 压缩协议

跨公网部署主从时，不加压缩的 binlog 传输极易打满带宽，尤其当主库写入频繁、含大量 JSON 或文本字段时。MySQL 8.0.21 起原生支持 COMPRESSION_ALGORITHM 和 COMPRESSION_LEVEL，比旧版 slave_compressed_protocol = ON 更可控、更高效。

在从库执行 CHANGE MASTER TO 时必须显式指定压缩参数，仅靠服务端配置无效：

CHANGE MASTER TO
  MASTER_HOST='master-public-ip',
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_PORT=3306,
  MASTER_SSL=1,
  COMPRESSION_ALGORITHM='zstd',
  COMPRESSION_LEVEL=3;

zstd 是目前最优选：相比 zlib，同等压缩率下 CPU 开销低 30–40%，ARM 架构（如 AWS Graviton）上优势更明显
COMPRESSION_LEVEL=3 是平衡点；设为 1 太弱（压缩率 ~1.2x），设为 9 则 CPU 升高但收益不明显（压缩率仅再提升 5–8%）
必须搭配 MASTER_SSL=1 —— 公网环境不启 SSL，压缩参数会被忽略（MySQL 内部校验逻辑）
执行后需 START SLAVE，且 SHOW SLAVE STATUS\G 中的 Compression_algorithm 字段要显示 zstd 才算生效

为什么开了压缩，Seconds_Behind_Master 反而变大？

常见错觉是“压缩=更快”，实际它只减少字节量，不缩短单次网络 RTT，还引入解压开销。若配置不当，反而拖慢从库同步速度。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

从库 max_allowed_packet 小于解压后日志包大小 → 连接静默断开，错误日志里只有 Lost connection to MySQL server during query，不会提示压缩相关
建议值：按主库典型事务 binlog 大小 × 1.5 设定，例如主库最大事务生成 8MB binlog，则从库设 SET GLOBAL max_allowed_packet = 12582912
压缩对高熵数据无效甚至膨胀：已 base64 的字段、UUID、加密 token 等，COMPRESS() 后可能变大 3–5%，这类数据多时压缩率会跌到 0.9+（查 SHOW STATUS LIKE 'Compression%' 确认）
监控关键指标：Compression_rate 持续低于 0.25，说明收益极小，应关闭压缩或改用业务层过滤（如只同步核心表）

压缩只作用于复制流量，不影响客户端连接

很多人混淆「复制压缩」和「客户端连接压缩」，以为配了 COMPRESSION_ALGORITHM 就自动给所有应用连上也压缩。不是这样。

COMPRESSION_ALGORITHM 仅控制 IO Thread 从主库拉取 binlog 的链路，与应用连从库查数据完全无关
应用要压缩结果集，得单独配置：JDBC 加 &useCompression=true，pymysql 传 compress=True，mysql 命令行用 --compress
两类压缩互不干扰，但共用同一台从库的 CPU —— 若同时开启且并发高，mysqld 的 %CPU 可能飙到 90%，此时需限制 slave_parallel_workers 或降级压缩等级
真正省带宽的是复制链路；客户端压缩只影响应用到从库这最后一跳，对异地灾备整体带宽占用贡献很小

压缩 + 半同步 + 心跳调优，三者必须协同

单纯开压缩不能解决异地灾备的抖动中断问题。公网链路不稳定时，IO Thread 容易假死，导致 Seconds_Behind_Master 突增，甚至主从失联。

必须配心跳：CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10.0（单位秒），避免网络短暂抖动触发重连风暴
必须启半同步：INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'，并设 rpl_semi_sync_master_enabled = ON，防止主库提交后因从库未收到就返回成功
压缩与半同步不冲突，但要注意：半同步等待时间（rpl_semi_sync_master_timeout）要大于压缩 + 网络 RTT 的总耗时，否则容易超时退化为异步
真实案例：北京→广州链路平均 RTT 50ms，zstd 压缩平均耗时 8ms，建议 rpl_semi_sync_master_timeout 至少设为 1000（1 秒），留足余量

压缩不是银弹，它只解决“字节数”问题；延迟、抖动、可靠性得靠心跳、半同步、监控告警一起兜底。线上压测时，务必用真实 binlog 流量跑 24 小时，看 Compression_rate 和 Seconds_Behind_Master 是否稳定在预期区间。