Categories
程式開發

從全備中恢復單庫或單表,小心有坑!


前言:

MySQL 邏輯備份工具最常用的就是mysqldump 了,一般我們都是備份整個實例或部分業務庫。 不清楚你有沒有做過恢復,恢復場景可能就比較多了,比如我想恢復某個庫或某個表等。 那麼如何從全備中恢復單庫或單表,這其中又有哪些隱藏的坑呢? 這篇文章我們一起來看下。

1.如何恢復單庫或單表

前面文章“有介紹過MySQL 的備份與恢復。可能我們每個數據庫實例中都不止一個庫,一般備份都是備份整個實例,但恢復需求又是多種多樣的,比如說我想只恢復某個庫或某張表,這個時候應該怎麼操作呢?

如果你的實例數據量不大,可以在另外一個環境恢復出整個實例,然後再單獨備份出所需庫或表用來恢復。 不過這種方法不夠靈活,並且只適用數據量比較少的情況。

其實從全備中恢復單庫還是比較方便的,有個–one-database 參數可以指定單庫恢復,下面來具體演示下:

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

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

# 删除testdb库 并进行单库恢复
mysql> drop database testdb;
Query OK, 36 rows affected (2.06 sec)

# 貌似恢复前 testdb库不存在的话要手动新建
mysql -uroot -pxxxx --one-database testdb < all_db.sql

除了上述方法外,恢復單庫或單表還可以採用手動篩選的方法。 這個時候Linux 下大名鼎鼎的sed 和grep 命令就派上用場了,我們可以利用這兩個命令從全備中篩選出單庫或單表的語句,篩選方法如下:

# 从全备中恢复单库
sed -n '/^-- Current Database: `testdb`/,/^-- Current Database: `/p' all_db.sql > testdb.sql

# 筛选出单表语句
cat all_db.sql | sed -e '/./{H;$!d;}' -e 'x;/CREATE TABLE `test_tb`/!d;q' > /tmp/test_tb_info.sql
cat all_db.sql | grep --ignore-case 'insert into `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> create table test_tb_bak like test_tb;
Query OK, 0 rows affected (0.03 sec)

mysql> insert into test_tb_bak select * from test_tb;
Query OK, 4 rows affected (0.02 sec)
Records: 4 Duplicates: 0 Warnings: 0

mysql> drop table test_tb;
Query OK, 0 rows affected (0.02 sec)

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

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

