MySQL如何恢复单库或单表,以及可能遇到的坑

2023-07-14 10:36:03 198

前言：

MySQL逻辑备份工具最常用的就是mysqldump了，一般我们都是备份整个实例或部分业务库。不清楚你有没有做过恢复，恢复场景可能就比较多了，比如我想恢复某个库或某个表等。那么如何从全备中恢复单库或单表，这其中又有哪些隐藏的坑呢？这篇文章我们一起来看下。

1.如何恢复单库或单表

前面文章有介绍过MySQL的备份与恢复。可能我们每个数据库实例中都不止一个库，一般备份都是备份整个实例，但恢复需求又是多种多样的，比如说我想只恢复某个库或某张表，这个时候应该怎么操作呢？

如果你的实例数据量不大，可以在另外一个环境恢复出整个实例，然后再单独备份出所需库或表用来恢复。不过这种方法不够灵活，并且只适用数据量比较少的情况。

其实从全备中恢复单库还是比较方便的，有个--one-database参数可以指定单库恢复，下面来具体演示下：

#查看及备份所有库
mysql>showdatabases;
+--------------------+
|Database|
+--------------------+
|information_schema|
|mysql|
|performance_schema|
|sbtest|
|sys|
|testdb|
|testdb2|
+--------------------+

mysqldump-uroot-pxxxx-R-E--single-transaction--all-databases>all_db.sql

#删除testdb库并进行单库恢复
mysql>dropdatabasetestdb;
QueryOK,36rowsaffected(2.06sec)

#貌似恢复前testdb库不存在的话要手动新建
mysql-uroot-pxxxx--one-databasetestdb
除了上述方法外，恢复单库或单表还可以采用手动筛选的方法。这个时候Linux下大名鼎鼎的sed和grep命令就派上用场了，我们可以利用这两个命令从全备中筛选出单库或单表的语句，筛选方法如下：
#从全备中恢复单库
sed-n'/^--CurrentDatabase:`testdb`/,/^--CurrentDatabase:`/p'all_db.sql>testdb.sql

#筛选出单表语句
catall_db.sql|sed-e'/./{H;$!d;}'-e'x;/CREATETABLE`test_tb`/!d;q'>/tmp/test_tb_info.sql
catall_db.sql|grep--ignore-case'insertinto`test_tb`'>/tmp/test_tb_data.sql
 2.小心有坑
对于上述手动筛选来恢复单库或单表的方法，看起来简单方便，其实隐藏着一个小坑，下面我们来具体演示下：
#备份整个实例
mysqldump-uroot-pxxxx-R-E--single-transaction--all-databases>all_db.sql

#手动备份下test_tb然后删除test_tb
mysql>createtabletest_tb_bakliketest_tb;
QueryOK,0rowsaffected(0.03sec)

mysql>insertintotest_tb_bakselect*fromtest_tb;
QueryOK,4rowsaffected(0.02sec)
Records:4Duplicates:0Warnings:0

mysql>droptabletest_tb;
QueryOK,0rowsaffected(0.02sec)

#从全备中筛选test_db建表及插数据语句
catall_db.sql|sed-e'/./{H;$!d;}'-e'x;/CREATETABLE`test_tb`/!d;q'>test_tb_info.sql
catall_db.sql|grep--ignore-case'insertinto`test_tb`'>test_tb_data.sql

#查看得到的语句貌似没问题
cattest_tb_info.sql

