如何实行MySQL句柄恢复的简单尝试
|
如何进行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里面就会包含进去。 commit [root@grtest s1]# 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 正常停库，启库。 这个时候验证数据就会发现，之前的那个事务已经做了回滚。 （编辑：银川站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
