程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> Linux下完成MySQL數據備份和恢復的敕令應用全攻略

Linux下完成MySQL數據備份和恢復的敕令應用全攻略

編輯:MySQL綜合教程

Linux下完成MySQL數據備份和恢復的敕令應用全攻略。本站提示廣大學習愛好者:(Linux下完成MySQL數據備份和恢復的敕令應用全攻略)文章只能為提供參考,不一定能成為您想要的結果。以下是Linux下完成MySQL數據備份和恢復的敕令應用全攻略正文


為了保證數據的平安,須要按期對數據停止備份。備份的方法有許多種,後果也紛歧樣。一旦數據庫中的數據湧現了毛病,就須要應用備份好的數據停止復原恢復。從而將喪失降到最低。上面我們來懂得一下MySQL罕見的有三種備份恢復方法:

1、應用Mysqldump+二進制日記完成備份
2、應用LVM快照+二進制日記完成備份
3、應用Xtrabackup備份

一:試驗情況引見:

體系引見:CentOS6.4_X64
數據庫版本:mysql-5.5.33

二:基於Mysqldump敕令完成備份恢復

2.1、思緒概念

Mysqldump是一個邏輯備份敕令;意思就是將數據庫中的數據備份成一個文本文件;也能夠說是將表的構造和數據存儲在文本文件中。

Mysqldump敕令的任務道理很簡略,它先查出須要備份的表的構造,再在文本文件中生成一個CREATE語句。然後,將表中的一切記載轉換為一條INSTERT語句。這些CREATE語句和INSTERT語句都是復原時應用的。復原數據時便可以應用個中的CREATE語句來創立表。應用個中的INSERT語句來復原數據。它可以完成全部辦事器備份,也能夠完成單個或部門數據庫、單個或部門表、表中的某些行、存儲進程、存儲函數、觸發器的備份;而且能主動記載備份時辰的二進制日記文件及響應的地位。關於InnoDB存儲引擎來說支撐基於單事務形式完成熱備,關於MyISAM則最多支撐溫備。

2.2、備份戰略

Mysqldump全備+二進制日記增備

2.3、進程完成

(1)Mysqldump全備
因為Mysql數據庫默許的為MyISAM存儲引擎所以只要應用溫備(備份同時僅支撐讀要求)停止,所以我們要為一切數據庫添加讀鎖

[root@stu18 ~]
#mysqldump -uroot -pmypass --lock-all-tables --master-data=2 --events --routines--all-databases > /zhao/database_`date +%F`.sql

解析:–lock-all-tables表現為一切表施加讀鎖;–master-data=2表現在備份文件中記載以後二進制日記的地位;–events表現備份數據的同時備份時光調劑器代碼;–routines表現備份數據的同時備份存儲進程和存儲函數;–all-databases表現備份一切庫。

[root@stu18 zhao]
# less database_2013-08-13.sql
--   
#表現正文項
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=14203; 
#這裡表現以後處於mysql-bin.000001這個二進制日記中,事宜為14203這是經由過程--master-data=2發生的
--
-- Current Database: `hellodb`
--
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `hellodb` /*!40100 DEFAULT CHARACTER SET utf8 */;

(2)二進制全備

辦法一: 導出二進制日記文件內容

[root@stu18 data]
# mysqlbinlog mysql-bin.000001 >/zhao/binlog_`date +%F`.sql

辦法二:轉動日記復制文件

mysql> flush logs; 
#轉動日記
[root@stu18 data]
# cp mysql-bin.000001 /zhao/mysql-bin.000001 #復制導出二進制文件

(3)二進制增備
起首添加數據信息

mysql> use hellodb;
mysql> INSERT INTO students(Name,Age,Gender,ClassID,TeacherID) values ('Yang kang',22,'M',3,3);

然後二進制增備

[root@stu18 data]
# mysqlbinlog --start-position=14203 --stop-position=14527 mysql-bin.000001 > /zhao/binlog_`date +%F_%H`.sql

解析:–start-position=14203是前次全備以後的二進制事宜地位;–stop-position=14527比來一天的二進制事宜地位。

2.4、模仿數據庫破壞,完成恢停工作

