innobackup 備份還原原理和操作

3/7/2017來源:SQL技巧人氣:4573

 

詳細內容參見網址:http://www.jb51.net/article/41570.htm

 

優勢:

1、快速可靠的進行完全備份 2、在備份的過程中不會影響到事務 3、支持數據流、網絡傳輸、壓縮,所以它可以有效的節約磁盤資源和網絡帶寬。 4、可以自動備份校驗數據的可用性。

安裝:

男人的天堂 AV电影Xtrabackup,查看另外的總結

 

 

4.1前提:(我們用這個工具一般都進行整個服務器的全備份,這步可以先不管。跳過直接進行備份就可以了。)

 

 

這步看之前先知道一些概念:

男人的天堂 AV电影Innodb和myisam引擎的表與那些文件組成:

Myisqm表:

.frm 表結構文件

.MYI表索引文件

.MYD表數據文件

 

 

Innodb表;

男人的天堂 AV电影共享表空間存儲方式下:

.frm表結構文件

男人的天堂 AV电影.ibdata所有的innodb表的數據和索引存放的文件

男人的天堂 AV电影獨立表空間存儲方式下:

.frm 表結構文件

.ibd各表自己的數據和索引存放文件

 

 

 

 

共享表空間: Innodb的所有數據保存在一個單獨的表空間里面,而這個表空間可以由很多個文件組成(具體的表現是數據庫目錄下會有一個或幾個名字是ibdata1,ibdata2,ibdata3...具體多少是可以配置的,默認只有一個ibdata1文件,所有的innodb引擎的表數據和索引都會存到這幾個文件中),一個表或多個表可能跨多個文件存在,所以其大小限制不再是文件大小的限 制和單個磁盤的限制,而是其自身的限制。從Innodb的官方文檔中可以看到,其表空間的最大限制為64TB,也就是說,Innodb的單表限制基本上也在64TB左右 了,當然這個大小是包括這個表的所有索引等其他相關數據。(這種方式存儲磁盤滿了,加上一塊,之后在新建個,新磁盤/ibdata* 文件就行了-新建的方式就是配置my.cnf文件重啟數據庫就行。不是特別簡單的。具體的加ibdata文件,在本目錄下的   ”innodb引擎共享空間存儲方式下的ibdata文件擴容.doc”查看詳細步驟或網址http://blog.csdn.net/zm2714/article/details/8479974/)

 

獨立表空間:每張innodb引擎的表都有自己的.ibd文件。數據和索引都存在這個文件中。這里引申個問題,當單個磁盤空間不足時。只能通過文件系統層面過的方法擴容。這里是用的技術是lvm。具體將會在文檔“lvm磁盤擴容-磁盤分區-磁盤掛載卸載-自動掛載.doc”中細總結。

 

 

 

 

應該確定采用的是單表一個表空間,否則不支持單表的備份與恢復。 在配置文件里邊的MySQLd段加上

男人的天堂 AV电影innodb_file_per_table = 1

為搞懂,這里停留了很長時間。

這里意思是:這種備份方式支持單表備份和還原,但是前提是必須將配置文件中innodb_file_per_table = 1,設置成1。

---當這個變量設置成1時,所有的innodb引擎的表,在數據庫目錄中的存儲方式將會是‘獨立表空間存儲方式’——即每個innodb表將會獨有一個表空間。具體的表現是每個innodb表在數據庫目錄下都有個*.ibd的文件,這個文件就是這張表的獨立表空間,這張表的所有的數據和索引都會存儲在這個文件中。這樣以后每次建表時都會是一張表一個.ibd文件,那么就可以做單張的表的備份和恢復。

那這里其實是有問題的,如果我的數據庫中已經有很多的數據了,并且之前并不是按照“獨立表空間的存儲方式存的”而是按照“共享表空間的存儲方式存的”,那么這時是不能單單修改了配置文件(innodb_file_per_table = 1)就行----關于共享表空間和獨立表空間具體細節參看(http://www.linux男人的天堂 AV电影idc.com/Linux/2015-01/111241.htm)。當時作者的意思是剛剛建立數據庫時要設置成這樣(innodb_file_per_table = 1)。

 

4.2備份策略:

 

完全備份+增量備份+二進制日志

 

 

4.3準備個目錄用于存放備份數據

復制代碼男人的天堂 AV电影 代碼如下:

[root@www ~]# makdir /innobackup

 

 

4.4做完全備份:

復制代碼 代碼如下:

[root@www ~]# innobackupex --user=root --passWord=mypass   /innobackup/

注:

1、只要在最后一行顯示 innobackupex: completed OK!,就說明你的備份是正確的。 2、另外要注意的是每次備份之后,會自動在數據目錄下創建一個以當前時間點命名的目錄用于存放備份的數據,那我們去看看都有什么

男人的天堂 AV电影[root@www 2013-09-12_11-03-04]# ls backup-my.cnf ibdata1 performance_schema xtrabackup_binary xtrabackup_checkpoints hellodb mysql test xtrabackup_binlog_info xtrabackup_logfile [root@www 2013-09-12_11-03-04]# xtrabackup_checkpoints :備份類型、備份狀態和LSN(日志序列號)范圍信息; xtrabackup_binlog_info :mysql服務器當前正在使用的二進制日志文件及至備份這一刻為止二進制日志事件的位置。 xtrabackup_logfile :非文本文件,xtrabackup自己的日志文件 xtrabackup_binlog_pos_innodb :二進制日志文件及用于InnoDB或XtraDB表的二進制日志文件的當前position。 backup-my.cnf :備份時數據文件中關于mysqld的配置

 

#xtrabackup備份原理:

官方原理

男人的天堂 AV电影在InnoDB內部會維護一個redo日志文件,我們也可以叫做事務日志文件。事務日志會存儲每一個InnoDB表數據的記錄修改。當InnoDB啟動 時,InnoDB會檢查數據文件和事務日志,并執行兩個步驟:它應用(前滾)已經提交的事務日志到數據文件,并將修改過但沒有提交的數據進行回滾操作。

 

xtrabackup在啟動時會記住log sequence number(LSN),并且復制所有的數據文件。復制過程需要一些時間,所以這期間如果數據文件有改動,那么將會使數據庫處于一個不同的時間點。這 時,xtrabackup會運行一個后臺進程,用于監視事務日志,并從事務日志復制最新的修改。xtrabackup必須持續的做這個操作,是因為事務日 志是會輪轉重復的寫入,并且事務日志可以被重用。所以xtrabackup自啟動開始,就不停的將事務日志中每個數據文件的修改都記錄下來。

 

男人的天堂 AV电影上面就是xtrabackup的備份過程。接下來是準備(epare)過程。在這個過程中,xtrabackup使用之前復制的事務日志,對各個數據文件執行災難恢復(就像MySQL剛啟動時要做的一樣)。當這個過程結束后,數據庫就可以做恢復還原了。

以上的過程在xtrabackup的編譯二進制程序中實現。程序innobackupex可以允許我們備份MyISAM表和frm文件從而增加了便捷和功 能。Innobackupex會啟動xtrabackup,直到xtrabackup復制數據文件后,然后執行FLUSH TABLES WITH READ LOCK來阻止新的寫入進來并把MyISAM表數據刷到硬盤上,之后復制MyISAM數據文件,最后釋放鎖。

 

備份MyISAM和InnoDB表最終會處于一致,在準備(prepare)過程結束后,InnoDB表數據已經前滾到整個備份結束的點,而不是回滾到 xtrabackup剛開始時的點。這個時間點與執行FLUSH TABLES WITH READ LOCK的時間點相同,所以MyISAM表數據與InnoDB表數據是同步的。類似Oracle的,InnoDB的prepare過程可以稱為recover(恢復),MyISAM的數據復制過程可以稱為restore(還原)。

 

xtrabackup和innobackupex這兩個工具都提供了許多前文沒有提到的功能特點。手冊上有對各個功能都有詳細的介紹。簡單介紹下,這些工 具提供了如流(streaming)備份,增量(incremental)備份等,通過復制數據文件,復制日志文件和提交日志到數據文件(前滾)實現了各 種復合備份方式。

xtrabackup詳細的原理請參見:http://sofar.blog.51cto.com/353572/1313649

 

 

男人的天堂 AV电影4.5回到mysql服務器端對數據進行更新操作

復制代碼男人的天堂 AV电影 代碼如下:

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= 指定這次增量備份是基于哪一次備份的,這里是完全備份文件,這樣可以把增量備份的數據合并到完全備份中去

“--incremental-basedir”這個參數名字變了運行innobackupex --help查看

 

4.7第二次增量

先去修改數據

復制代碼 代碼如下:

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/  這里只須要把最后的目錄改為第一次增量備份的數據目錄即可

“--incremental-basedir”這個參數名字變了運行innobackupex --help查看

 

4.8最后一次對數據更改但是沒做增量備份

復制代碼男人的天堂 AV电影 代碼如下:

男人的天堂 AV电影mysql> delete from coc where id=14;

4.9把二進制日志文件備份出來,(因為最后一次修改,沒做增量備份,要依賴二進制日志做時間點恢復)

復制代碼男人的天堂 AV电影 代碼如下:

[root@www data]# cp mysql-bin.000003 /tmp/

 

 

男人的天堂 AV电影4.10模擬數據庫崩潰

復制代碼 代碼如下:

[root@www data]# service mysqld stop [root@www data]# rm -rf *

恢復前準備:重點這個必須有

4.11對完全備份做數據同步

復制代碼男人的天堂 AV电影 代碼如下:

[root@www ~]# innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/

男人的天堂 AV电影4.12對第一次增量做數據同步

復制代碼 代碼如下:

男人的天堂 AV电影 innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-37-01/

 

“--incremental-basedir”這個參數名字變了運行innobackupex --help查看

 

4.13對第二次增量做數據同步

復制代碼 代碼如下:

innobackupex --apply-log --redo-only /innobackup/2013-09-12_11-03-04/ --incremental-basedir=/innobackup/2013-09-12_11-45-53/ --apply-log 的意義在于把備份時沒commit的事務撤銷,已經commit的但還在事務日志中的應用到數據庫

“--incremental-basedir”這個參數名字變了運行innobackupex --help查看

 

 

 

 

 

 

男人的天堂 AV电影###############################################

注:

對于xtrabackup來講,它是基于事務日志和數據文件備份的,備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據庫文件中的事務,還應該對其做預處理,把已提交的事務同步到數據文件,未提交的事務要回滾。因此其備份的數據庫,不能立即拿來恢復。

預處理的過程:

首先對完全備份文件只把已提交的事務同步至數據文件,要注意的是有增量的時候,不能對事務做數據回滾,不然你的增量備份就沒有效果了。

然后把第一次的增量備份合并到完全備份文件內,

以此類推,把后幾次的增量都合并到前一次合并之后的文件中,這樣的話,我們只要拿著完全備份+二進制日志,就可以做時間點恢復。

 

 

 

 

 

為什么要恢復前準備:xtrabackup 在啟動時會記住log sequence number(LSN),并且復制所有的數據文件。復制過程需要一些時間,所以這期間如果數據文件有改動,那么將會使數據庫處于一個不同的時間點。這 時,xtrabackup會運行一個后臺進程,用于監視事務日志,并從事務日志復制最新的修改。

 

備 份MyISAM和InnoDB表最終會處于一致,在準備(prepare)過程結束后,InnoDB表數據已經前滾到整個備份結束的點,而不是回滾到 xtrabackup剛開始時的點。這個時間點與執行FLUSH TABLES WITH READ LOCK的時間點相同,所以MyISAM表數據與InnoDB表數據是同步的。類似Oracle的,InnoDB的prepare過程可以稱為recover(恢復),MyISAM的數據復制過程可以稱為restore(還原)。

 

個人理解:備份完成時,備份的數據是備份開始時間點的樣子,在備份過程中數據的變化會記錄到事務日志中。因此你備份的數據庫不能直接使用必須要recover(恢復),恢復完成之后那么備份的數據庫的狀態就是你備份結束時的樣子。備份結束后的數據改變就只能指望二進制文件了。所以還要把當時的那個二進制文件拷貝出來,用于進行精確地時間恢復。或者位置恢復。

 

 

 

 

 

4.14數據恢復

復制代碼男人的天堂 AV电影 代碼如下:

[root@www ~]# service mysqld stop [root@www data]# rm -rf *  模擬數據庫崩潰 [root@www ~]# innobackupex --copy-back /innobackup/2013-09-12_11-03-04/ --copy-back數據庫恢復,后面跟上備份目錄的位置

 

 

 

 

 

 

4.15檢測:

復制代碼 代碼如下:

[root@www ~]# cd /mydata/data/ [root@www data]# chown mysql:mysql * [root@www data]#service mysqld start

 

注:必須更改好數據目錄下所有文件的屬主和屬組,否則無法啟動。

 

 

前邊就完成了完全備份和恢復,但之前那個二進制文件文件怎么辦,干什么用。做基于時間點的恢復。詳細使用請參見:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

參考過程:

一、全部數據庫

 

備份:

 

innobackupex --user=root --password=root --defaults-file=/etc/mysql/my.cnf /data/mysql_backup/full_backup

 

 

 二、指定數據庫

 

備份:

 

假如我們要備份centos和aabb數據庫。

 

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 ./ | gz - > 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

參數:

--slave-info這個參數在對從數據庫進行備份時使用,可以保存主數據庫當前的二進制文件和偏移量。這樣可以減輕主數據庫因備份二壓力過大。其他參數自行查看。需要注意的是,你的數據庫超時設定會對備份有影響。在備份結束的時候快要結束的時候,有時候可能會因為你的數據庫連接超時而中斷,造成備份失敗。所以把數據庫超時設定加大才好,不要過短。

 

 

 

 

 

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這個選項失敗了不知道怎么回事,可以的話已更改能部分恢復數據庫。最后我手動將目錄拷回來改了權限就行了,當人如果不行的話就直單個表單個表的回復。

所以盡量用完全備份。

 

 

 

4.14數據恢復

 

注意:需要指定配置文件,否則找不到要還原的目錄

復制代碼 代碼如下:

 

[root@www ~]# service mysqld stop

[root@www data]# rm -rf *  模擬數據庫崩潰

[root@www ~]# innobackupex --defaults-file=/usr/my.cnf --copy-back /innobackup/2013-09-12_11-03-04/

--copy-back數據庫恢復,后面跟上備份目錄的位置

 

 

 

 

 

 

4.15檢測:

復制代碼 代碼如下:

 

[root@www ~]# cd /mydata/data/

[root@www data]# chown mysql:mysql *

[root@www data]#service mysqld start

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

##################################################

基于完全備份后的單表恢復,這種恢復方式前提是問題表沒有被重建過

參看網址:http://www.zhongweicheng.com/?p=1284

 

 

 

MySQL innobackupex全備中恢復Innodb單表

男人的天堂 AV电影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 table root@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 t2 Then 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!   

 

男人的天堂 AV电影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)就要說遠程備份和備份壓縮,先說流備份吧。

男人的天堂 AV电影流備份是指備份的數據通過標準輸出STDOUT傳輸給tar程序進行歸檔,而不是單純的將數據文件保存到指定的備份目錄中,參數--stream=tar表示開啟流備份功能并打包。同時也可以利用流備份到遠程服務器上。

舉例來說,

$ innobackupex --stream=TAR ${BACKUP_DIR}/base | gzip > ${BACKUP_DIR}/base.tar.gz $ innobackupex --stream=TAR ${BACKUP_DIR}/base|ssh somebackupaddr “cat > ${DIR}/base.tar”

 

男人的天堂 AV电影在我們現實使用中,更多的使用增量備份,至于歸檔壓縮我們可以通過腳本自主完成。

 

基于單表備份的單表恢復(這里可有流備份),前提也是問題表沒有被重新建立過。否則是不會成功的。

 

 

建好備份目錄;mkdir /data/backup -p

 

壓縮備份:

男人的天堂 AV电影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

 

 

 

參數:--safe-slave-backup 備份slave:

 

                      Stop slave SQL thread and wait to start backup until

男人的天堂 AV电影                      Slave_open_temp_tables in "SHOW STATUS" is zero. If there

男人的天堂 AV电影                      are no open temporary tables, the backup will take place,

                      otherwise the SQL thread will be started and stopped

男人的天堂 AV电影                      until there are no open temporary tables. The backup will

男人的天堂 AV电影                      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.

 

 

 

新建個目錄男人的天堂 AV电影-mkdir /data/databak;

 

解壓備份到干凈的目錄:

tar -ixf searchaccount.tar.gz -C /data/databak/

 

 

導出表:innobackupex --apply-log --export /data/databak

 

查看下: 男人的天堂 AV电影ll /data/databak/se

男人的天堂 AV电影里邊的.ibd文件是我們需要的。

 

 

模擬原來的數據表損壞:

男人的天堂 AV电影mysql > ALTER TABLE se.searchaccount DISCARD TABLESPACE;

拷貝要恢復的表的.ibd文件到數據庫目錄下:

男人的天堂 AV电影cp /data/databak/se/{searchaccount.ibd,searchaccount.cfg} /usr/local/mysql/data

 

 

 

改變拷貝過去的.ibd文件的屬主和屬組:

chown mysql.mysql ...ibd文件。必須改。

 

 

導入表:強調下這個問題表沒有被重新建立過才會成功

 

ALTER TABLE se.searchaccount IMPORT TABLESPACE;

 

 

 

 

男人的天堂 AV电影#######################################

 

如果問題表是被誤刪除的那么恢復的時候是有點復雜的,不管是從完全備份那里恢復還是從單表備份哪里恢復,都是一樣的。

 

 

如果問題表被刪除了,那么與上邊的恢復差別就是在最后導入表的部分。

表被刪除了的話,恢復是需要修復數據庫目錄下的ibdata1文件的。

 

修復工具是需要安裝的,工具下載地址:https://launchpad.net/percona-data-recovery-tool-for-innodb/+download

 

男人的天堂 AV电影一.安裝: .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表原來的數據。)

