Home > database > 换一种方式来解决问题

换一种方式来解决问题

周五收到开发同学通知,由于程序bug导致误更新了用户的数据,需要将21号的数据拿出来分析,然后重新插入进去。当时就咨询了苏普同学,问问他们该怎么恢复,由于我们数据采用的是xtrabackup方式来备份数据,在恢复数据的时候需要将备份数据拷贝到另外一台机器上,在把数据还原出来。但是不幸的是我们的备份有问题,苏普同学恢复了两次也没有恢复成功,难道真的要面临数据丢失了吗,开发同学不停的在旺旺上问恢复好没有,在这个时候你能说我们的备份有问题吗,不能!

这个时候突发想到了开发同学在给我用户id查看更新后数据的时候,发现该记录的创建时间和更新时间分别为:

root@dc_pages_bak 06:06:37>select gmt_created,gmt_modified
->   from tfs_0007
->  where user_id = 217101303
->    and gmt_created <= ‘2011-4-23’
->    and gmt_created >= ‘2011-4-19’;
+———————+———————+
| gmt_created         | gmt_modified        |
+———————+———————+
| 2011-04-21 17:29:39 | 2011-04-22 18:01:21 |
该用户的记录是在4-22号被更新的,但是创建时间是在4-21,这个时候仿佛看到了曙光,因为今天4-22,那么昨天做的插入在binlog中还有保留的一份的吧,我们的binlog保留的时间为一周,于是找到备份目录中在4-21 ,17点30左右的binlog,然后用mysqlbinlog分析日志,找到插入的语句;在分析了两份binlog后,终于找到了21号插入的这条数据:

INSERT INTO tfs_0007 (user_id, *,*,*,*,gmt_created, gmt_modified)

VALUES (217101303, *,*,*,*,now(),now());

数据找到了,换另一种方式来解决问题,虽然有一定的局限性,但是成功了如果早一点想到该办法,也不会给用户带来那么多的不爽的体验;

至于为什么我们的xtrabackup为什么恢复会出现问题,还需要和苏普他们确认一下,这个问题不小啊。

Categories: database Tags:
  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.