防范从库误删需三重保障：一是强制只读（read_only+super_read_only）、权限回收与元数据表存储；二是访问隔离（堡垒机、proxysql拦截）；三是保留回档能力（延迟从库、row格式binlog、完整日志保留）及操作闭环（审计、工单、校验与演练）。
从库数据意外删除，往往不是复制机制本身出问题，而是人为操作或配置疏漏导致的。防范重点不在“阻止复制”，而在于让从库真正成为只读、可信赖、可回档的副本。
强制从库只读并锁定元数据
仅靠 read_only = ON 不够——它不阻止 SUPER 权限用户写入，也不禁用 DDL（如 DROP TABLE）。必须组合使用：
- 设置
read_only = ON，并确保所有运维账号不持有 SUPER 权限； - 显式收回普通账号在从库上的
DROP、TRUNCATE、ALTER权限，例如：REVOKE DROP, TRUNCATE, ALTER ON prod_db.* FROM 'ops'@'%'; - 启用
super_read_only = ON（MySQL 5.7+），该参数会阻止包括 SUPER 用户在内的任何写操作（除 SET 命令外），重启后仍生效； - 将复制元数据存入表而非文件：
relay_log_info_repository = TABLEmaster_info_repository = TABLE
避免因文件损坏导致复制状态丢失或误跳过事件。
切断直接删库路径
从库被误删，90% 发生在人直接登录后执行命令。必须从访问层隔离：
- 生产从库禁止开放给开发/运维人员直连，只允许 DBA 或自动化平台账号访问；
- DBA 登录从库时，强制通过堡垒机，并启用双因素认证与 IP 白名单；
- 客户端工具（如 MySQL Shell、mycli）配置默认连接地址为测试库；生产从库连接串命名含
_slave_ro后缀，视觉上强化“只读”认知； - 在从库上部署 ProxySQL 或 MaxScale，对匹配
^DROP|^TRUNCATE|^DELETE FROM [^ ]+$的语句直接拦截并返回错误，不转发到后端。
保留回档能力：延迟从库 + 完整 binlog
即使从库被删，只要主库完好且日志完整，就能重建。关键配置不能妥协：
- 部署至少一台 延迟从库（如
CHANGE REPLICATION SOURCE TO SOURCE_DELAY = 3600;），人为误删后有 1 小时窗口回退； - 主库开启
binlog_format = ROW，且确认已持久化（查SELECT @@binlog_format;，并在 my.cnf 中配置）； - 主库设
sync_binlog = 1和innodb_flush_log_at_trx_commit = 1，确保事务提交即落盘，断电不丢 binlog； - 从库开启
relay_log_recovery = ON，重启时自动修复中断的 relay log，避免因宕机导致复制跳过部分事件； - binlog 保留时间不少于 7 天（
expire_logs_days = 7），并关闭普通账号的PURGE BINARY LOGS权限。
操作闭环：审计 + 快照 + 工单
技术手段防不住所有风险，流程闭环才能兜底：
- 启用 audit_log 插件或企业版审计日志，记录所有连接、查询、权限变更，日志实时推送至 ELK；
- 对从库执行任何 DML/DDL 操作前，必须走工单系统，附带：
• 执行语句原文
• 对应的 SELECT 验证语句及结果行数快照
• 回滚语句（如适用）
• 审批人签字与时间戳； - 定期（每月）用
pt-table-checksum校验主从数据一致性，发现差异立即告警； - 每季度对延迟从库做一次模拟误删演练：手动删表 → 从延迟位点恢复 → 验证业务可用性。