./ibdconnect  -o /var/lib/mysql/ibdata1  -f /var/lib/mysql/test/A.ibd -d test -t A

 

使用percona recovery tool 重新checksum ibdata。這一步需要多次執行直到沒有輸出信息為止。(這里是將事務日志文件中還沒有提交的事務redo到硬盤數據頁中。因為內存中的臟頁由于之前的故障不可用了(本來應該由chakpoint機制來將內存緩沖區的臟頁數據刷新到硬盤中的)。)

男人的天堂 AV电影./innochecksum -f /var/lib/mysql/ibdata1

 

 

 

男人的天堂 AV电影#####################################################

 

 

 下邊是擴展:在沒有備份和二進制日志未開啟時,若某個表的重要數據被刪除后的恢復方式。沒測試過不過看最后的注釋。這種方法只適用于innodb表,并且最重要的是,一旦數據表中數據被誤刪除,必須馬上停止對這張表的寫入操作,否則真的就不能再恢復了。

 

 

使用Percona Data Recovery Tool for InnoDB恢復數據

August 29th, 2013 hidba 

昨晚收到一則求助,一個用戶的本地數據庫的重要數據由于誤操作被刪除,需要進行緊急恢復,用戶的數據庫日常并沒有進行過任何備份,binlog也沒有開啟,所以從備份和binlog入手已經成為不可能,咨詢了丁奇,發了一篇percona的文章給我,頓時感覺有希望,于是到percona的官網上下載了恢復工具: 一.安裝: .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包括了主鍵數據和索引數據兩大部分(如果該表有多個二級索引,則會生成多個文件) ./page_parser -5 -f t_bibasic_storage.ibd 參數解釋: -5:代表 row format為Compact -f:代表要解析的文件 結果如下: pages-1377707810/FIL_PAGE_INDEX 0-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知曉)