mysql> DROP DATABASE hellodb;    
#刪除數據庫
############上面這些進程要在離線狀況下履行############
mysql> SET sql_log_bin=0;     
#先封閉二進制日記
mysql> flush logs;      
#轉動日記
[root@stu18 ~]
# mysql -uroot -pmypass < /zhao/database_2013-08-13.sql #導入數據庫備份文件
[root@stu18 ~]
# mysql -uroot -pmypass < /zhao/binlog_2013-08-13_19.sql #導入增量備份文件
[root@stu18 ~]
# mysql -uroot –pmypass #登錄檢查,恢復完成
mysql> SET sql_log_bin=1;

這類備份方法恢復簡略,然則恢復復原以後索引會湧現毛病須要重建,並且備份成果會占領很年夜的空間,請酌情應用。

PS:mysqldump經常使用敕令小結
備份MySQL數據庫的敕令

mysqldump -hhostname -uusername -ppassword databasename > backupfile.sql

備份MySQL數據庫為帶刪除表的格局

備份MySQL數據庫為帶刪除表的格局,可以或許讓該備份籠罩已稀有據庫而不須要手動刪除原稀有據庫。

mysqldump -–add-drop-table -uusername -ppassword databasename > backupfile.sql

直接將MySQL數據庫緊縮備份

mysqldump -hhostname -uusername -ppassword databasename | gzip > backupfile.sql.gz

備份MySQL數據庫某個(些)表

mysqldump -hhostname -uusername -ppassword databasename specific_table1 specific_table2 > backupfile.sql

同時備份多個MySQL數據庫

mysqldump -hhostname -uusername -ppassword –databases databasename1 databasename2 databasename3 > multibackupfile.sql

僅僅備份數據庫構造

mysqldump –no-data –databases databasename1 databasename2 databasename3 > structurebackupfile.sql

備份辦事器上一切數據庫

mysqldump –all-databases > allbackupfile.sql

復原MySQL數據庫的敕令

mysql -hhostname -uusername -ppassword databasename < backupfile.sql

復原緊縮的MySQL數據庫

gunzip < backupfile.sql.gz | mysql -uusername -ppassword databasename

將數據庫轉移到新辦事器

mysqldump -uusername -ppassword databasename | mysql –host=*.*.*.* -C databasename

3、基於LVM快照完成備份恢復

3.1、思緒明細

(1)LVM這類備份方法請求Mysql的數據保留在邏輯卷上
(2)須要給Mysql辦事器施加讀鎖(mysql>FLUSH TABLES WITH READLOCK;),這裡弗成直接加入辦事器
(3)另起終端為數據地點的卷創立快照(lvcreate),包管事務日記和數據文件必需在統一卷上(分離創立能夠會招致數據文件和事務日記紛歧致,從而能夠招致沒法正常恢復)

3.2、備份戰略

LVM快照全備+二進制日記增備(關於即時點恢復還要恢復至後續的二進制地位)

3.3、條件前提

(1)創立邏輯卷及掛載邏輯卷,此進程在此就不做演示了

(2)初始化mysql將其數據目次指向/mydata/data

[root@stu18 ~]
# cd /usr/local/mysql/
[root@stu18 mysql]
# scripts/mysql_install_db --user=mysql --datadir=/mydata/data

(3)編纂檢查設置裝備擺設文件,重啟辦事

[root@stu18 mysql]
# vim /etc/my.cnf
datadir = /mydata/data 
#檢查此項能否界說數據目次地位
sync_binlog=1 
#添加此項,每一個事務提交時刻,把事務日記從緩存區寫到日記文件中,而且刷新日記文件的數據到磁盤上;
[root@stu18 mysql]
# service mysqld start

3.4、進程展現

(1)確保事務日記和數據文件必需在統一卷上

[root@stu18 ~]
# ls /mydata/data/
hellodb  myclass   mysql-bin.000003 stu18.magedu.com.err
ibdata1  mysql    mysql-bin.000004 stu18.magedu.com.pid
ib_logfile0 mysql-bin.000001 mysql-bin.index  student
ib_logfile1 mysql-bin.000002 performance_schema test

解析:個中ib_logfile0與ib_logfile1是日記文件
(2)施加全局鎖並轉動日記

mysql> FLUSH TABLES WITH READ LOCK;
mysql> FLUSH LOGS;

