首页 > mysql教程 > 正文

MySQL句柄恢复文件的简单尝试

转载 2019-02-11 0 2

原标题:MySQL句柄恢复文件的简单尝试

今天突然想起一个问题,那就是对于ibdata的恢复,如果我们简单模拟一下,就会发现还是蛮有意思的。

首先我们得到两个参数值,一个是刷脏页的指标,另外一个是数据文件的目录。

mysql> show variables like '%pct%';

+------------------------------------------+-----------+

| Variable_name | Value |

+------------------------------------------+-----------+

| innodb_buffer_pool_dump_pct | 25 |

| innodb_compression_failure_threshold_pct | 5 |

| innodb_compression_pad_pct_max | 50 |

| innodb_max_dirty_pages_pct | 75.000000 |

| innodb_max_dirty_pages_pct_lwm | 0.000000 |

| innodb_old_blocks_pct | 37 |

+------------------------------------------+-----------+

6 rows in set (0.01 sec)

mysql> show variables like 'datadir';

+---------------+----------------+

| Variable_name | Value |

+---------------+----------------+

| datadir | /home/data/s1/ |

+---------------+----------------+

1 row in set (0.00 sec)

这个时候的文件是下面的几个:

[root@grtest s1]# ll ib*

-rw-r----- 1 mysql mysql 413 Jun 20 14:01 ib_buffer_pool

-rw-r----- 1 mysql mysql 12582912 Jun 20 14:01 ibdata1

-rw-r----- 1 mysql mysql 50331648 Jun 20 14:01 ib_logfile0

-rw-r----- 1 mysql mysql 50331648 Jun 20 14:01 ib_logfile1

-rw-r----- 1 mysql mysql 12582912 Jun 20 14:02 ibtmp1

其中,ib_buffer_pool是5.7的新特性,暂时没有用到,两个redo日志,一个临时文件。

我们可以测试一下破坏的情况,同时和事务结合起来。

mysql> create database test;

Query OK, 1 row affected (0.00 sec)

mysql> use test

Database changed

mysql> create table test(id int);

Query OK, 0 rows affected (0.01 sec)

手工开启一个事务,但是不提交。

mysql>start transaction;

Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values(1000);

Query OK, 1 row affected (0.01 sec)

这个时候没有commit,所以查看binlog里面目前是没有匹配记录的。

# mysqlbinlog -vv binlog.000001 |grep -i INSERT

而一旦提交之后,binlog里面就会包含进去。

SQL>commit

# mysqlbinlog -vv binlog.000001 |grep -i -a5 INSERT

BINLOG '

UZNjWRPhYAAAKwAAABIHAAAAANsAAAAAAAEABHRlc3QABHRlc3QAAQMAAQ==

UZNjWR7hYAAAJAAAADYHAAAAANsAAAAAAAEAAgAB//7oAwAA

'/*!*/;

### INSERT INTO `test`.`test`

### SET

### @1=1000 /* INT meta=0 nullable=1 is_null=0 */

# at 1846

#170710 22:47:11 server id 24801 end_log_pos 1873 Xid = 477

COMMIT/*!*/;

我们来验证一下这种破坏场景下的数据情况,插入一条记录,不提交,然后破坏文件,查看恢复的情况。

mysql> start transaction;

Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values(2000);

Query OK, 1 row affected (0.00 sec)

我们就把这些ib_字样的文件删除了。

查看mysqld的pid,发现测试环境中有大量的同类服务。

# pidof mysqld

30518 29944 29698 29401 15307 10659

所以我们换一个姿势。# netstat -nltp|grep mysqld|grep 24801

tcp 0 0 :::24801 :::* LISTEN 29401/mysqld

在系统目录下,按照规律会发现下面的文件。

# ll /proc/29401/fd|grep ib_*|grep delete

lrwx------ 1 root root 64 Jul 10 22:49 10 -> /home/data/s1/ib_logfile1 (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 11 -> /home/data/s1/ibtmp1 (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 12 -> /tmp/ibHcflkp (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 4 -> /home/data/s1/ibdata1 (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 5 -> /tmp/ibq7lvQK (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 6 -> /tmp/ib59bGj5 (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 7 -> /tmp/ibYubRMp (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 8 -> /tmp/ib8LAUL4 (deleted)

lrwx------ 1 root root 64 Jul 10 22:49 9 -> /home/data/s1/ib_logfile0 (deleted)

我们做两件事情,一件是给当前的环境上锁,然后进行文件的拷贝。

[root@grtest s1]# chown mysql:mysql xxxx

[root@grtest s1]# mv 10 /home/data/s1/ib_logfile1

[root@grtest s1]# mv 11 /home/data/s1/ibtmp1

[root@grtest s1]# mv 9 /home/data/s1/ib_logfile0

[root@grtest s1]# mv 4 /home/data/s1/ibdata1

正常停库,启库。

这个时候验证数据就会发现,之前的那个事务已经做了回滚。

mysql> select *from test;

+------+

| id |

+------+

| 1000 |

+------+

1 row in set (0.01 sec)

所以这一点上,句柄层级的恢复和之前自己在oracle下的句柄恢复情况很类似。

相关文章


  • 案例丨教育行业MySQL数据库加密安全实践
  • mysql 数据库中的三种判断是否包含总结
  • zblog写作:ms-sql和mysql数据库哪个更加实用?
  • JDBC 之:MySQL 以及相关软件的使用基础
  • mysql和Oracle获取数据库的图片的差异
  • linux运维之mysql连接报ERROR 1042
  • 推荐一款稳定、高效的MySQL数据库备份利器
  • MySQL从零开始:04 表的增删改查(一)
  • 作者信息