mysql主从复制不能代替日常备份，因其非离线静态副本，无法隔离误操作、不可校验、不可时间点恢复；可靠方案需全量备份+binlog归档+定期验证。
MySQL主从复制不能代替日常数据备份，因为它根本就不是备份——它只是另一份正在运行、实时同步的数据库副本。
主从复制无法隔离误操作
只要主库执行了 DROP DATABASE、TRUNCATE TABLE 或没加 WHERE 的 DELETE，从库会在几秒内原样重放。你没法“撤回”这个操作，也没法把从库临时切到只读状态来阻止（除非提前设了 read_only=1 且没被绕过）。而真正的备份是离线、静态、可校验的，误删后能按需恢复到任意时间点。
binlog 归档缺失导致增量链断裂
主从复制依赖主库的 binlog 持续推送，但这些日志默认不归档、不校验、不异地保存。常见坑包括：
-
expire_logs_days设为 7，但全量备份周期是 14 天 → 旧 binlog 被自动清理，中间变更无法还原 - 没配
log-bin路径权限，或和数据目录共用磁盘 → binlog 写失败却无告警，复制看似正常，实则日志早已停写 - 归档脚本没加锁、没检查文件大小、没校验
mysqlbinlog --base64-output=DECODE-ROWS -v输出 → 某天发现最近三天的mysql-bin.0000xx全是 0 字节
从库状态不可信，无法替代备份验证
从库的 Seconds_Behind_Master 可能长期显示 0，但实际已因 SQL 线程报错而卡住（比如主从表结构不一致、唯一键冲突）；或者中继日志损坏、relay-log.index 文件丢失，导致复制中断却不报警。你无法靠“从库还能查”来判断它是否真能用于恢复——而备份必须通过 mysqldump --apply-slave-statements 或 xtrabackup --prepare 显式验证才能入库。
真正可靠的方案，是把主从当作“快速切换通道”和“binlog 同步验证器”，再叠加每周一次全量备份 + 每日 binlog 归档，并定期用 mysqlbinlog 抽样检查归档内容。否则，主库一误删，从库跟着删，归档又断链，你就只剩备份日志里那句“上一次成功备份：14 天前”。
