记录一下基于docker-composer的mysql环境下进行误删除数据恢复的步骤
线上系统使用这样的cron规则1
0 6 * * * cd /docker-compose/mysql && docker-compose exec -T mysql mysqldump -A -F --triggers --routines --events > backup/$(date '+\%u').sql
-F, --flush-logs切换到下一个binlog文件，这样全量备份的时候flush binlog，在要恢复数据的时候，start-time或者position不用找也不用填--triggers --routines --events不加的话会在导出的文件里第一行有一条警告信息0 6 * * *每天凌晨6点$(date '+\%u')返回今天周几（1-7）（在crontab里面百分比符号%需要转义）
停机，停止业务
防止恢复期间产生新的数据，然后在数据恢复后丢失了这部分新数据
找到出错的sql pos
- 记录下错误sql执行的时间
- 执行
show master status\G;查看当前binlog文件名 - 执行
mysqlbinlog --base64-output=decode-rows -v --start-datetime='2019-08-09 06:00:00' --stop-datetime='2019-08-09 11:37:00' mysql-bin.003526 | grep 'INSERT' -A50这样的命令通过时间段和sql的关键字匹配出出错sql的position
其中2019-08-09 06:00:00是你全量备份的时间点，2019-08-09 11:37:00是你出错sql执行的时间
输出信息中sql语句下面的# at 4304726就是position了 - 然后你就得到了用来恢复的命令
恢复数据
- 新建一个空的mysql实例
- 导入一个最近的全量备份
- 将binlog文件拷贝到新实例内
- 执行
mysqlbinlog --base64-output=decode-rows -v --start-datetime='2019-08-09 06:00:00' --stop-position=4304726 mysql-bin.003526 | mysql来恢复全量备份到错误sql之间的数据
启动系统
数据恢复完毕，此时可以选择两种方案
- 将恢复的表导入到老的mysql实例
- 直接将项目中的mysql连接信息改到新的mysql实例
如果是docker-compose的话，两种都随便，怎么省事怎么来，因为使用docker-compose构建的mysql实例都是一致的，没有任何差异，用新的用老的都一样。