如何利用MySQL半同步复制增强数据安全性_理解Ack应答机制与配置-mysql教程-PHP中文网

半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；关键在于ACK仅表示从库IO线程已将binlog写入relay log，而非SQL线程执行完成，且必须重启IO线程才能加载插件逻辑，插件名与MySQL版本严格匹配（8.0.26+用source/replica，旧版用master/slave），超时后自动降级为异步复制，需监控降级次数而非仅看状态是否ON。

如何利用mysql半同步复制增强数据安全性_理解ack应答机制与配置

半同步复制不能防止所有数据丢失，但能显著降低主库宕机时未同步事务丢失的概率；关键在于理解 ACK 是从库 IO 线程写入 relay log 后发出的信号，不是执行完成、也不是网络收到就确认。

为什么 SHOW STATUS LIKE 'Rpl_semi_sync_slave_status' 一直为 OFF

这是最常遇到的“配置成功但不生效”问题。根本原因不是插件没装，而是从库 IO 线程压根没加载半同步逻辑。

仅执行 SET GLOBAL rpl_semi_sync_slave_enabled = 1 不触发加载 —— 插件只在 IO 线程启动时初始化
必须显式重启线程：STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
检查 SELECT @@plugin_dir; 确认 semisync_replica.so（8.0.26+）或 semisync_slave.so（≤8.0.25）文件真实存在
防火墙可能拦截了 ACK 包：主库 3306 端口需允许从库 IP 的 双向 TCP ACK 流量，不只是初始连接

INSTALL PLUGIN 失败：插件名与 MySQL 版本强绑定

MySQL 8.0.26 是分水岭，插件名和 SO 文件名全部变更，混用必报错或状态始终 OFF。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

MySQL 8.0.26 及以上：INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so' + INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so'
MySQL 5.7–8.0.25：INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so' + INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'
执行 SHOW PLUGINS LIKE '%semi%'，确认 Status 列为 ACTIVE 且 Type 是 SEMISYNCHRONOUS_REPLICATION
SO 文件名大小写敏感，Linux 下是 .so，macOS 是 .dylib，不可硬套

rpl_semi_sync_source_wait_point 决定“已提交即已落盘”的边界

这个变量控制主库在事务生命周期哪个节点等待 ACK，直接决定崩溃后能否找回已提交事务。

AFTER_SYNC（5.7+ 默认）：主库写完 binlog → 等 ACK → 再提交 → 崩溃后，所有已提交事务一定存在于至少一个从库 relay log 中
AFTER_COMMIT（5.5/5.6 默认）：主库先提交 → 再等 ACK → 崩溃时，已提交但未发出去的事务会丢失
务必在主库执行：SET GLOBAL rpl_semi_sync_source_wait_point = 'AFTER_SYNC'；该设置对后续事务生效，不影响当前正在运行的事务
它不改变超时行为，也不影响 rpl_semi_sync_source_timeout，但划清了数据安全底线

超时降级不是故障恢复，而是掩盖网络或从库 IO 延迟

Rpl_semi_sync_source_status 在超时后自动变为 OFF，看起来“还能用”，但实际已退化为异步复制 —— 这个状态本身不会报警，容易被忽略。

监控重点不是 Rpl_semi_sync_source_status 是否为 ON，而是 Rpl_semi_sync_source_no_tx（降级次数）和 Rpl_semi_sync_source_timeouts（超时次数）是否持续增长
频繁降级大概率说明：从库 relay log 写入慢（磁盘 I/O 瓶颈）、主从网络 RTT > rpl_semi_sync_source_timeout、或从库 IO 线程卡在某个 event 上
不要把 rpl_semi_sync_source_timeout 设为 0（永不降级）—— 主库事务会无限阻塞，业务直接雪崩
ACK 不代表数据已执行，只代表 relay log 落盘；SQL 线程延迟仍可能导致从库数据“可见滞后”