(3)檢查並保留以後正在應用的二進制日記及以後履行二進制日記地位(異常主要)

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File    | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 |  187 |    |     |
+------------------+----------+--------------+------------------+
[root@stu18 zhao]
# mysql -uroot -pmypass -e 'SHOW MASTER STATUS;' >/zhao/lvmback-2013-08-14/binlog.txt

(4)創立快照卷

[root@stu18 zhao]
# lvcreate -L 100M -s -p r -n mydata-lvm /dev/vg1/mydata

(5)立刻切換終端釋放鎖

mysql> UNLOCK TABLES;

(6)備份數據

[root@stu18 data]
# cp -a * /zhao/lvmback-2013-08-14/

(7)二進制完成增量備份

mysql> use hellodb;   
#指定默許數據庫
Database changed
mysql> CREATE TABLE testtb (id int,name CHAR(10));  
#創立表
Query OK, 0 rows affected (0.35 sec)
mysql> INSERT INTO testtb VALUES (1,'tom');   
#添加數據
Query OK, 1 row affected (0.09 sec)
[root@stu18 data]
# mysqlbinlog --start-position=187 mysql-bin.000004 > /zhao/lvmlogbin_2013-08-14/binlog.sql   #日記完成增量備份

(8)模仿數據庫瓦解

[root@stu18 ~]
# service mysqld stop
[root@stu18 ~]
# cd /mydata/data/
[root@stu18 data]
# rm -rf *

(9)恢單數據

[root@stu18 ~]
# cp /zhao/lvmback-2013-08-14/* /mydata/data/ -a   #完整備份恢復
[root@stu18 ~]
# cd /mydata/data/    #檢查恢單數據內容
[root@stu18 data]
# chown -R mysql.mysql * #更改屬主屬組
[root@stu18 data]
# service mysqld start  #啟動辦事
[root@stu18 data]
# mysql -uroot –pmypass #登錄測試
mysql> SHOW DATABASES;  
#檢查數據完全性,無測試表testtd應用二進制恢復
mysql> SET sql_log_bin=0 
#封閉二進制日記
mysql> source /zhao/lvmlogbin_2013-08-14/binlog.sql; 
#二進制恢復
mysql> SHOW TABLES;   
#檢查恢復成果
+-------------------+
| Tables_in_hellodb |
+-------------------+
| classes   |
| coc    |
| courses   |
| scores   |
| students   |
| teachers   |
| testtb   |
| toc    |
+-------------------+
mysql> SET sql_log_bin=1; 
#開啟二進制日記

此對象是接近於熱備的方法完成的,而且用此辦法來備份恢單數據速度長短常快的。

四:基於xtrabackup來完成備份恢復

4.1、優勢特征

完整以熱備的情勢停止,可以或許完成疾速靠得住地完整備份和部門備份,支撐增量備份,支撐時光點復原,備份進程中不會打攪到事務操作,可以或許完成收集傳輸和緊縮功效從而有用的勤儉磁盤空間,備份完成後可主動驗證數據能否可用,恢復速度較快等等。更多優勢特征請參考http://www.percona.com/software/percona-xtrabackup

留意:以上這些優勢特征只能在InnoDB引擎上完善完成,而在MyISAM存儲引擎上仍然最多只能應用溫備的情勢停止而且還不支撐增量備份。
別的Xtrabackup更多的高等功效還依附於Mysql數據庫關於InnoDB完成了零丁的表空間,不然也就沒有方法完成單表導入導出檢查方法以下:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_file%';
+--------------------------+----------+
| Variable_name   | Value |
+--------------------------+----------+
| innodb_file_format  | Antelope |
| innodb_file_format_check | ON  |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | ON  |
+--------------------------+----------+

個中的innodb_file_per_table為ON則表現完成了單表單空間。若為OFF則須要應用mysqldump全備然後更改設置裝備擺設文件刪除本來的數據文件偏重新初始化辦事器最初將數據從新導入。所以建議今後在裝置Mysql辦事器時將其選項默許設置成1便可(innodb_file_per_table = 1)。單表單空間的數據顯示情勢為:

[root@stu18 hellodb]
# ls
classes.frm coc.MYD  courses.MYI scores.MYI teachers.frm testtb.ibd
classes.MYD coc.MYI  db.opt  students.frm teachers.MYD toc.frm
classes.MYI courses.frm scores.frm students.MYD teachers.MYI toc.MYD
coc.frm  courses.MYD scores.MYD students.MYI testtb.frm toc.MYI

