MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑
更新時間：2020年09月30日 14:29:06 作者：MySQL技術(shù)
這篇文章主要介紹了MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑，幫助大家更好的備份數(shù)據(jù)庫，保護(hù)數(shù)據(jù)安全，感興趣的朋友可以了解下
前言：
MySQL 邏輯備份工具最常用的就是 mysqldump 了，一般我們都是備份整個實例或部分業(yè)務(wù)庫。不清楚你有沒有做過恢復(fù)，恢復(fù)場景可能就比較多了，比如我想恢復(fù)某個庫或某個表等。那么如何從全備中恢復(fù)單庫或單表，這其中又有哪些隱藏的坑呢？這篇文章我們一起來看下。
1.如何恢復(fù)單庫或單表
前面文章有介紹過 MySQL 的備份與恢復(fù)?？赡芪覀兠總€數(shù)據(jù)庫實例中都不止一個庫，一般備份都是備份整個實例，但恢復(fù)需求又是多種多樣的，比如說我想只恢復(fù)某個庫或某張表，這個時候應(yīng)該怎么操作呢？
如果你的實例數(shù)據(jù)量不大，可以在另外一個環(huán)境恢復(fù)出整個實例，然后再單獨備份出所需庫或表用來恢復(fù)。不過這種方法不夠靈活，并且只適用數(shù)據(jù)量比較少的情況。
其實從全備中恢復(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ù)單庫或單表的方法，看起來簡單方便，其實隱藏著一個小坑，下面我們來具體演示下：
# 備份整個實例
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)驗的同學(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ù)越糟糕的情況，最好有個空實例演練下，然后再進(jìn)行恢復(fù)。
以上就是MySQL如何恢復(fù)單庫或單表,以及可能遇到的坑的詳細(xì)內(nèi)容，更多關(guān)于MySQL 恢復(fù)單庫或單表的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
下面小編就為大家?guī)硪黄猻ql format函數(shù)()的用法及簡單實例。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-05-05
詳解Mysql如何實現(xiàn)數(shù)據(jù)同步到Elasticsearch
要通過Elasticsearch實現(xiàn)數(shù)據(jù)檢索，首先要將Mysql中的數(shù)據(jù)導(dǎo)入Elasticsearch，并實現(xiàn)數(shù)據(jù)源與Elasticsearch數(shù)據(jù)同步，這里使用的數(shù)據(jù)源是Mysql數(shù)據(jù)庫。目前Mysql與Elasticsearch常用的同步機(jī)制大多是基于插件實現(xiàn)的，希望這篇文章能對大家有所幫助2021-11-11
CentOs7安裝部署Sonar環(huán)境的詳細(xì)過程(JDK1.8+MySql5.7+sonarqube7.8)
這篇文章主要介紹了CentOs7安裝部署Sonar環(huán)境(JDK1.8+MySql5.7+sonarqube7.8),本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2023-06-06
這篇文章主要為大家詳細(xì)介紹了mysql 8.0.12 安裝配置圖文教程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2018-08-08
這篇文章主要介紹了MySql常用操作SQL語句匯總,本文講解了增加、刪除、查詢、修改等常用SQL語句實例,需要的朋友可以參考下2015-03-03
這篇文章主要介紹了sql注入數(shù)據(jù)庫原理詳情介紹，文章圍繞主題展開詳細(xì)的內(nèi)容戒殺，具有一定的參考價值，需要的小伙伴可以參考一下，希望對你的學(xué)習(xí)有所幫助2022-09-09
深入理解SQL的四種連接-左外連接、右外連接、內(nèi)連接、全連接
本篇文章是對SQL中的四種連接-左外連接、右外連接、內(nèi)連接、全連接進(jìn)行了詳細(xì)的分析介紹，需要的朋友參考下2013-07-07
詳解MySQL導(dǎo)出指定表中的數(shù)據(jù)的實例
這篇文章主要介紹了詳解MySQL導(dǎo)出指定表中的數(shù)據(jù)的實例的相關(guān)資料,希望通過本文能幫助到大家，需要的朋友可以參考下2017-09-09
MySQL5.7中 performance和sys schema中的監(jiān)控參數(shù)解釋(推薦)
在MySQL5.7中，performance schema有很大改進(jìn)，包括引入大量新加入的監(jiān)控項、降低占用空間和負(fù)載，以及通過新的sys schema機(jī)制顯著提升易用性。下面通過本文給大家介紹 MySQL5.7中 performance和sys schema中的監(jiān)控參數(shù)解釋,需要的朋友可以參考下2017-08-08
這篇文章主要為大家詳細(xì)介紹了MySQL主從復(fù)制的實現(xiàn)過程，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-07-07