詳細內(nèi)容參見網(wǎng)址：http://www.jb51.net/article/41570.htm
優(yōu)勢：
1、快速可靠的進行完全備份2、在備份的過程中不會影響到事務(wù)3、支持數(shù)據(jù)流、網(wǎng)絡(luò)傳輸、壓縮，所以它可以有效的節(jié)約磁盤資源和網(wǎng)絡(luò)帶寬。4、可以自動備份校驗數(shù)據(jù)的可用性。
安裝：
Xtrabackup，查看另外的總結(jié)
4.1前提：（我們用這個工具一般都進行整個服務(wù)器的全備份，這步可以先不管。跳過直接進行備份就可以了。）
這步看之前先知道一些概念：
Innodb和myisam引擎的表與那些文件組成：
Myisqm表：
.frm 表結(jié)構(gòu)文件
.MYI表索引文件
.MYD表數(shù)據(jù)文件
Innodb表;
共享表空間存儲方式下：
.frm表結(jié)構(gòu)文件
.ibdata所有的innodb表的數(shù)據(jù)和索引存放的文件
獨立表空間存儲方式下：
.frm 表結(jié)構(gòu)文件
.ibd各表自己的數(shù)據(jù)和索引存放文件
共享表空間： Innodb的所有數(shù)據(jù)保存在一個單獨的表空間里面，而這個表空間可以由很多個文件組成（具體的表現(xiàn)是數(shù)據(jù)庫目錄下會有一個或幾個名字是ibdata1，ibdata2，ibdata3...具體多少是可以配置的，默認只有一個ibdata1文件，所有的innodb引擎的表數(shù)據(jù)和索引都會存到這幾個文件中），一個表或多個表可能跨多個文件存在，所以其大小限制不再是文件大小的限制和單個磁盤的限制，而是其自身的限制。從Innodb的官方文檔中可以看到，其表空間的最大限制為64TB，也就是說，Innodb的單表限制基本上也在64TB左右 了，當然這個大小是包括這個表的所有索引等其他相關(guān)數(shù)據(jù)。（這種方式存儲磁盤滿了，加上一塊，之后在新建個，新磁盤/ibdata* 文件就行了-新建的方式就是配置my.cnf文件重啟數(shù)據(jù)庫就行。不是特別簡單的。具體的加ibdata文件，在本目錄下的 ”innodb引擎共享空間存儲方式下的ibdata文件擴容.doc”查看詳細步驟或網(wǎng)址http://blog.csdn.net/zm2714/article/details/8479974/）
獨立表空間：每張innodb引擎的表都有自己的.ibd文件。數(shù)據(jù)和索引都存在這個文件中。這里引申個問題，當單個磁盤空間不足時。只能通過文件系統(tǒng)層面過的方法擴容。這里是用的技術(shù)是lvm。具體將會在文檔“l(fā)vm磁盤擴容-磁盤分區(qū)-磁盤掛載卸載-自動掛載.doc”中細總結(jié)。
應(yīng)該確定采用的是單表一個表空間，否則不支持單表的備份與恢復。在配置文件里邊的MySQLd段加上
innodb_file_per_table = 1
為搞懂，這里停留了很長時間。
這里意思是：這種備份方式支持單表備份和還原，但是前提是必須將配置文件中innodb_file_per_table = 1，設(shè)置成1。
---當這個變量設(shè)置成1時，所有的innodb引擎的表，在數(shù)據(jù)庫目錄中的存儲方式將會是‘獨立表空間存儲方式’——即每個innodb表將會獨有一個表空間。具體的表現(xiàn)是每個innodb表在數(shù)據(jù)庫目錄下都有個*.ibd的文件，這個文件就是這張表的獨立表空間，這張表的所有的數(shù)據(jù)和索引都會存儲在這個文件中。這樣以后每次建表時都會是一張表一個.ibd文件，那么就可以做單張的表的備份和恢復。
那這里其實是有問題的，如果我的數(shù)據(jù)庫中已經(jīng)有很多的數(shù)據(jù)了，并且之前并不是按照“獨立表空間的存儲方式存的”而是按照“共享表空間的存儲方式存的”，那么這時是不能單單修改了配置文件（innodb_file_per_table = 1）就行----關(guān)于共享表空間和獨立表空間具體細節(jié)參看（http://www.linuxidc.com/Linux/2015-01/111241.htm）。當時作者的意思是剛剛建立數(shù)據(jù)庫時要設(shè)置成這樣（innodb_file_per_table = 1）。
4.2備份策略：
完全備份+增量備份+二進制日志
4.3準備個目錄用于存放備份數(shù)據(jù)
復制代碼 代碼如下:
[root@www ~]# makdir /innobackup
4.4做完全備份：
復制代碼 代碼如下:
[root@www ~]# innobackupex --user=root --passWord=mypass /innobackup/
注：
1、只要在最后一行顯示 innobackupex: completed OK!，就說明你的備份是正確的。2、另外要注意的是每次備份之后，會自動在數(shù)據(jù)目錄下創(chuàng)建一個以當前時間點命名的目錄用于存放備份的數(shù)據(jù)，那我們?nèi)タ纯炊加惺裁?/p>
[root@www 2013-09-12_11-03-04]# lsbackup-my.cnf ibdata1 performance_schema xtrabackup_binary xtrabackup_checkpointshellodb mysql test xtrabackup_binlog_info xtrabackup_logfile[root@www 2013-09-12_11-03-04]#xtrabackup_checkpoints ：備份類型、備份狀態(tài)和LSN(日志序列號)范圍信息；xtrabackup_binlog_info ：mysql服務(wù)器當前正在使用的二進制日志文件及至備份這一刻為止二進制日志事件的位置。xtrabackup_logfile ：非文本文件，xtrabackup自己的日志文件xtrabackup_binlog_pos_innodb ：二進制日志文件及用于InnoDB或XtraDB表的二進制日志文件的當前position。backup-my.cnf ：備份時數(shù)據(jù)文件中關(guān)于mysqld的配置
#xtrabackup備份原理：
官方原理
在InnoDB內(nèi)部會維護一個redo日志文件，我們也可以叫做事務(wù)日志文件。事務(wù)日志會存儲每一個InnoDB表數(shù)據(jù)的記錄修改。當InnoDB啟動 時，InnoDB會檢查數(shù)據(jù)文件和事務(wù)日志，并執(zhí)行兩個步驟：它應(yīng)用（前滾）已經(jīng)提交的事務(wù)日志到數(shù)據(jù)文件，并將修改過但沒有提交的數(shù)據(jù)進行回滾操作。
xtrabackup在啟動時會記住log sequence number（LSN），并且復制所有的數(shù)據(jù)文件。復制過程需要一些時間，所以這期間如果數(shù)據(jù)文件有改動，那么將會使數(shù)據(jù)庫處于一個不同的時間點。這 時，xtrabackup會運行一個后臺進程，用于監(jiān)視事務(wù)日志，并從事務(wù)日志復制最新的修改。xtrabackup必須持續(xù)的做這個操作，是因為事務(wù)日 志是會輪轉(zhuǎn)重復的寫入，并且事務(wù)日志可以被重用。所以xtrabackup自啟動開始，就不停的將事務(wù)日志中每個數(shù)據(jù)文件的修改都記錄下來。
上面就是xtrabackup的備份過程。接下來是準備（PRepare）過程。在這個過程中，xtrabackup使用之前復制的事務(wù)日志，對各個數(shù)據(jù)文件執(zhí)行災(zāi)難恢復（就像MySQL剛啟動時要做的一樣）。當這個過程結(jié)束后，數(shù)據(jù)庫就可以做恢復還原了。
以上的過程在xtrabackup的編譯二進制程序中實現(xiàn)。程序innobackupex可以允許我們備份MyISAM表和frm文件從而增加了便捷和功 能。Innobackupex會啟動xtrabackup，直到xtrabackup復制數(shù)據(jù)文件后，然后執(zhí)行FLUSH TABLES WITH READ LOCK來阻止新的寫入進來并把MyISAM表數(shù)據(jù)刷到硬盤上，之后復制MyISAM數(shù)據(jù)文件，最后釋放鎖。
備份MyISAM和InnoDB表最終會處于一致，在準備（prepare）過程結(jié)束后，InnoDB表數(shù)據(jù)已經(jīng)前滾到整個備份結(jié)束的點，而不是回滾到xtrabackup剛開始時的點。這個時間點與執(zhí)行FLUSH TABLES WITH READ LOCK的時間點相同，所以MyISAM表數(shù)據(jù)與InnoDB表數(shù)據(jù)是同步的。類似Oracle的，InnoDB的prepare過程可以稱為recover（恢復），MyISAM的數(shù)據(jù)復制過程可以稱為restore（還原）。
xtrabackup和innobackupex這兩個工具都提供了許多前文沒有提到的功能特點。手冊上有對各個功能都有詳細的介紹。簡單介紹下，這些工 具提供了如流（streaming）備份，增量（incremental）備份等，通過復制數(shù)據(jù)文件，復制日志文件和提交日志到數(shù)據(jù)文件（前滾）實現(xiàn)了各 種復合備份方式。
xtrabackup詳細的原理請參見：http://sofar.blog.51cto.com/353572/1313649
4.5回到mysql服務(wù)器端對數(shù)據(jù)進行更新操作
復制代碼 代碼如下:
mysql> use hellodb; mysql> delete from students where StuID>=24;
4.6增量備份
復制代碼 代碼如下:
innobackupex --user=root --password=mypass --incremental /innobackup/--incremental-basedir=/innobackup/2013-09-12_11-03-04/--incremental 指定備份類型 --incremental-basedir= 指定這次增量備份是基于哪一次備份的，這里是完全備份文件,這樣可以把增量備份的數(shù)據(jù)合并到完全備份中去
“--incremental-basedir”這個參數(shù)名字變了運行innobackupex --help查看
4.7第二次增量
先去修改數(shù)據(jù)
復制代碼 代碼如下:
mysql> insert into students (Name,Age,Gender,ClassID,TeacherID) values ('tom',33,'M',2,4);innobackupex --user=root --password=mypass --incremental /innobackup/ --incremental-basedir=/innobackup/2013-09-12_11-37-01/ 這里只須要把最后的目錄改為第一次增量備份的數(shù)據(jù)目錄即可
“--incremental-basedir”這個參數(shù)名字變了運行innobackupex --help查看
4.8最后一次對數(shù)據(jù)更改但是沒做增量備份
復制代碼 代碼如下:
mysql> delete from coc where id=14;
4.9把二進制日志文件備份出來，(因為最后一次修改，沒做增量備份，要依賴二進制日志做時間點恢復)
復制代碼 代碼如下:
[root@www data]# cp mysql-bin.000003 /tmp/
4.10模擬數(shù)據(jù)庫崩潰
復制代碼 代碼如下:
[root@www data]# service mysqld stop [root@www data]# rm -rf *
恢復前準備：重點這個必須有
4.11對完全備份做數(shù)據(jù)同步
復制代碼 代碼如下:
[root@www ~]# innobackupex --apply-log --redo-only/innobackup/2013-09-12_11-03-04/
4.12對第一次增量做數(shù)據(jù)同步
復制代碼 代碼如下:
innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-37-01/
“--incremental-basedir”這個參數(shù)名字變了運行innobackupex --help查看
4.13對第二次增量做數(shù)據(jù)同步
復制代碼 代碼如下:
innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-45-53/--apply-log 的意義在于把備份時沒commit的事務(wù)撤銷，已經(jīng)commit的但還在事務(wù)日志中的應(yīng)用到數(shù)據(jù)庫
“--incremental-basedir”這個參數(shù)名字變了運行innobackupex --help查看
###############################################
注：
對于xtrabackup來講，它是基于事務(wù)日志和數(shù)據(jù)文件備份的，備份的數(shù)據(jù)中可能會包含尚未提交的事務(wù)或已經(jīng)提交但尚未同步至數(shù)據(jù)庫文件中的事務(wù)，還應(yīng)該對其做預處理，把已提交的事務(wù)同步到數(shù)據(jù)文件，未提交的事務(wù)要回滾。因此其備份的數(shù)據(jù)庫，不能立即拿來恢復。
預處理的過程：
首先對完全備份文件只把已提交的事務(wù)同步至數(shù)據(jù)文件，要注意的是有增量的時候，不能對事務(wù)做數(shù)據(jù)回滾，不然你的增量備份就沒有效果了。
然后把第一次的增量備份合并到完全備份文件內(nèi)，
以此類推，把后幾次的增量都合并到前一次合并之后的文件中，這樣的話，我們只要拿著完全備份+二進制日志，就可以做時間點恢復。
為什么要恢復前準備：xtrabackup在啟動時會記住log sequence number（LSN），并且復制所有的數(shù)據(jù)文件。復制過程需要一些時間，所以這期間如果數(shù)據(jù)文件有改動，那么將會使數(shù)據(jù)庫處于一個不同的時間點。這 時，xtrabackup會運行一個后臺進程，用于監(jiān)視事務(wù)日志，并從事務(wù)日志復制最新的修改。
備 份MyISAM和InnoDB表最終會處于一致，在準備（prepare）過程結(jié)束后，InnoDB表數(shù)據(jù)已經(jīng)前滾到整個備份結(jié)束的點，而不是回滾到xtrabackup剛開始時的點。這個時間點與執(zhí)行FLUSH TABLES WITH READ LOCK的時間點相同，所以MyISAM表數(shù)據(jù)與InnoDB表數(shù)據(jù)是同步的。類似Oracle的，InnoDB的prepare過程可以稱為recover（恢復），MyISAM的數(shù)據(jù)復制過程可以稱為restore（還原）。
個人理解：備份完成時，備份的數(shù)據(jù)是備份開始時間點的樣子，在備份過程中數(shù)據(jù)的變化會記錄到事務(wù)日志中。因此你備份的數(shù)據(jù)庫不能直接使用必須要recover（恢復），恢復完成之后那么備份的數(shù)據(jù)庫的狀態(tài)就是你備份結(jié)束時的樣子。備份結(jié)束后的數(shù)據(jù)改變就只能指望二進制文件了。所以還要把當時的那個二進制文件拷貝出來，用于進行精確地時間恢復。或者位置恢復。
4.14數(shù)據(jù)恢復
復制代碼 代碼如下:
[root@www ~]# service mysqld stop [root@www data]# rm -rf * 模擬數(shù)據(jù)庫崩潰 [root@www ~]# innobackupex --copy-back /innobackup/2013-09-12_11-03-04/ --copy-back數(shù)據(jù)庫恢復，后面跟上備份目錄的位置
4.15檢測：
復制代碼 代碼如下:
[root@www ~]# cd /mydata/data/ [root@www data]# chown mysql:mysql * [root@www data]#service mysqld start
注：必須更改好數(shù)據(jù)目錄下所有文件的屬主和屬組，否則無法啟動。
前邊就完成了完全備份和恢復，但之前那個二進制文件文件怎么辦，干什么用。做基于時間點的恢復。詳細使用請參見：
http://blog.sina.com.cn/s/blog_62a24b6801013vcy.html
mysqlbinlog --stop-date="2009-09-01 00:00:00" /mysqldata/mysql-bin.000009 | mysql -u root -p
參考過程：
一、全部數(shù)據(jù)庫
備份：
innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf /data/mysql_backup/full_backup
二、指定數(shù)據(jù)庫
備份:
假如我們要備份centos和aabb數(shù)據(jù)庫。
innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf --databases="centos aabb" /data/mysql_backup/
這樣就會在/data/mysql_backup生成一個帶時間的目錄，如果不需要帶時間，可以使用選項–no-timestamp。
如果想備份成壓縮文件，可以使用如下語句：
innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf --databases="centos aabb" --no-timestamp --stream=tar ./ | gzip - > centos-aabb.bz.tar.gz
innobackupex --defaults-file=/etc/my.cnf --user=root --host=127.0.0.1 --password='' --databases="lidonghai mysql" --slave-info --safe-slave-backup --stream=tar /data/innobackup/ > /data/innobackup/test.tar.gz
參數(shù)：
--slave-info這個參數(shù)在對從數(shù)據(jù)庫進行備份時使用，可以保存主數(shù)據(jù)庫當前的二進制文件和偏移量。這樣可以減輕主數(shù)據(jù)庫因備份二壓力過大。其他參數(shù)自行查看。需要注意的是，你的數(shù)據(jù)庫超時設(shè)定會對備份有影響。在備份結(jié)束的時候快要結(jié)束的時候，有時候可能會因為你的數(shù)據(jù)庫連接超時而中斷，造成備份失敗。所以把數(shù)據(jù)庫超時設(shè)定加大才好，不要過短。
innobackupex --defaults-file=/data/mysql/my.cnf --user=root --host=172.168.1.51 --password=horizoompassword --slave-info --safe-slave-backup --stream=tar /data/innobackup/ > /data/innobackup/fullbackup.tar.gz
tar -ixf test.tar.gz -C /data/innobackup/test
innobackupex --apply-log --redo-only /data/innobackup/test
innobackupex --copy-back /data/innobackup/test --user=root --host=127.0.0.1 --password='' #--force-non-empty-directories這個選項失敗了不知道怎么回事，可以的話已更改能部分恢復數(shù)據(jù)庫。最后我手動將目錄拷回來改了權(quán)限就行了，當人如果不行的話就直單個表單個表的回復。
所以盡量用完全備份。
4.14數(shù)據(jù)恢復
注意：需要指定配置文件，否則找不到要還原的目錄
復制代碼 代碼如下:
[root@www ~]# service mysqld stop
[root@www data]# rm -rf * 模擬數(shù)據(jù)庫崩潰
[root@www ~]# innobackupex --defaults-file=/usr/my.cnf --copy-back /innobackup/2013-09-12_11-03-04/
--copy-back數(shù)據(jù)庫恢復，后面跟上備份目錄的位置
4.15檢測：
復制代碼 代碼如下:
[root@www ~]# cd /mydata/data/
[root@www data]# chown mysql:mysql *
[root@www data]#service mysqld start
##################################################
基于完全備份后的單表恢復，這種恢復方式前提是問題表沒有被重建過
參看網(wǎng)址：http://www.zhongweicheng.com/?p=1284
First, you must meet certain prerequisites to be able to restore a ibd tablespace:1.The ibd file must be from a consistent backup with all insert buffer entries merged and have no uncommitted transactions in order to not be dependent of the shared 2.tablespace ibdata. That is, shutting down with innodb_fast_shutdown=0. We’ll use XtraBackup to avoid the server shutdown.3.You must not drop, truncate or alter the schema of the table after the backup has been taken.The variable innodb_file_per_table must be enabled.[root@test bin]# ./innobackupex –defaults-file=/service/mysql5.5/my.cnf –export /backup/5.5/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. This software is published under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991. 131125 19:50:23 innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_file=/service/mysql5.5/my.cnf;mysql_read_default_group=xtrabackup' (using password: NO). 131125 19:50:23 innobackupex: Connected to MySQL server IMPORTANT: Please check that the backup run completes successfully. At the end of a successful backup run innobackupex prints "completed OK!". innobackupex: Using mysql server version 5.5.25-log innobackupex: Created backup directory /backup/5.5/2013-11-25_19-50-23 131125 19:50:23 innobackupex: Starting ibbackup with command: xtrabackup_55 –defaults-file="/service/mysql5.5/my.cnf" –defaults-group="mysqld" –backup –suspend-at-end –target-dir=/backup/5.5/2013-11-25_19-50-23 –tmpdir=/tmp innobackupex: Waiting for ibbackup (pid=13361) to suspend innobackupex: Suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_suspended_2' xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680) xtrabackup: uses posix_fadvise(). xtrabackup: cd to /data/mysql5.5 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 3 xtrabackup: innodb_log_file_size = 5242880 >> log scanned up to (1600610) [01] Copying ./ibdata1 to /backup/5.5/2013-11-25_19-50-23/ibdata1 [01] …done [01] Copying ./test/t2.ibd to /backup/5.5/2013-11-25_19-50-23/test/t2.ibd [01] …done >> log scanned up to (1600610) xtrabackup: Creating suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_suspended_2' with pid '13361' 131125 19:50:25 innobackupex: Continuing after ibbackup has suspended 131125 19:50:25 innobackupex: Starting to lock all tables… 131125 19:50:25 innobackupex: All tables locked and flushed to disk 131125 19:50:25 innobackupex: Starting to backup non-InnoDB tables and files innobackupex: in subdirectories of '/data/mysql5.5' innobackupex: Backing up file '/data/mysql5.5/test/t2.frm' innobackupex: Backing up files '/data/mysql5.5/mysql/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files) >> log scanned up to (1600610) innobackupex: Backing up files '/data/mysql5.5/performance_schema/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files) 131125 19:50:26 innobackupex: Finished backing up non-InnoDB tables and files 131125 19:50:26 innobackupex: Waiting for log copying to finish xtrabackup: The latest check point (for incremental): '1600610' xtrabackup: Stopping log copying thread. .>> log scanned up to (1600610) xtrabackup: Creating suspend file '/backup/5.5/2013-11-25_19-50-23/xtrabackup_log_copied' with pid '13361' xtrabackup: Transaction log of lsn (1600610) to (1600610) was copied. 131125 19:50:27 innobackupex: All tables unlocked innobackupex: Backup created in directory '/backup/5.5/2013-11-25_19-50-23' innobackupex: MySQL binlog position: filename 'ZWC-TEST.000003', position 420 131125 19:50:27 innobackupex: Connection to database server closed 131125 19:50:27 innobackupex: completed OK!
Truncate t2 tableroot@test 07:52:19>show create table t2/G *************************** 1. row *************************** Table: t2 Create Table: CREATE TABLE `t2` ( `id` int(11) NOT NULL, `name` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.00 sec) root@test 07:52:28>select count(*) from t2; +———-+ | count(*) | +———-+ | 2 | +———-+ 1 row in set (0.00 sec) root@test 07:52:36>alter table t2 discard tablespace; Query OK, 0 rows affected (0.00 sec) root@test 07:52:46>select count(*) from t2; ERROR 1030 (HY000): Got error -1 from storage engine
Begin recovery t2Then apply the logs to get a consistent backup.[root@test bin]# ./innobackupex –defaults-file=/service/mysql5.5/my.cnf –apply-log –export /backup/5.5/2013-11-25_19-50-23/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. This software is published under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991. IMPORTANT: Please check that the apply-log run completes successfully. At the end of a successful apply-log run innobackupex prints "completed OK!". 131125 19:53:30 innobackupex: Starting ibbackup with command: xtrabackup_55 –defaults-file="/service/mysql5.5/my.cnf" –defaults-group="mysqld" –prepare –target-dir=/backup/5.5/2013-11-25_19-50-23 –export –tmpdir=/tmp xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680) xtrabackup: cd to /backup/5.5/2013-11-25_19-50-23 xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1600610) xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 2097152 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 2097152 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory parameter) 131125 19:53:30 InnoDB: The InnoDB memory heap is disabled 131125 19:53:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins 131125 19:53:30 InnoDB: Compressed tables use zlib 1.2.3 131125 19:53:30 InnoDB: Initializing buffer pool, size = 100.0M 131125 19:53:30 InnoDB: Completed initialization of buffer pool 131125 19:53:30 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 131125 19:53:30 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003 131125 19:53:30 InnoDB: Waiting for the background threads to start 131125 19:53:31 Percona XtraDB (http://www.percona.com) 5.5.31-29.3 started; log sequence number 1600610 xtrabackup: export option is specified. xtrabackup: export metadata of table 'test/t2' to file `./test/t2.exp` (1 indexes) xtrabackup: name=PRIMARY, id.low=15, page=3 [notice (again)] If you use binary log and don't use any hack of group commit, the binary log position seems to be: InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003 xtrabackup: starting shutdown with innodb_fast_shutdown = 0 131125 19:53:31 InnoDB: Starting shutdown… 131125 19:53:35 InnoDB: Shutdown completed; log sequence number 1601824 131125 19:53:35 innobackupex: Restarting xtrabackup with command: xtrabackup_55 –defaults-file="/service/mysql5.5/my.cnf" –defaults-group="mysqld" –prepare –target-dir=/backup/5.5/2013-11-25_19-50-23 –export –tmpdir=/tmp for creating ib_logfile* xtrabackup_55 version 2.1.5 for Percona Server 5.5.31 Linux (x86_64) (revision id: 680) xtrabackup: cd to /backup/5.5/2013-11-25_19-50-23 xtrabackup: This target seems to be already prepared. xtrabackup: notice: xtrabackup_logfile was already used to '–prepare'. xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 3 xtrabackup: innodb_log_file_size = 5242880 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 3 xtrabackup: innodb_log_file_size = 5242880 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 104857600 bytes for buffer pool (set by –use-memory parameter) 131125 19:53:35 InnoDB: The InnoDB memory heap is disabled 131125 19:53:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins 131125 19:53:35 InnoDB: Compressed tables use zlib 1.2.3 131125 19:53:35 InnoDB: Initializing buffer pool, size = 100.0M 131125 19:53:35 InnoDB: Completed initialization of buffer pool 131125 19:53:35 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait… 131125 19:53:35 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait… 131125 19:53:35 InnoDB: Log file ./ib_logfile2 did not exist: new to be created InnoDB: Setting log file ./ib_logfile2 size to 5 MB InnoDB: Database physically writes the file full: wait… 131125 19:53:35 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 131125 19:53:35 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003 131125 19:53:35 InnoDB: Waiting for the background threads to start 131125 19:53:36 Percona XtraDB (http://www.percona.com) 5.5.31-29.3 started; log sequence number 1602060 xtrabackup: export option is specified. xtrabackup: export metadata of table 'test/t2' to file `./test/t2.exp` (1 indexes) xtrabackup: name=PRIMARY, id.low=15, page=3 [notice (again)] If you use binary log and don't use any hack of group commit, the binary log position seems to be: InnoDB: Last MySQL binlog file position 0 420, file name ./ZWC-TEST.000003 xtrabackup: starting shutdown with innodb_fast_shutdown = 0 131125 19:53:36 InnoDB: Starting shutdown… 131125 19:53:40 InnoDB: Shutdown completed; log sequence number 1602060 131125 19:53:40 innobackupex: completed OK!
Copy the t2.ibd files from the backup to the database data directory[root@test bin]# cp /backup/5.5/2013-11-25_19-50-23/test/t2.ibd /data/mysql5.5/test/ [root@test bin]# chown mysql.mysql /data/mysql5.5/test/t2.ibd
Import tablespace.root@test 07:55:55>select count(*) from t2; ERROR 1030 (HY000): Got error -1 from storage engine root@test 07:55:56> root@test 07:55:56> root@test 07:55:57>alter table t2 import tablespace; Query OK, 0 rows affected (0.00 sec) root@test 07:56:04>select count(*) from t2; +———-+ | count(*) | +———-+ | 2 | +———-+ 1 row in set (0.00 sec) root@test 07:56:08>select * from t2; +—-+——+ | id | name | +—-+——+ | 1 | aaa | | 2 | bbb | +—-+——+ 2 rows in set (0.00 sec) root@test 07:56:13>
提到流備份(streaming)就要說遠程備份和備份壓縮，先說流備份吧。
流備份是指備份的數(shù)據(jù)通過標準輸出STDOUT傳輸給tar程序進行歸檔，而不是單純的將數(shù)據(jù)文件保存到指定的備份目錄中，參數(shù)--stream=tar表示開啟流備份功能并打包。同時也可以利用流備份到遠程服務(wù)器上。
舉例來說，
$innobackupex --stream=TAR${BACKUP_DIR}/base | gzip > ${BACKUP_DIR}/base.tar.gz$ innobackupex --stream=TAR${BACKUP_DIR}/base|ssh somebackupaddr “cat > ${DIR}/base.tar”
在我們現(xiàn)實使用中，更多的使用增量備份，至于歸檔壓縮我們可以通過腳本自主完成。
基于單表備份的單表恢復（這里可有流備份），前提也是問題表沒有被重新建立過。否則是不會成功的。
建好備份目錄；mkdir /data/backup -p
壓縮備份：
innobackupex --user=root --password=simlinux.com --defaults-file=/etc/my.cnf --include='se.searchaccount' --slave-info --safe-slave-backup --stream=tar /data/backup > /data/backup/searchaccount.tar.gz
參數(shù)：--safe-slave-backup 備份slave:
Stop slave SQL thread and wait to start backup until
Slave_open_temp_tables in "SHOW STATUS" is zero. If there
are no open temporary tables, the backup will take place,
otherwise the SQL thread will be started and stopped
until there are no open temporary tables. The backup will
fail if Slave_open_temp_tables does not become zero after
--safe-slave-backup-timeout seconds. The slave SQL thread
will be restarted when the backup finishes.
新建個目錄-mkdir /data/databak;
解壓備份到干凈的目錄：
tar -ixf searchaccount.tar.gz -C /data/databak/
導出表:innobackupex --apply-log --export /data/databak
查看下： ll /data/databak/se
里邊的.ibd文件是我們需要的。
模擬原來的數(shù)據(jù)表損壞：
mysql > ALTER TABLE se.searchaccount DISCARD TABLESPACE;
拷貝要恢復的表的.ibd文件到數(shù)據(jù)庫目錄下：
cp /data/databak/se/{searchaccount.ibd,searchaccount.cfg} /usr/local/mysql/data
改變拷貝過去的.ibd文件的屬主和屬組：
chown mysql.mysql ...ibd文件。必須改。
導入表：強調(diào)下這個問題表沒有被重新建立過才會成功
ALTER TABLE se.searchaccount IMPORT TABLESPACE;
#######################################
如果問題表是被誤刪除的那么恢復的時候是有點復雜的，不管是從完全備份那里恢復還是從單表備份哪里恢復，都是一樣的。
如果問題表被刪除了，那么與上邊的恢復差別就是在最后導入表的部分。
表被刪除了的話，恢復是需要修復數(shù)據(jù)庫目錄下的ibdata1文件的。
修復工具是需要安裝的，工具下載地址：https://launchpad.net/percona-data-recovery-tool-for-innodb/+download
一.安裝：.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz.cd percona-data-recovery-tool-for-innodb-0/mysql-source/../configure.cd percona-data-recovery-tool-for-innodb-0.make
具體的操作步驟參見：
http://www.educity.cn/shujuku/692845.html
http://www.jb51.net/article/31877.htm
下面的兩步相當于上面那些恢復方式的最后一步“導入表”--替換下就可以了
使用percona recovery tool 修改ibdata：(我感覺這里并不是修改ibdata，而是通過ibdata1和A.ibd文件來恢復A表原來的數(shù)據(jù)。)
./ibdconnect -o /var/lib/mysql/ibdata1 -f /var/lib/mysql/test/A.ibd -d test -t A
使用percona recovery tool 重新checksum ibdata。這一步需要多次執(zhí)行直到?jīng)]有輸出信息為止。（這里是將事務(wù)日志文件中還沒有提交的事務(wù)redo到硬盤數(shù)據(jù)頁中。因為內(nèi)存中的臟頁由于之前的故障不可用了（本來應(yīng)該由chakpoint機制來將內(nèi)存緩沖區(qū)的臟頁數(shù)據(jù)刷新到硬盤中的）。）
./innochecksum -f /var/lib/mysql/ibdata1
#####################################################
August 29th, 2013 hidba
昨晚收到一則求助，一個用戶的本地數(shù)據(jù)庫的重要數(shù)據(jù)由于誤操作被刪除，需要進行緊急恢復，用戶的數(shù)據(jù)庫日常并沒有進行過任何備份，binlog也沒有開啟，所以從備份和binlog入手已經(jīng)成為不可能，咨詢了丁奇，發(fā)了一篇percona的文章給我，頓時感覺有希望，于是到percona的官網(wǎng)上下載了恢復工具：一.安裝：.tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz.cd percona-data-recovery-tool-for-innodb-0/mysql-source/../configure.cd percona-data-recovery-tool-for-innodb-0.make
二.解析ibd文件：此過程會將表的idb文件解析為很多的page，innodb的page分為兩大部分，一部分一級索引部分（primary key），另一部分為二級索引部分（secondary key），所以解析出來的idb包括了主鍵數(shù)據(jù)和索引數(shù)據(jù)兩大部分（如果該表有多個二級索引，則會生成多個文件）./page_parser -5 -f t_bibasic_storage.ibd參數(shù)解釋：-5：代表 row format為Compact-f：代表要解析的文件結(jié)果如下：pages-1377707810/FIL_PAGE_INDEX0-161 0-325 0-463 0-464 0-465可以看到t_bibasic_storage.ibd解析出來5個文件（161為主鍵索引的index_id,325,463,464,465為二級索引的index_id,該id可以通過開啟innodb_table_monitor知曉）
三.生成表定義：由于該工具在解析數(shù)據(jù)pages的時候，需要獲得該table的表結(jié)構(gòu)定義，所以需要執(zhí)行如下命令：./create_defs.pl –host xxxx –port 3306 –user root –password xxx –db didb –table t_bibasic_storage >include/table_defs.h上面的命令會將t_bibasic_storage表的表結(jié)構(gòu)定義傳入到table_defs.h中，在生成了表結(jié)構(gòu)定義后，重新make該恢復工具：.make
四.開始恢復pages中刪除的數(shù)據(jù)：在重新編譯工具后，執(zhí)行如下命令：./constraints_parser -5 -D -f pages-1377707810/FIL_PAGE_INDEX/0-161 >/tmp/t_bibasic_salessend.sql參數(shù)：-5 -f的參數(shù)和page_parser相同；-D:該參數(shù)的含義為代表恢復刪除的數(shù)據(jù)頁；
恢復完成后生成如下語句和文件：LOAD DATA INFILE ‘/tmp/t_bibasic_proinfo.dmp’ REPLACE INTO TABLE `t_bibasic_proinfo` FIELDS TERMINATED BY ‘/t’ OPTIONALLY ENCLOSED BY ‘”‘ LINES STARTING BY ‘t_bibasic_proinfo/t’ (id, procode, skuoid, skucode, skuname, catatt, dutydepoid, dutydepname, seasonatt, brandatt, prostatus, choosedate, syear, smonth, sday, created, unioncomcode);
/tmp/t_bibasic_salessend.sql 該文件就是我們需要load data的文本文件；
總結(jié)：1）。該恢復工具只支持innodb存儲引擎，文件的格式需要為：Compact2）。數(shù)據(jù)被誤刪除后，需要盡快將保護現(xiàn)場，停止數(shù)據(jù)庫，把idb文件拷貝出來，防止ibd文件寫入數(shù)據(jù)被覆蓋（筆者恢復的一個表中，由于數(shù)據(jù)刪除后，表中仍有大量寫入，導致大部分數(shù)據(jù)沒有恢復出來）；3）。千叮囑萬囑咐，數(shù)據(jù)庫的備份重于泰山；
新聞熱點
疑難解答
圖片精選