4.2、裝置Xtrabackup

下載percona-xtrabackup最新的版本為2.1.4(percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm)
裝置:

[root@stu18 ~]
# rpm -ivh percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm

如有毛病沒法裝置存問裝perl-DBD-mysql依附包

[root@stu18 ~]
# yum -y install perl-DBD-mysql

留意:分歧的情況依附的關系包能夠有多個,請按照提醒停止設置裝備擺設

4.3、完整備份

應用innobakupex備份時,其會挪用xtrabackup備份一切的InnoDB表,復制一切關於表構造界說的相干文件(.frm)、和MyISAM、MERGE、CSV和ARCHIVE表的相干文件,同時還會備份觸發器和數據庫設置裝備擺設信息相干的文件。這些文件會被保留至一個以時光敕令的目次中。完整備份敕令以下:

# innobackupex --user=DBUSER--password=DBUSERPASS /path/to/BACKUP-DIR/

完成進程及解釋:

[root@stu18 ~] # mkdir /innobackup #創立備份文件目次 [root@stu18 ~] # innobackupex --user=root --password=mypass /innobackup/ #完整備份 ################假如履行准確厥後輸入的幾行信息平日以下############### xtrabackup: Transaction log of lsn (1604655) to (1604655) was copied. #二進制日記的地位(lsn) 130814 07:04:55 innobackupex: All tables unlocked innobackupex: Backup created in directory '/innobackup/2013-08-14_07-04-49' #備份文件保留的地位 innobackupex: MySQL binlog position: filename 'mysql-bin.000003', position 538898 130814 07:04:55 innobackupex: Connection to database server closed 130814 07:04:55 innobackupex: completed

OK!       備份完成
切換至備份文件目次檢查備份的數據信息及創立生成的文件:

 

[root@stu18 ~] # cd /innobackup/2013-08-14_07-04-49/ [root@stu18 2013-08-14_07-04-49] # ls backup-my.cnf myclass student xtrabackup_binlog_info hellodb mysql test xtrabackup_checkpoints ibdata1 performance_schema xtrabackup_binary xtrabackup_logfile

針對文件解析:

(1)xtrabackup_checkpoints —— 備份類型(如完整或增量)、備份狀況(如能否曾經為prepared狀況)和LSN(日記序列號)規模信息;
每一個InnoDB頁(平日為16k年夜小)都邑包括一個日記序列號,即LSN。LSN是全部數據庫體系的體系版本號,每一個頁面相干的LSN可以或許注解此頁面比來是若何產生轉變的。
(2)xtrabackup_binlog_info —— mysql辦事器以後正在應用的二進制日記文件及至備份這一刻為止二進制日記事宜的地位。
(3)xtrabackup_binary —— 備份頂用到的xtrabackup的可履行文件;
(4)backup-my.cnf —— 備份時用到的設置裝備擺設選項信息,也就是設置裝備擺設文件中關於mysqld的相干文件設置裝備擺設;
(5) xtrabackup_logfile —— 非文本文件是xtrabackup自己的日記文件;

4.4、預備一個完整備份

普通情形下,在備份完成後,數據尚且不克不及用於恢復操作,由於備份的數據中能夠會包括還沒有提交的事務或曾經提交但還沒有同步至數據文件中的事務。是以,此時數據文件仍處於紛歧致狀況。“預備”的重要感化恰是經由過程回滾未提交的事務及同步曾經提交的事務至數據文件從而使得數據文件處於分歧性狀況。

innobakupex敕令的–apply-log選項可用於完成上述功效。以下面的敕令:

[root@stu18 ~]
# innobackupex -apply-log /innobackup/2013-08-14_07-04-49/
#############假如履行准確,其最初輸入的幾行信息平日以下################
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
130814 7:39:33 InnoDB: Starting shutdown...
130814 7:39:37 InnoDB: Shutdown completed; log sequence number 1606156
130814 07:39:37 innobackupex: completed OK!

4.5、模仿數據庫瓦解完成完整恢復

(1)模仿瓦解

[root@stu18 ~]
# service mysqld stop
[root@stu18 ~]
# cd /mydata/data/
[root@stu18 data]
# rm -rf *

