**前言：**

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

#### 1.如何恢復單庫或單表

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

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

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

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` 命令就派上用場了，我們可以利用這兩個命令從全備中篩選出單庫或單表的語句，篩選方法如下：

```sql
# 從全備中恢復單庫
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.小心有坑

對於上述手動篩選來恢復單庫或單表的方法，看起來簡單方便，其實隱藏著一個小坑，下面我們來具體演示下：

```sql
# 備份整個例項
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 < test_tb_data.sql

# 檢視恢復資料 並和備份表比對
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 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小時的問題。

那麼你會問了，為什麼全部恢復不會出問題呢？問的好，我們看下備份檔案就知道了。

```sql
# 備份檔案開頭
-- MySQL dump 10.13  Distrib 5.7.23, for Linux (x86_64)
--
-- Host: localhost    Database:
-- ------------------------------------------------------
-- Server version       5.7.23-log

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

# 備份檔案結尾
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

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

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

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

```sql
# 清空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 型別，用這種方法要格外注意。無論面對哪種恢復需求，我們都要格外小心，不要造成越恢復越糟糕的情況，最好有個空例項演練下，然後再進行恢復。

從全備中恢復單庫或單表，小心有坑！

相關文章