背景
生产库有三张表被开发清空，开发说是10点38清空的。三张表如下：
platform_goods_info
platform_goods_spec_info
platform_goods_image_info
需求：现在复盘先确认以下两个问题：
- 数据库在还原时是否有快捷的手段(比如只还原以上三张表的数据)
-
确认10点38的还原时间点是否正确
一、还原全量备份数据库
1.1还原基础库
[root@abc mnt]# gzip -d os20210306054301.sql.gz
[root@abc mnt]# du -sh os20210306054301.sql #库有5G还原起来比较费时
5.2G os20210306054301.sql
[root@abc mnt]# mysql -uroot -p123456 <os20210306054301.sql #官方也没有办法去分离备份表，除非预先做分离
#5G数据全量还原了18分钟，如果数据超过100G的话时间可能会延长至1小时
二、处理基础数据
参考文档：https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html
#备注：因为我这里知道有清空三张表，同时又知道具体清空的时间，所以比较好找位置点。基础库还原之后将3张表导出备份。
2.1实例开启远程连接
#可选操作
[root@abc tmp]# systemctl restart mysqld.service
CREATE USER 'root'@'%' IDENTIFIED BY '123456';
GRANT ALL ON *.* TO 'root'@'%';
flush privileges;
2.2工具导出
[
]
2.3本地备份
#可选操作，任选一种模式将基础表导出
[root@abc tmp]# mysqldump -uroot -p123456 os platform_goods_info > platform_goods_info.sql
[root@abc tmp]# mysqldump -uroot -p123456 os platform_goods_spec_info > platform_goods_spec_info.sql
[root@abc tmp]# mysqldump -uroot -p123456 os platform_goods_image_info > platform_goods_image_info.sql
#检查
[root@abc tmp]# du -sh ./*.sql
13M ./platform_goods_image_info.sql
8.9M ./platform_goods_info.sql
13M ./platform_goods_spec_info.sql
[root@abc tmp]# tail -200 ./platform_goods_spec_info.sql
三、增量还原
3.1拆分binlog
[root@abc mnt]# mysqlbinlog -vv --base64-output=decode-rows --start-datetime="2021-03-06 10:37:00" --stop-datetime="2021-03-06 10:38:59" mysql-bin.004226 >/tmp/check.sql
3.2查看删除信息
[root@abc mnt]# egrep -n "platform_goods_info|platform_goods_spec_info|platform_goods_image_info" /tmp/check.sql |more
[
]
#备注：可以看到行3809有删除操作
3.3分析位置点
[root@abc mnt]# sed -n '3800,3823p' /tmp/check.sql
[
]
#vi确认，大文件避免vim操作
[root@abc mnt]# vim /tmp/check.sql
[
]
3.3选择位置点
[root@abc mnt]# mysqlbinlog -vv --base64-output=decode-rows --stop-position="48778781" mysql-bin.004226 >/add.sql
3.4还原
[root@abc mnt]# mysql -uroot -p123456</add.sql
3.5查看数据
[root@abc mnt]# mysql -uroot -p123456 -e 'select count(*) from os.platform_goods_info'
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------+
| count(*) |
+----------+
| 29111 |
+----------+
[root@abc mnt]# mysql -uroot -p123456 -e 'select count(*) from os.platform_goods_spec_info'
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------+
| count(*) |
+----------+
| 31566 |
+----------+
[root@abc mnt]# mysql -uroot -p123456 -e 'select count(*) from os.platform_goods_image_info'
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------+
| count(*) |
+----------+
| 46323 |
+----------+
#数据表没有被删除证明增量位置相对正确，实际删除时间应该是10点36分
四、分析
- 这里有个细节，就是一开始我就知道我的binlog日志是哪些，因为我在全量备份的时候使用了参数–flush-logs，每次备份完毕后会在mysql-bin.004225的binlog日志基础上自增1
[root@abc mnt]# more os20210306054301.sql ... -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.004225', MASTER_LOG_POS=154; -
每次增量数据确实很难百分百确认数据完全还原成功，所以在人为删除表之后需要将业务停止。防止新增数据。
-
mysqldump备份的数据还原起来还是很慢的，数据量大的话可以尝试innobackupex方式进行备份还原
留言