(2)從完整備份中恢單數據(謹記:在恢單數據之前萬萬弗成初始化數據庫和啟動辦事)
innobackupex敕令的–copy-back選項用於履行恢復操作,其經由過程復制一切數據相干的文件至mysql辦事器DATADIR目次中來履行恢復進程。innobackupex經由過程backup-my.cnf來獲得DATADIR目次的相干信息。

[root@stu18 ~]
# innobackupex --copy-back /innobackup/2013-08-14_07-04-49/
#############假如履行准確,其最初輸入的幾行信息平日以下################
innobackupex: Starting to copy InnoDB log files
innobackupex: in '/innobackup/2013-08-14_07-04-49'
innobackupex: back to original InnoDB log directory '/mydata/data'
innobackupex: Copying '/innobackup/2013-08-14_07-04-49/ib_logfile0' to '/mydata/data'
innobackupex: Copying '/innobackup/2013-08-14_07-04-49/ib_logfile1' to '/mydata/data'
innobackupex: Finished copying back files.
130814 07:58:22 innobackupex: completed OK!

(3)當數據恢復至數據目次今後,還須要確保一切數據文件的屬主和屬組均為准確的用戶,如mysql,不然,在啟動mysqld之前還須要事前修正數據文件的屬主和屬組。

# chown -R mysql:mysql /mydata/data/

(4)啟動辦事器上岸檢查恢復完成。

[root@stu18 data]
# service mysqld start

留意:每次恢復完成以後必定要從新做一次完整備份任務!!

4.6、應用innobackupex停止增量備份

解釋:每一個InnoDB的頁面都邑包括一個LSN信息,每當相干的數據產生轉變,相干的頁面的LSN就會主動增加。這恰是InnoDB表可以停止增量備份的基本,即innobackupex經由過程備份前次完整備份以後產生轉變的頁面來完成。
第一次修改數據完成增量備份
完成增量備份可使用上面的敕令停止:

[root@stu18 data]
# innobackupex --user=root --password=mypass --incremental /innobackup --incremental-basedir=/innobackup/2013-08-14_08-14-12/

個中,/innobackup指的是完整備份地點的目次,此敕令履行停止後,innobackupex敕令會在/backup目次中創立一個新的以時光定名的目次以寄存一切的增量備份數據。–incremental-basedir是指向上一次完整備份地點的目次。

第二次修改數據停止增量備份:

[root@stu18 ~]
# innobackupex --user=root --password=mypass --incremental /innobackup --incremental-basedir=/innobackup/2013-08-14_08-29-05/

第二次增量備份的履行敕令和第一次年夜致雷同,只要其–incremental-basedir應當指向上一次的增量備份地點的目次。

第三次修改數據還未停止增量備份

mysql> delete from coc where id=14;

4.7、應用innobackupex基於完整+增量+二進制日記恢單數據

(1)因為筆者這裡將二進制日記和數據文件寫在了統一個文件目次下所以在模仿數據庫瓦解前必需先復制出二進制日記文件,所以建議看客們將數據目次和二進制目次離開寄存,不要和筆者一樣犯如斯二的毛病。辦法以下:
條件是在方才樹立辦事器還沒有啟動辦事器之前做以下操作;

mkdir /mybinlog 
#樹立一目次用於寄存二進制日記
chown mysql:mysql /mybinlog 
#更改權限
vim /etc/my.cnf 
#修正設置裝備擺設文件
log-bin=/mybinlog/mysql-bin 
#二進制日記目次及文件名前綴,添加上

好了言歸正傳復制二進制日記文件:

[root@stu18 data]
# cp mysql-bin.000001/innobackup/

(2)模仿辦事器瓦解

[root@stu18 ~]
# service mysqld stop
[root@stu18 ~]
# cd /mydata/data/
[root@stu18 data]
# rm -rf *

(3)預備備份

起首留意“預備”增量備份與整頓完整備份有著一些分歧,特別要留意的是:
1)須要在每一個備份(包含完整和各個增量備份)上,將曾經提交的事務停止“重放”。“重放”以後,一切的備份數據將歸並到完整備份上。
2)基於一切的備份將未提交的事務停止“回滾”。

完整備份“預備”

