恢复已删除ibdata1

最近我有一个客户删除InnoDB主表空间 - ibdata1 - 和重做日志 - ib_logfile *的情况。

MySQL使InnoDB文件始终保持打开状态。以下恢复技术基于此事实，它允许抢救数据库。

实际上，文件很久以前被删除 - 大约6个月左右。只要文件在物理上打开，它仍然会在文件系统中退出，并且可以访问已打开它的进程。

因此，从用户的角度来看，删除后没有任何变化。顺便说一句，这是监视这些文件存在的一个很好的理由！
但重启后InnoDB将检测到既没有系统表空间也没有日志文件，因此它将创建空的。InnoDB字典将为空，InnoDB将无法使用一堆现有的ibd文件。这种情况将是ibdconnect的工作，但只要MySQL没有重新启动，就可以快速恢复数据库。让我来说明一下。

让我们模拟一下事故。为此，我将删除/ var / lib / mysql / ib *文件，而sysbench生成读/写活动：

位于Screen0：

 

 

 

 

 

 

Shell

 

1 2 3 4 5 6 7 8 9 10 11 12 13

root@localhost:~# sysbench --num-threads=16 --max-requests=0 --test=oltp --oltp-table-size=1000000 --max-time=3600 --mysql-user=root run sysbench 0.4.12:  multi-threaded system evaluation benchmark   No DB drivers specified, using mysql Running the test with following options: Number of threads: 16   Doing OLTP test. Running mixed OLTP test Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases) Using "BEGIN" for starting transactions Using auto_inc on the id column Threads started!

屏蔽1：

 

 

 

 

 

Shell

 

1 2	root@localhost:/var/lib/mysql# rm ib* root@localhost:/var/lib/mysql#

现在文件已经消失，但MySQL仍在运行。它们不存在于/ var / lib / mysql中，但可以在/ proc文件系统中访问：

 

 

 

 

 

Shell

 

1 2 3 4

root@localhost:/var/lib/mysql# ls -la  /proc/14101/fd/ | grep -e ibdata -e ib_ lrwx------ 1 root  root  64 Aug  7 23:29 3 -> /var/lib/mysql/ibdata1 (deleted) lrwx------ 1 root  root  64 Aug  7 23:29 8 -> /var/lib/mysql/ib_logfile0 (deleted) lrwx------ 1 root  root  64 Aug  7 23:29 9 -> /var/lib/mysql/ib_logfile1 (deleted)

其中14101是mysqld进程的PID。

但是，我们无法将它们复制回来，因为在任何给定的时间点，缓冲池中都有修改过的页面。这些页面不会写入磁盘，如果未永久写入更改，则会丢失这些页面。这可能导致损坏和数据丢失。

出于同样的原因，我们不能通过复制文件来进行MySQL备份。

因此，我们必须确保所有修改都写入磁盘。

为此，我们必须停止任何进一步的写入并等待InnoDB刷新所有页面。

要停止写入活动，我们可以停止应用程序或锁定表：

 

 

 

 

 

Shell

 

1 2	mysql> flush tables with read lock; Query OK, 0 rows affected (0.37 sec)

现在让我们等到所有脏页都刷新到磁盘上。为此，我们将监测检查站的年龄。检查点年龄是当前日志序列号与“SHOW ENGINE INNODB STATUS”输出中的最后一个检查点之间的差异。如果检查点年龄为零，则刷新所有页面：

 

 

 

 

 

Shell

 

1 2 3 4 5 6 7

--- LOG --- Log sequence number 363096003 Log flushed up to   363096003 Last checkpoint at  363096003 Max checkpoint age    7782360

为了加快刷新速度，我们可以将脏页百分比设置为零：

 

 

 

 

 

Shell

 

1 2	mysql> ; Query OK, 0 rows affected (0.01 sec)

确保所有其他后台流程完成其工作也很重要。
其中之一是插入缓冲线程。它的大小不应超过1（它永远不会小于1）：

 

 

 

 

 

Shell

 

1 2 3 4

------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- , free list len 398, seg size 400,

后台写进程purge thread，清除所有事务。
它应该清除所有交易，直到最后

 

 

 

 

 

Shell

 

1 2 3 4 5

------------ TRANSACTIONS ------------ Trx id counter 0 16644 Purge done for trx's n:o < 0 16644 undo n:o < 0 0

但是如果最后一个事务不需要清除操作（例如SELECT），则Trx id计数器将更大。
在这种情况下，至少确保InnoDB没有进行任何写入：

 

 

 

 

 

Shell

 

1 2 3 4 5 6 7 8 9 10 11

FILE I/O -------- I/O thread 0 state: waiting for i/o request (insert buffer thread) I/O thread 1 state: waiting for i/o request (log thread) I/O thread 2 state: waiting for i/o request (read thread) I/O thread 3 state: waiting for i/o request (write thread) Pending normal aio reads: 0, aio writes: 0, ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 Pending flushes (fsync) log: 0; buffer pool: 0 332 OS file reads, 47 OS file writes, 32 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s

当刷新所有修改过的页面时，现在可以安全地复制InnoDB文件：

 

 

 

 

 

Shell

 

1 2 3

root@localhost:/var/lib/mysql# cp /proc/14101/fd/3 /var/lib/mysql/ibdata1 root@localhost:/var/lib/mysql# cp /proc/14101/fd/8 /var/lib/mysql/ib_logfile0 root@localhost:/var/lib/mysql# cp /proc/14101/fd/9 /var/lib/mysql/ib_logfile1

让我们修复所有者：

 

 

 

 

 

Shell

 

1 2	root@localhost:/var/lib/mysql# chown -R mysql ib* root@localhost:/var/lib/mysql#

并重启MySQL：

 

 

 

 

 

Shell

 

1	root@localhost:/var/lib/mysql# /etc/init.d/mysql restart

重启后，所有InnoDB表都可以访问：

 

 

 

 

 

Shell

 

1 2 3 4 5 6 7

mysql> select count(*) from sbtest; +----------+ | count(*) | +----------+ |  1000000 | +----------+ 1 row in set (0.19 sec)

结论

• 添加到您的监控系统检查InnoDB文件ibdata和ib_logfile *是否存在
• 在明确进一步恢复策略之前，请勿重新启动MySQL
• 结论：
  1.监控InnoDB文件 ibdata 和 ib_logfile* 是否存在
  2.清楚恢复策略，否则不要重启MySQLd