DROPTABLEIFEXISTS`test_tb`;
/*!40101SET@saved_cs_client=@@character_set_client*/;
/*!40101SETcharacter_set_client=utf8*/;
CREATETABLE`test_tb`(
`inc_id`int(11)NOTNULLAUTO_INCREMENTCOMMENT'自增主键',
`col1`int(11)NOTNULL,
`col2`varchar(20)DEFAULTNULL,
`col_dt`datetimeDEFAULTNULL,
`create_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'创建时间',
`update_time`timestampNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'修改时间',
PRIMARYKEY(`inc_id`)
)ENGINE=InnoDBAUTO_INCREMENT=5DEFAULTCHARSET=utf8COMMENT='测试表';
/*!40101SETcharacter_set_client=@saved_cs_client*/;

cattest_tb_data.sql

INSERTINTO`test_tb`VALUES(1,1001,'dsfs','2020-08-0412:12:36','2020-09-1706:19:27','2020-09-1706:19:27'),
(2,1002,'vfsfs','2020-09-0412:12:36','2020-09-1706:19:27','2020-09-1706:19:27'),
(3,1003,'adsfsf',NULL,'2020-09-1706:19:27','2020-09-1706:19:27'),
(4,1004,'walfd','2020-09-1714:19:27','2020-09-1706:19:27','2020-09-1807:52:13');

#执行恢复单表操作
mysql-uroot-pxxxxtestdbselect*fromtest_tb;
+--------+------+--------+---------------------+---------------------+---------------------+
|inc_id|col1|col2|col_dt|create_time|update_time|
+--------+------+--------+---------------------+---------------------+---------------------+
|1|1001|dsfs|2020-08-0412:12:36|2020-09-1706:19:27|2020-09-1706:19:27|
|2|1002|vfsfs|2020-09-0412:12:36|2020-09-1706:19:27|2020-09-1706:19:27|
|3|1003|adsfsf|NULL|2020-09-1706:19:27|2020-09-1706:19:27|
|4|1004|walfd|2020-09-1714:19:27|2020-09-1706:19:27|2020-09-1807:52:13|
+--------+------+--------+---------------------+---------------------+---------------------+
4rowsinset(0.00sec)

mysql>select*fromtest_tb_bak;
+--------+------+--------+---------------------+---------------------+---------------------+
|inc_id|col1|col2|col_dt|create_time|update_time|
+--------+------+--------+---------------------+---------------------+---------------------+
|1|1001|dsfs|2020-08-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|2|1002|vfsfs|2020-09-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|3|1003|adsfsf|NULL|2020-09-1714:19:27|2020-09-1714:19:27|
|4|1004|walfd|2020-09-1714:19:27|2020-09-1714:19:27|2020-09-1815:52:13|
+--------+------+--------+---------------------+---------------------+---------------------+
4rowsinset(0.00sec)
如果你仔细观察的话，会发现恢复出来的数据有问题，貌似时间不太对，你再仔细看看，是不是有的时间差了8小时！详细探究下来，我们发现timestamp类型字段的时间数据恢复有问题，准确来讲备份文件中记录的是0时区，而我们系统一般采用东八区，所以才会出现误差8小时的问题。
那么你会问了，为什么全部恢复不会出问题呢？问的好，我们看下备份文件就知道了。
#备份文件开头
--MySQLdump10.13Distrib5.7.23,forLinux(x86_64)
--
--Host:localhostDatabase:
--------------------------------------------------------
--Serverversion5.7.23-log

/*!40101SET@OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT*/;
/*!40101SET@OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS*/;
/*!40101SET@OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION*/;
/*!40101SETNAMESutf8*/;
/*!40103SET@OLD_TIME_ZONE=@@TIME_ZONE*/;
/*!40103SETTIME_ZONE='+00:00'*/;
注意上面两行
/*!40014SET@OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS,UNIQUE_CHECKS=0*/;
/*!40014SET@OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,FOREIGN_KEY_CHECKS=0*/;
/*!40101SET@OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO'*/;
/*!40111SET@OLD_SQL_NOTES=@@SQL_NOTES,SQL_NOTES=0*/;


#备份文件结尾
/*!40103SETTIME_ZONE=@OLD_TIME_ZONE*/;
/*!40101SETSQL_MODE=@OLD_SQL_MODE*/;
/*!40014SETFOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS*/;
/*!40014SETUNIQUE_CHECKS=@OLD_UNIQUE_CHECKS*/;
/*!40101SETCHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT*/;
/*!40101SETCHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS*/;
/*!40101SETCOLLATION_CONNECTION=@OLD_COLLATION_CONNECTION*/;
/*!40111SETSQL_NOTES=@OLD_SQL_NOTES*/;

--Dumpcompletedon2020-09-1815:56:40
仔细看备份文件，你会发现mysqldump备份出来的文件中，首先会将会话时区改为0，结尾处再改回原时区。这就代表着，备份文件中记录的时间戳数据都是以0时区为基础的。如果直接执行筛选出的SQL，就会造成0时区的时间戳插入的东八区的系统中，显然会造成时间相差8小时的问题。
看到这里，不知道你是否看懂了呢，可能有过备份恢复经验的同学好理解些。解决上述问题的方法也很简单，那就是在执行SQL文件前，更改当前会话时区为0，再次来演示下：
#清空test_db表数据
mysql>truncatetabletest_tb;
QueryOK,0rowsaffected(0.02sec)

#文件开头增加时区声明
vimtest_tb_data.sql
setsessionTIME_ZONE='+00:00';
INSERTINTO`test_tb`VALUES(1,1001,'dsfs','2020-08-0412:12:36','2020-09-1706:19:27','2020-09-1706:19:27'),
(2,1002,'vfsfs','2020-09-0412:12:36','2020-09-1706:19:27','2020-09-1706:19:27'),
(3,1003,'adsfsf',NULL,'2020-09-1706:19:27','2020-09-1706:19:27'),
(4,1004,'walfd','2020-09-1714:19:27','2020-09-1706:19:27','2020-09-1807:52:13');

#执行恢复并比对发现数据正确
mysql>select*fromtest_tb;
+--------+------+--------+---------------------+---------------------+---------------------+
|inc_id|col1|col2|col_dt|create_time|update_time|
+--------+------+--------+---------------------+---------------------+---------------------+
|1|1001|dsfs|2020-08-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|2|1002|vfsfs|2020-09-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|3|1003|adsfsf|NULL|2020-09-1714:19:27|2020-09-1714:19:27|
|4|1004|walfd|2020-09-1714:19:27|2020-09-1714:19:27|2020-09-1815:52:13|
+--------+------+--------+---------------------+---------------------+---------------------+
4rowsinset(0.00sec)

mysql>select*fromtest_tb_bak;
+--------+------+--------+---------------------+---------------------+---------------------+
|inc_id|col1|col2|col_dt|create_time|update_time|
+--------+------+--------+---------------------+---------------------+---------------------+
|1|1001|dsfs|2020-08-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|2|1002|vfsfs|2020-09-0412:12:36|2020-09-1714:19:27|2020-09-1714:19:27|
|3|1003|adsfsf|NULL|2020-09-1714:19:27|2020-09-1714:19:27|
|4|1004|walfd|2020-09-1714:19:27|2020-09-1714:19:27|2020-09-1815:52:13|
+--------+------+--------+---------------------+---------------------+---------------------+
4rowsinset(0.00sec)
总结：
我们在网络中很容易搜索出恢复单库或单表的方法，大多都有提到上述利用sed、grep命令来手动筛选的方法。但大部分文章都未提及可能出现的问题，如果你的表字段有timestamp类型，用这种方法要格外注意。无论面对哪种恢复需求，我们都要格外小心，不要造成越恢复越糟糕的情况，最好有个空实例演练下，然后再进行恢复。
以上就是MySQL如何恢复单库或单表,以及可能遇到的坑的详细内容，更多关于MySQL恢复单库或单表的资料请关注毛票票其它相关文章！

MySQL如何恢复单库或单表,以及可能遇到的坑

热门推荐

随机推荐