三.生成表定義: 由于該工具在解析數據pages的時候,需要獲得該table的表結構定義,所以需要執行如下命令: ./create_defs.pl –host xxxx –port 3306 –user root –password xxx –db didb –table t_bibasic_storage >include/table_defs.h 上面的命令會將t_bibasic_storage表的表結構定義傳入到table_defs.h中,在生成了表結構定義后,重新make該恢復工具: .make

四.開始恢復pages中刪除的數據: 在重新編譯工具后,執行如下命令: ./constraints_parser -5 -D -f pages-1377707810/FIL_PAGE_INDEX/0-161 >/tmp/t_bibasic_salessend.sql 參數: -5 -f的參數和page_parser相同; -D:該參數的含義為代表恢復刪除的數據頁;

恢復完成后生成如下語句和文件: 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);

男人的天堂 AV电影/tmp/t_bibasic_salessend.sql 該文件就是我們需要load data的文本文件;

男人的天堂 AV电影總結: 1)。該恢復工具只支持innodb存儲引擎,文件的格式需要為:Compact 2)。數據被誤刪除后,需要盡快將保護現場,停止數據庫,把idb文件拷貝出來,防止ibd文件寫入數據被覆蓋(筆者恢復的一個表中,由于數據刪除后,表中仍有大量寫入,導致大部分數據沒有恢復出來); 3)。千叮囑萬囑咐,數據庫的備份重于泰山;

 



優質網站模板

  • 1
  • 2
  • 3