一、备份资源
二、处理流程
2.1全量数据库导入
[root@mysql_sys ~]# gzip -d os20180411.sql.gz //解压,在全量数据库导入至本地mysql中
[root@mysql_sys ~]# mysql -uroot -p < os20180411.sql //导入库，可以查看到对应数据条目
2.2拆分binlog日志
#备注：这里一定要先问故障发生时间，先通过时间进行截取，找个时间点先把数据恢复一部分
[root@mysql_sys ~]# mysqlbinlog -d os mysql-bin.000015 --stop-datetime="2018-04-10 16:00:00" > new.sql
[root@mysql_sys ~]# sed -n "/customer_order_info/,/;/p" new.sql |sed 's#\/\*!\*\/##' > new_1.sql
#备注：先把故障前的SQL给提取出来，不然没法去看，将这个时间段的该表信息提取出来
2.3增量sql导入
#备注：这里压力是最大的一定要选对pos点，不然前功尽弃，因为全量sql导入成功也是非常耗时的，如果sql量大的话
[root@mysql_sys ~]# mysql -uroot -f os -p < new_1.sql
2.4校验数据
三、总结
- 通过mysqldump备份的数据包随着量的增大全量还原就越来越耗时，sql大的话可以考虑XtraBackup
- 通过mysqlbinlog查找位置点是个胆大心细的过程，在这个阶段会耗费大量时间和精力去做判断
- 一般误删数据都是由于开发人员将表进行了delete(不排除开发update没带where条件)，线上应杜绝开发直接有权限去drop、delete操作(有些公司不规范，开发不肯让出这部分权限出来)
- 业务数据库用户权限最好只有select、insert、update权限(不授权drop与delete)，这样在拍错pos故障点的时候能够非常快的定位到位置点(如果是通过drop或者delete误删的表或数据的话)
- 整个业务线在还原的过程中开发和运维都处于高压力状态下(因为涉及还原的话业务全部停止运行，每一分钟都是煎熬)，所以平时要从小抓起让开发直接或间接操作数据库的时候有反复确认三遍再回车的意识(有些公司开发是可以直接操作生成sql的，这是个问题但也避免不了)，防微杜渐
留言