误删数据

根据误删操作的类型，可以分为：

工具： Flashback 工具。
原理： 修改 binlog 内容，回放。
- insert -> Write_rows 改为 Delete_rows。
- delete -> Delete_rows 改为 Write_rows。
- update -> Update_rows，交换修改前后的值。
前提： binlog_format=row 和 binlog_row_image=FULL。
多个事务的恢复： 需要将事务执行顺序反过来。
安全恢复实践： 不要直接在主库上执行恢复操作！
- 恢复到一个备份或临时从库上执行恢复操作。
- 确认数据无误后再恢复回主库。
- 原因： 业务可能在误操作基础上继续修改数据，直接恢复可能造成二次破坏。

特点： 这三个命令在 binlog 中记录的是 statement 格式，无法用 Flashback 恢复。
恢复方法： 全量备份 + 增量日志（binlog）。
恢复流程 (mysqlbinlog 方法):
1. 取最近一次全量备份恢复出一个临时库。
2. 从日志备份中取出备份点之后的 binlog。
3. 应用 binlog 到临时库，跳过误操作的语句。
  - 非 GTID 模式： 使用 --stop-position 执行到误操作前，再用 --start-position 从误操作后继续执行。
  - GTID 模式： 使用 set gtid_next=误操作GTID;begin;commit; 将 GTID 加入临时库集合，自动跳过。
mysqlbinlog 方法的不足：
- 无法指定只解析某个表的日志。
- 应用日志过程单线程。
加速方法 (master-slave 方法):
1. 用备份恢复出临时实例。
2. 将临时实例设置成线上备库的从库。
3. 使用 CHANGE REPLICATION FILTER replicate_do_table = (tbl_name) 只同步误操作的表。
4. 利用并行复制技术加速恢复。
binlog 备份： 需要定期备份全量备份和 binlog，并根据成本设定 binlog 保留天数。
binlog 不足的补充： 如果备库已清理需要的 binlog，需要从 binlog 备份系统中下载并放回备库（修改 master.index 文件并重启）。
重要建议： 将数据恢复功能自动化，并经常演练。
- 提高恢复速度，减少损失。
- 避免手动操作失误造成二次伤害。

预防永远比事后补救更重要。

账号分离： 避免写错命令。
- 业务开发同学只给 DML 权限，不给 truncate/drop 权限 (DDL 通过管理系统)。
- DBA 日常使用只读账号，必要时才用更新权限账号。
制定操作规范： 避免写错要删除的表名。
- 删除前先对表进行改名（加固定后缀，如 _to_be_deleted）。
- 观察一段时间确保无影响。
- 通过管理系统执行删除，且管理系统只能删除特定后缀的表。
sql_safe_updates 参数： 设置为 on。
- 预防 delete 或 update 语句遗漏 where 条件或 where 条件未使用索引。
- 如果要删除小表全部数据，可以使用 where id >= 0，但性能较差，优先考虑 truncate 或 drop。
代码上线前 SQL 审计。
延迟复制备库： 对于核心业务，搭建延迟复制备库 (CHANGE MASTER TO MASTER_DELAY = N)。
- 主库误删操作在延迟时间内不会同步到延迟备库。
- 发现误操作后，停止延迟备库同步，跳过误操作命令，可以快速恢复出最新数据。