主頁 > 知識庫 > MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑

MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑

熱門標(biāo)簽:芒果電話機(jī)器人自動化 百度地圖圖標(biāo)標(biāo)注中心 湖南人工外呼系統(tǒng)多少錢 廣東人工電話機(jī)器人 信陽穩(wěn)定外呼系統(tǒng)運(yùn)營商 日照旅游地圖標(biāo)注 申請外呼電話線路 石家莊電商外呼系統(tǒng) 南通自動外呼系統(tǒng)軟件

前言:

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

1.如何恢復(fù)單庫或單表

前面文章有介紹過 MySQL 的備份與恢復(fù)??赡芪覀兠總€數(shù)據(jù)庫實(shí)例中都不止一個庫,一般備份都是備份整個實(shí)例,但恢復(fù)需求又是多種多樣的,比如說我想只恢復(fù)某個庫或某張表,這個時候應(yīng)該怎么操作呢?

如果你的實(shí)例數(shù)據(jù)量不大,可以在另外一個環(huán)境恢復(fù)出整個實(shí)例,然后再單獨(dú)備份出所需庫或表用來恢復(fù)。不過這種方法不夠靈活,并且只適用數(shù)據(jù)量比較少的情況。

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

# 查看及備份所有庫
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庫 并進(jìn)行單庫恢復(fù)
mysql> drop database testdb;
Query OK, 36 rows affected (2.06 sec)

# 貌似恢復(fù)前 testdb庫不存在的話要手動新建
mysql -uroot -pxxxx --one-database testdb  all_db.sql

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

# 從全備中恢復(fù)單庫
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.小心有坑

對于上述手動篩選來恢復(fù)單庫或單表的方法,看起來簡單方便,其實(shí)隱藏著一個小坑,下面我們來具體演示下:

# 備份整個實(shí)例
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建表及插數(shù)據(jù)語句
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 '創(chuàng)建時間',
 `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');

# 執(zhí)行恢復(fù)單表操作
mysql -uroot -pxxxx testdb  test_tb_info.sql
mysql -uroot -pxxxx testdb  test_tb_data.sql

# 查看恢復(fù)數(shù)據(jù) 并和備份表比對
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)

如果你仔細(xì)觀察的話,會發(fā)現(xiàn)恢復(fù)出來的數(shù)據(jù)有問題,貌似時間不太對,你再仔細(xì)看看,是不是有的時間差了8小時!詳細(xì)探究下來,我們發(fā)現(xiàn) timestamp 類型字段的時間數(shù)據(jù)恢復(fù)有問題,準(zhǔn)確來講備份文件中記錄的是0時區(qū),而我們系統(tǒng)一般采用東八區(qū),所以才會出現(xiàn)誤差8小時的問題。

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

# 備份文件開頭
-- 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 */;


# 備份文件結(jié)尾
/*!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

仔細(xì)看備份文件,你會發(fā)現(xiàn) mysqldump 備份出來的文件中,首先會將會話時區(qū)改為0,結(jié)尾處再改回原時區(qū)。這就代表著,備份文件中記錄的時間戳數(shù)據(jù)都是以0時區(qū)為基礎(chǔ)的。如果直接執(zhí)行篩選出的SQL,就會造成0時區(qū)的時間戳插入的東八區(qū)的系統(tǒng)中,顯然會造成時間相差8小時的問題。

看到這里,不知道你是否看懂了呢,可能有過備份恢復(fù)經(jīng)驗(yàn)的同學(xué)好理解些。解決上述問題的方法也很簡單,那就是在執(zhí)行SQL文件前,更改當(dāng)前會話時區(qū)為0,再次來演示下:

# 清空test_db表數(shù)據(jù)
mysql> truncate table test_tb;
Query OK, 0 rows affected (0.02 sec)

# 文件開頭增加時區(qū)聲明
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');

# 執(zhí)行恢復(fù)并比對 發(fā)現(xiàn)數(shù)據(jù)正確
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)

總結(jié):

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

以上就是MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑的詳細(xì)內(nèi)容,更多關(guān)于MySQL 恢復(fù)單庫或單表的資料請關(guān)注腳本之家其它相關(guān)文章!

您可能感興趣的文章:
  • MySQL使用全庫備份數(shù)據(jù)恢復(fù)單表數(shù)據(jù)的方法
  • MySQL單表恢復(fù)的步驟
  • 從MySQL全庫備份中恢復(fù)某個庫和某張表的方法
  • mysql 從 frm 文件恢復(fù) table 表結(jié)構(gòu)的3種方法【推薦】
  • InnoDB 類型MySql恢復(fù)表結(jié)構(gòu)與數(shù)據(jù)
  • MySQL 從全庫備份中恢復(fù)指定的表和庫示例
  • MySQL單表ibd文件恢復(fù)方法詳解
  • MYSQL使用.frm恢復(fù)數(shù)據(jù)表結(jié)構(gòu)的實(shí)現(xiàn)方法
  • 用mysqldump備份和恢復(fù)指定表的方法
  • MySQL 利用frm文件和ibd文件恢復(fù)表數(shù)據(jù)

標(biāo)簽:天津 公主嶺 呼和浩特 牡丹江 合肥 惠州 阿里 沈陽

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑》,本文關(guān)鍵詞  MySQL,如何,恢復(fù),單庫,或,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑》相關(guān)的同類信息!
  • 本頁收集關(guān)于MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章