DROP TABLE IF EXISTS `test_tb`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `test_tb` (
`inc_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`col1` int(11) NOT NULL,
`col2` varchar(20) DEFAULT NULL,
`col_dt` datetime DEFAULT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
PRIMARY KEY (`inc_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COMMENT='测试表';
/*!40101 SET character_set_client = @saved_cs_client */;

cat test_tb_data.sql

INSERT INTO `test_tb` VALUES (1,1001,'dsfs','2020-08-04 12:12:36','2020-09-17 06:19:27','2020-09-17 06:19:27'),
(2,1002,'vfsfs','2020-09-04 12:12:36','2020-09-17 06:19:27','2020-09-17 06:19:27'),
(3,1003,'adsfsf',NULL,'2020-09-17 06:19:27','2020-09-17 06:19:27'),
(4,1004,'walfd','2020-09-17 14:19:27','2020-09-17 06:19:27','2020-09-18 07:52:13');

# 执行恢复单表操作
mysql -uroot -pxxxx testdb < test_tb_info.sql mysql -uroot -pxxxx testdb select * from test_tb; +--------+------+--------+---------------------+---------------------+---------------------+ | inc_id | col1 | col2 | col_dt | create_time | update_time | +--------+------+--------+---------------------+---------------------+---------------------+ | 1 | 1001 | dsfs | 2020-08-04 12:12:36 | 2020-09-17 06:19:27 | 2020-09-17 06:19:27 | | 2 | 1002 | vfsfs | 2020-09-04 12:12:36 | 2020-09-17 06:19:27 | 2020-09-17 06:19:27 | | 3 | 1003 | adsfsf | NULL | 2020-09-17 06:19:27 | 2020-09-17 06:19:27 | | 4 | 1004 | walfd | 2020-09-17 14:19:27 | 2020-09-17 06:19:27 | 2020-09-18 07:52:13 | +--------+------+--------+---------------------+---------------------+---------------------+ 4 rows in set (0.00 sec) mysql> select * from test_tb_bak;
+--------+------+--------+---------------------+---------------------+---------------------+
| inc_id | col1 | col2 | col_dt | create_time | update_time |
+--------+------+--------+---------------------+---------------------+---------------------+
| 1 | 1001 | dsfs | 2020-08-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 2 | 1002 | vfsfs | 2020-09-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 3 | 1003 | adsfsf | NULL | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 4 | 1004 | walfd | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 | 2020-09-18 15:52:13 |
+--------+------+--------+---------------------+---------------------+---------------------+
4 rows in set (0.00 sec)

如果你仔細觀察的話,會發現恢復出來的數據有問題,貌似時間不太對,你再仔細看看,是不是有的時間差了8小時! 詳細探究下來,我們發現timestamp 類型字段的時間數據恢復有問題,準確來講備份文件中記錄的是0時區,而我們系統一般採用東八區,所以才會出現誤差8小時的問題。

那麼你會問了,為什麼全部恢復不會出問題呢? 問的好,我們看下備份文件就知道了。

# 备份文件开头
-- MySQL dump 10.13 Distrib 5.7.23, for Linux (x86_64)
--
-- Host: localhost Database:
-- ------------------------------------------------------
-- Server version 5.7.23-log

/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
注意上面两行
/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;

# 备份文件结尾
/*!40103 SET [email protected]_TIME_ZONE */;
/*!40101 SET [email protected]_SQL_MODE */;
/*!40014 SET [email protected]_FOREIGN_KEY_CHECKS */;
/*!40014 SET [email protected]_UNIQUE_CHECKS */;
/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;
/*!40101 SET [email protected]_COLLATION_CONNECTION */;
/*!40111 SET [email protected]_SQL_NOTES */;

-- Dump completed on 2020-09-18 15:56:40

仔細看備份文件,你會發現mysqldump 備份出來的文件中,首先會將會話時區改為0,結尾處再改回原時區。 這就代表著,備份文件中記錄的時間戳數據都是以0時區為基礎的。 如果直接執行篩選出的SQL,就會造成0時區的時間戳插入的東八區的系統中,顯然會造成時間相差8小時的問題。

看到這裡,不知道你是否看懂了呢,可能有過備份恢復經驗的同學好理解些。 解決上述問題的方法也很簡單,那就是在執行SQL文件前,更改當前會話時區為0,再次來演示下:

# 清空test_db表数据
mysql> truncate table test_tb;
Query OK, 0 rows affected (0.02 sec)

# 文件开头增加时区声明
vim test_tb_data.sql
set session TIME_ZONE='+00:00';
INSERT INTO `test_tb` VALUES (1,1001,'dsfs','2020-08-04 12:12:36','2020-09-17 06:19:27','2020-09-17 06:19:27'),
(2,1002,'vfsfs','2020-09-04 12:12:36','2020-09-17 06:19:27','2020-09-17 06:19:27'),
(3,1003,'adsfsf',NULL,'2020-09-17 06:19:27','2020-09-17 06:19:27'),
(4,1004,'walfd','2020-09-17 14:19:27','2020-09-17 06:19:27','2020-09-18 07:52:13');

# 执行恢复并比对 发现数据正确
mysql> select * from test_tb;
+--------+------+--------+---------------------+---------------------+---------------------+
| inc_id | col1 | col2 | col_dt | create_time | update_time |
+--------+------+--------+---------------------+---------------------+---------------------+
| 1 | 1001 | dsfs | 2020-08-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 2 | 1002 | vfsfs | 2020-09-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 3 | 1003 | adsfsf | NULL | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 4 | 1004 | walfd | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 | 2020-09-18 15:52:13 |
+--------+------+--------+---------------------+---------------------+---------------------+
4 rows in set (0.00 sec)

mysql> select * from test_tb_bak;
+--------+------+--------+---------------------+---------------------+---------------------+
| inc_id | col1 | col2 | col_dt | create_time | update_time |
+--------+------+--------+---------------------+---------------------+---------------------+
| 1 | 1001 | dsfs | 2020-08-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 2 | 1002 | vfsfs | 2020-09-04 12:12:36 | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 3 | 1003 | adsfsf | NULL | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 |
| 4 | 1004 | walfd | 2020-09-17 14:19:27 | 2020-09-17 14:19:27 | 2020-09-18 15:52:13 |
+--------+------+--------+---------------------+---------------------+---------------------+
4 rows in set (0.00 sec)

總結:

我們在網絡中很容易搜索出恢復單庫或單表的方法,大多都有提到上述利用sed 、grep 命令來手動篩選的方法。 但大部分文章都未提及可能出現的問題,如果你的表字段有timestamp 類型,用這種方法要格外注意。 無論面對哪種恢復需求,我們都要格外小心,不要造成越恢復越糟糕的情況,最好有個空實例演練下,然後再進行恢復。