[root@stu18 ~]
# innobackupex --apply-log --redo-only/innobackup/2013-08-14_08-14-12/

第一次增量備份“預備”也就是說將第一次增量備份歸並到了完整備份中

[root@stu18 ~]
# innobackupex --apply-log--redo-only /innobackup/2013-08-14_08-14-12/--incremental-dir=/innobackup/2013-08-14_08-29-05/

第二次增量備份“預備”也就是說將第二次增量備份也歸並到了完整備份中

[root@stu18 ~]
# innobackupex --apply-log--redo-only /innobackup/2013-08-14_08-14-12/ --incremental-dir=/innobackup/2013-08-14_09-08-39/

個中 –redo-only是只將已提交的事務同步到數據文件中,未提交的事務日記不在停止回滾了。

(4)恢單數據(基於innobackupex基於完整+增量)

[root@stu18 ~]
# innobackupex --copy-back/innobackup/2013-08-14_08-14-12/

(5)更改屬組屬主

[root@stu18 ~]
# cd /mydata/data/
[root@stu18 data]
# chown -R mysql:mysql *

(6)啟動檢查

[root@stu18 ~]
# mysql -uroot -pmypas
mysql> select * from coc;
+----+---------+----------+
| ID | ClassID | CourseID |
+----+---------+----------+
| 1|  1 |  2 |
| 2|  1 |  5 |
| 3|  2 |  2 |
| 4|  2 |  6 |
| 5|  3 |  1 |
| 6|  3 |  7 |
| 7|  4 |  5 |
| 8|  4 |  2 |
| 9|  5 |  1 |
| 10 |  5 |  9 |
| 11 |  6 |  3 |
| 12 |  6 |  4 |
| 13 |  7 |  4 |
| 14 |  7 |  3 |
+----+---------+----------+
14 rows in set (0.00 sec)

成果顯示數據准確完全,然則第三次的修改信息未失效。

(7)基於二進制日記完成數據恢復
檢查最初一次增量備份二進制日記地點的地位:

[root@stu18 data]
# cd /innobackup/2013-08-14_09-08-39/
[root@stu18 2013-08-14_09-08-39]
# cat xtrabackup_binlog_info
mysql-bin.000001 780

檢查二進制日記文件將未備份數據的二進制日記導出

[root@stu18 innobackup]
# mysqlbinlog mysql-bin.000001
# at 780
#130814 9:20:19 server id 1 end_log_pos 851 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1376443219/*!*/;
BEGIN
/*!*/;
# at 851
#130814 9:20:19 server id 1 end_log_pos 944 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1376443219/*!*/;
delete from coc where id=14
/*!*/;
# at 944
#130814 9:20:19 server id 1 end_log_pos 1016 Query thread_id=7 exec_time=0 error_code=0
SET TIMESTAMP=1376443219/*!*/;
COMMIT
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@stu18 innobackup]
# mysqlbinlog --start-position=780 mysql-bin.000001 > ./all.sql  #導出數據

恢單數據

[root@stu18 ~]
# mysql -uroot –pmypass
mysql> SET SQL_LOG_BIN=0;   
#封閉二進制日記
mysql> source /innobackup/all.sql 
#導入數據
mysql> SET SQL_LOG_BIN=1;   
#開啟二進制日記
mysql> select * from coc;   
#檢查數據,恢復完成
+----+---------+----------+
| ID | ClassID | CourseID |
+----+---------+----------+
| 1 |  1 |  2 |
| 2 |  1 |  5 |
| 3 |  2 |  2 |
| 4 |  2 |  6 |
| 5 |  3 |  1 |
| 6 |  3 |  7 |
| 7 |  4 |  5 |
| 8 |  4 |  2 |
| 9 |  5 |  1 |
| 10 |  5 |  9 |
| 11 |  6 |  3 |
| 12 |  6 |  4 |
| 13 |  7 |  4 |
+----+---------+----------+
13 rows in set (0.00 sec)

這類備份恢復方法完整以熱備的情勢完成完整備份和增量備份和二進制日記復原數據,而且恢復速度也很快,是最好的備份恢復方法!!

總結:以上三種備份恢復都是可以基於二進制日記文件停止的,因此表現出了二進制日記的主要性,從而映照出了日記的主要性;所以進修檢查應用日記文件是進修Mysql的重中之重!

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved