MySQL5.7-InnoDB之数据还原

        天有不测风云，A公司的小明因最近股票大跌导致工作分心把公司某个MySQL数据库的数据给删了，给删了，给删了，挖槽，这可是S了祭天都无法回天的大事哈。

        这可把小明吓得成小青了，赶紧把这事告诉了老大王哥。

        王哥知道这事后，拍着小明的肩膀说，你这小子搞啥哦，我们不是有在做数据库的备份，赶紧把备份的还原一下。小明听完感觉活了过来，灰溜溜的赶紧把数据库的数据还原回来。

        以上的故事发生的情况不知道有没有在各位大佬的公司发生过。说实在的，数据库真的是公司的很宝贵的资产，如果对数据库做好备份工作，这真的S了祭天都没用的，许多知名的互联网公司都发生过类似的悲剧，还好他们凭自己的技术能力将损失降到最少。

        废话不多说了，咱们先进入正题，讲一讲MySQL InnoDB的日常是如何怎么样做数据还原的。

1、时间点还原（Point-in-Time Recovery）

        首先我们要启动MySQL 数据库之前先将binary logging 开启起来，这样MySQL就会将数据的变化都记录到log日志文件中，如果某天需要恢复某时间点上的数据就可以使用mysqlbinlog工具从我们的备份log文件中进行还原。例子：

基于时间点

[root@node1 log]# mysqlbinlog  mysqlbin.000026 --start-datetime='2018-11-13 17:15:50' --stop-datetime='2018-11-13 17:16:25' -r /opt/time.binlog
[root@node1 log]# grep update /opt/time.binlog 

基于位置点恢复

[root@node1 log]# mysqlbinlog  mysqlbin.000026  --start-position=406 --stop-position=523  -r /opt/pos.sql 

2、从损坏或磁盘故障中进行恢复数据

        我们在日常的运维过程中如果出现数据库的服务器有磁盘故障或者损坏的情况，我们通常会基于一个基本的备份进行还原，然后再通过使用mysqlbinlog或者mysql执行基于point-in-time从bin日志文件进行恢复到问题前的数据状态。

        有些情况我们会以为数据库某个表损坏了，就会对这些表进行dump，drop或者re-create的处理，但这是不科学的，MySQL 有个CHECK TABLE，这家伙可以帮我们检查这些表的情况，查看是否真损坏了，虽然这个CHECK TABLE不能完美的检查出损坏的情况，但这好过我们主观性判断。

        还有一些情况哈，我们看似数据库页文件损坏了但实际是我们的操作系统文件缓存有问题，而我们的数据还是ok的，只要重启一下服务器就行了。

        如果我们的MySQL出现因数据不一致性问题无法重启，我们可以通过Forcing InnoDB Recovery的以恢复模式启动实例。（具体可以了解一下Forcing InnoDB Recovery）。

3、InnoDB 崩溃恢复

        当我们的MySQL 服务意外退出了，我们只是重启一下MySQL服务就行了，这时候InnoDB 进行恢复还原操作自动检查日志而且还会执行前滚处理到当前状态。另外InnoDB 也会回滚一些崩溃前还未提交事务。

        下面是mysqld 显示在还原的状态输出的信息：

InnoDB: Log scan progressed past the checkpoint lsn 369163704
InnoDB: Doing recovery: scanned up to log sequence number 374340608
InnoDB: Doing recovery: scanned up to log sequence number 379583488
InnoDB: Doing recovery: scanned up to log sequence number 384826368
InnoDB: Doing recovery: scanned up to log sequence number 390069248
InnoDB: Doing recovery: scanned up to log sequence number 395312128
InnoDB: Doing recovery: scanned up to log sequence number 400555008
InnoDB: Doing recovery: scanned up to log sequence number 405797888
InnoDB: Doing recovery: scanned up to log sequence number 411040768
InnoDB: Doing recovery: scanned up to log sequence number 414724794
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up in
total 518425 row operations to undo
InnoDB: Trx id counter is 1792
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
...
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Rolling back trx with id 1511, 518425 rows to undo
...
InnoDB: Waiting for purge to start
InnoDB: 5.7.18 started; log sequence number 414724794
...
./mysqld: ready for connections.