MySQL筆記(8)---備份與恢復

1.前言

　　本章記錄數據庫的備份與恢復操做。MySQL提供了不少工具完成備份工做：mysqldump、ibbackup、replication，也可使用一些第三方的工具完成，如xtrabacup、LVM快照等。

2.備份與恢復概述

　　根據備份方法的不一樣，能夠將備份分爲：

　　　　Hot Backup（熱備）：指的是在數據庫運行中直接備份，對運行沒有影響

　　　　Cold Backup（冷備）：在數據庫中止的狀況下，這種備份最簡單，通常就複製物理文件便可

　　　　Warm Backup（溫備）：在數據庫運行中，可是對數據庫操做會有影響，如加一個全局的讀鎖保證備份數據的一致性

　　備份後的文件，又能夠分爲：

　　　　邏輯備份：指備份出的文件內容是可讀的，通常是文本文件，內容是一條條SQL語句，或者是表內實際數據組成。如mysqldump和select * into outfile的方法。這類方法的好處是能夠觀察導出的文件內容，通常適用於數據庫的升級、遷移等工做。可是缺點是恢復所須要的時間每每比較長。

　　　　裸文件備份：指複製數據庫的物理文件，既能夠是在數據庫運行中的複製，也能夠是在數據庫中止運行時直接的數據文件複製。這類備份的恢復時間每每較邏輯備份要短。

　　按照備份數據庫的內容，又可分爲：

　　　　徹底備份：對數據庫進行一個完整的備份

　　　　增量備份：對上次完整備份的基礎上，對更改的數據進行備份

　　　　日誌備份：經過對一個徹底備份進行二級制日誌的重作來完成數據庫的point-in-time的恢復工做。MySQL數據庫的複製原理就是異步實時地將二進制日誌重作傳送並應用到從數據庫。

　　對MySQL來講，官方沒有提供真正的增量備份的方法，大部分是經過二進制日誌完成增量備份的工做。這種備份較之真正的增量備份來講，效率仍是很低的。由於可能對一個頁執行屢次SQL完成重作。對於真正的增量備份，只須要記錄當前每頁最後的檢查點的LSN，若是大於以前全備時的LSN，則備份該頁，不然不用備份，這大大加快了備份的速度和恢復的時間，同時也是xtrabackup工具增量備份的原理。

　　此外還要注意理解數據庫備份一致性，要求在備份的時候數據在這一時間點上是一致的。例如：買東西，扣錢得東西，可是備份過程當中備份了扣錢，而沒有備份得東西就很糟糕了。

　　InnoDB支持MVCC功能，所以實現一致的備份比較簡單。用戶能夠先開啓一個事務，而後導出一組相關的表，最後提交。事務的隔離級別固然是要REPEATABLE READ，這樣就能夠給出一個完美的一致性備份。

　　對於mysqldump備份工具來講，能夠經過添加--single-transaction選項得到InnoDB存儲引擎的一致性備份，原理和以前所說的相同。

　　最後，任什麼時候候都須要作好遠程異地備份，容災的防範。

3.冷備

　　對於InnoDB存儲引擎的冷備很是簡單，只須要備份MySQL數據庫的frm文件，共享表空間文件，獨立表空間文件*.ibd，重作日誌文件。另外，建議備份MySQL數據庫的配置文件my.cnf，有利於恢復操做。

　　一臺機器的冷備是不夠的，要將數據放在遠程的機房。

　　冷備的優勢是：

　　　　備份簡單，只須要複製相關文件便可

　　　　備份文件易於在不一樣操做系統，不一樣MySQL版本上進行恢復

　　　　恢復至關簡單，只須要把文件恢復到指定位置便可

　　　　恢復速度快，不須要執行任何SQL語句，也不須要重建索引

　　冷備的缺點是：

　　　　文件比邏輯文件大不少，由於表空間存放不少其它數據，好比undo段，插入緩衝等。

　　　　冷備也不老是能夠輕易跨平臺，操做系統、MySQL版本、文件大小寫敏感、浮點數格式都會成爲問題。

4.邏輯備份

4.1 mysqldump

　　mysqldump [arguments] > file_name

　　若是想備份全部的數據庫，使用--all-databases選項：

　　　　mysqldump --all-databases > dump.sql

　　若是想要備份指定的數據庫 --databases db1 db2 db3

　　若是想要對test這個架構進行備份，可使用：

　　　　mysqldump --single-transaction test > test_backup.sql　　 以前說了--single-transaction用於保證備份的一致性

　　參數有不少，可使用mysqldump --help查看，下面介紹一些比較重要的參數：

　　　　--single-transaction: 在備份開始前，先執行START TRANSACTION命令，以得到備份的一致性，當前該參數只對InnoDB存儲引擎有效。

　　　　--lock-tables:在備份中，一次鎖住每一個架構下的全部表。通常用於MyISAM存儲引擎，能夠保證一致性。這個參數與上面參數是互斥的，只能用一個。若是有兩種表，只能選擇這個。可是隻能保證同一架構下的一致性，不能保證全部架構下的一致性。

　　　　--lock-all-tables: 用於避免上面說的一致性問題，鎖住全部的表

　　　　--add-drop-database:在create database前先進行drop database。這個參數須要和--all-databases或者--databases選項一塊兒使用。

　　　　--master-data[=value]：經過該參數產生的備份轉存文件主要用來創建一個replication。當value爲1時，轉存文件中記錄CHANGE MASTER語句。爲2時，CHANGE MASTER語句被寫出SQL註釋。默認值爲空。這個會忽略--lock-tables選項，若是沒有使用--single-transaction就會自動加上--lock-all-tables選項。

　　　　--events: 備份事件調度器

　　　　--routines:備份存儲過程和函數

　　　　--triggers:備份觸發器

　　　　--hex-blob:將BINARY、VARBINARY、BLOG、BIT列類型備份爲十六進制的格式。文本模式下有些字符可能看不見。

　　　　--tab=path：產生TAB分割的數據文件。

　　　　--where:導出指定的文件數據

4.2 SELECT ... INFO OUTFILE

　　這個也是一種邏輯備份的方法，更準確地說是導出一張表中的數據。

　　　　SELECT [column 1], [column 2] ...

　　　　INTO

　　　　OUTFILE 'file_name'

　　　　[{FIELDS | COLUMNS}

　　　　[TERMINATED BY 'string']　　　　　　表示分隔符

　　　　[[OPTIONALLY] ENCLOSED BY 'char']　　表示對字符串的包含符

　　　　[ESCAPED BY 'char']]　　　　表示轉義符

　　　　[ LINES

　　　　[ STARTING BY 'string']　　　　表示每行開始的字符串

　　　　[ TERMINATED BY 'string']　　 表示每行結束的字符串

　　　　]

　　　　FROM TABLE WHERE...

 4.3 邏輯備份的恢復

　　mysqldump的恢復操做比較簡單，由於備份的就是SQL，執行這個文件就能夠了。

　　　　mysql -uroot -p < test_backup.sql

　　若是導出時包含了建立和刪除數據庫的SQL語句，那麼必須確保刪除架構時，架構目錄下沒有其餘與數據庫相關的文件，不然會出錯。

　　由於邏輯備份的文件是由SQL語句組成的，也能夠經過SOURCE命令來執行導出的邏輯備份文件：

　　　　source /home/mysql/test_back.sql

　　經過mysqldump能夠恢復數據庫，可是其能夠導出存儲過程，觸發器，事件，數據，可是不能導出視圖。所以若是使用了視圖，備份完數據庫後，還須要導出視圖的定義，或備份視圖定義的文件frm，並在恢復時導入。

4.4 LOAD DATA INFILE

　　若經過mysqldump-tab，或者經過select into outfile導出的數據須要恢復，這時能夠經過命令LOAD DATA INFILE進行導入。語法以下：

　　　　LOAD DATA INTO TABLE a IGNORE 1 LINES INFILES '/home/mysql/a.txt'

　　　　[REPLACE | IGNORE]  INTO TABLE tbl_name

　　　　[CHARACTER SET charset_name]

　　　　[{FIELDS | COLUMNS}

　　　　[ TERMINATED BY 'string']

　　　　[[OPTIONALLY] ENCLOSED BY 'char']

　　　　[ESCAPED BY 'char']

　　　　]

　　　　[LINES

　　　　[STARTING BY 'string']

　　　　[TERMINATED BY 'string']

　　　　]

　　　　[IGNORE number LINES]

　　　　[(col_name_or_user_var， ...)]

　　　　[SET col_name= expr, ...]

　　能夠設置導入過程忽略對外鍵的檢查，加快導入速度：set @@foreign_key_checks=0

4.5 mysqlimport

　　這是MySQL提供的一個命令行程序，從本質上來講，是LOAD DATA INFILE的命令接口，大部分選項和LOAD DATA INFILE語法相同。

　　　　mysqlimport [options] db_name textfile1 [textfile2...]

　　不一樣的是，其能夠用來導入多張表。而且經過--user-thread參數併發地導入不一樣的文件。併發是指同時導入多個文件，不是同時操做一個文件。

5. 二級制日誌備份與恢復

　　二級制日誌很是關鍵，用戶能夠經過它完成point-in-time的恢復工做。MySQL的replication一樣須要二進制日誌，默認狀況下是不開啓的，須要配置log-bin=mysql-bin

　　在以前說過，只是簡單的啓用二進制日誌是不夠的，須要一些其餘參數保證最爲安全和正確地記錄二進制日誌，所以對於InnoDB存儲引擎，推薦的二進制日誌的服務器配置應該是：

　　　　log-bin = mysql-bin

　　　　sync_binlog = 1

　　　　innodb_support_xa=1

　　在備份二進制日誌文件前，能夠經過FLUSH LOGS命令生成一個新的二進制日誌文件，而後備份以前的。

　　恢復二進制日誌也很是簡單，經過mysqlbinlog便可。

　　　　mysqlbinlog [options] log_file

6 熱備

6.1 ibbackup

　　這個是InnoDB存儲引擎官方提供的熱備工具，能夠同時備份MyISAM存儲引擎和INNODB存儲引擎表。對InnoDB的備份工做原理以下：

　　　　1.記錄備份開始時，InnoDB存儲引擎重作日誌文件檢查點的LSN。

　　　　2.複製共享表空間文件以及獨立表空間文件

　　　　3.記錄複製完表空間文件後，InnoDB存儲引擎重作日誌文件檢查點的LSN

　　　　4.複製在備份時產生的重作日誌。

　　對於事務的數據庫，如Oracle和SQL Server，熱備的原理大體和上相同。能夠發如今備份期間不會對數據庫自己有任何影響，所作的操做只是複製數據庫文件，所以任何對數據庫的操做都是容許的，不會阻塞任何操做。

　　ibbackup的優勢以下：

　　　　1.在線備份，不阻塞任何的SQL

　　　　2.備份性能好，實質是複製數據庫文件和重作日誌文件

　　　　3.支持壓縮備份，經過選項，支持不一樣級別的壓縮

　　　　4.跨平臺支持，能夠運行再linux、windows和主流的unix系統上

　　ibbackup對InnoDB存儲引擎表的恢復步驟以下：

　　　　1.恢復表空間文件

　　　　2.應用重作日誌文件

　　ibbackup提供了一種高性能的熱備方式，是首選方式。可是其是收費的，不過開源的緣由，社區的力量，Percona公司作了一款免費的XtraBackup熱備工具，其實現了全部ibbackup功能，並擴展支持了真正的增量備份功能。

6.2 XtraBackup

　　該工具支持MySQL5.0以上版本，在GPL v2開源下發布。

　　命令是: xtrabackup--backup  | --prepare [OPTIONS]，具體可選參數就不進行介紹了。

　　若是要作一個徹底備份，能夠執行命令：

　　　　　　xtrabackup --backup

6.3 XtraBackup實現增量備份

　　MySQL數據庫自己提供的工具並不支持真正的增量備份，更準確地說，二進制日誌的恢復應該是point-in-time的恢復而不是增量備份。

　　XtraBackup支持增量備份，工做原理以下：

　　　　1.首先完成一個全備，記錄下此時檢查點的LSN

　　　　2.在進行增量備份時，比較表空間中每一個頁的LSN是否大於上次備份時的LSN，若是是，則備份該頁，同時記錄下當前檢查點的LSN。

　　xtrabackup --backup --target-dir=/backup/base   全備份

　　xtrabackup --backup --target-dir=/backup/delta --incremental-basedir=/backup/base 增量備份

　　xtrabackup --prepare --target-dir=/backup/base  準備增量

　　xtrabackup --prepare --target-dir=/backup/base --incremental-basedir=/backup/delta 添加增量數據

7 快照備份

　　MySQL自己不支持快照功能，因此快照備份是指經過文件系統支持的快照功能對數據庫進行備份。備份的前提是將全部數據庫文件放在同一個文件分區中，而後對該分區進行快照操做。

　　支持快照的文件系統設備包括FreeBSD的UFS文件系統，Solaris的ZFS文件系統，GUN/Linux的邏輯管理器（LVM）等。這裏以LVM爲例進行介紹，UFS和ZFS的快照實現大體和LVM類似。

　　LVM是LINUX系統下對磁盤分區進行管理的一種機制。LVM在硬盤和分區上創建一個邏輯層，來提升磁盤分區管理的靈活性。管理員能夠經過LVM系統輕鬆管理磁盤分區。例如，將若干個磁盤分區鏈接成一個整塊的卷組，造成一個存儲池。管理員能夠在卷組上隨意建立邏輯卷，並進一步在邏輯捲上建立文件系統。管理員經過LVM能夠方便地調整卷組的大小，而且能夠對磁盤存儲按照組的方式進行命名、管理和分配。

　　vgdisplay命令查看系統中有哪些卷組。lvdisplay能夠用來查看當前系統中有哪些邏輯卷。

　　LVM使用了寫時複製技術來建立快照。當建立一個快照時，僅複製原始卷中數據的元數據，並不會有數據的物理操做，所以快照的建立過程是很是快的。當快照建立完成，原始捲上有寫操做時，快照會跟蹤原始卷塊的改變，將要改變的數據在改變以前複製到快照預留的空間中，所以這個原理稱爲寫時複製。對於讀取操做，若是讀取的數據塊是建立快照後沒有修改過的，會將讀操做直接重定向原始捲上，若是修改過，就直接讀取保存在快照中該塊在原始捲上改變以前的數據。採起寫時複製機制保證了讀取快照時獲得的數據與快照建立時一致。

8 複製

8.1 複製的工做原理

　　複製是MySQL數據庫提供的一種高可用高性能的解決方案，通常用來創建大型應用。整體來講，replication的工做原理分爲如下3個步驟：

　　　　1.主服務器（master）把數據更改記錄到二進制日誌中。

　　　　2.從服務器（slave）把主服務器的二進制日誌複製到本身的中繼日誌中

　　　　3.從服務器重作中繼日誌中的日誌，把更改應用到本身的數據庫上，以達到數據的最終一致性。

　　複製的原理其實就是一個徹底備份加上二進制日誌備份的還原。不一樣的是這個二進制日誌的還原操做基本上實時在進行中。這裏要注意，複製不是徹底實時進行同步的，而是異步實時。這中間存在主從服務器之間的執行延時，若是主服務器壓力很大，則可能致使從服務器延時較大。

　　從服務器有2個線程，一個是IO線程，負責讀取主服務器的二進制日誌，並將其保存爲中繼日誌。另外一個線程是SQL線程，複製執行中繼日誌。MySQL4.0版本以前，從服務器只有1個線程，既負責讀取二進制日誌，又複製執行二進制日誌中的SQL語句。這樣不符合高性能的要求，已淘汰。SHOW FULL PROCESSLIST能夠看見相關內容。

　　SHOW SLAVE STATUS和SHOW MASTER STATUS能夠觀察一下延遲。主要是觀察從服務器的read_master_log_pos和主服務器的當前二進制偏移量position，知道兩者的差距。

8.2 快照+複製的備份架構

　　複製能夠用來做爲備份，但功能不只限於備份，主要功能以下：

　　　　1.數據分佈。因爲MySQL數據庫提供的複製並不須要很大的帶寬要求，所以能夠在不一樣的數據中心之間實現數據的複製。

　　　　2.讀取的負載平衡。經過創建多個從服務器，能夠將讀取平均地分佈到這些從服務器中，而且減小主服務器的壓力。通常經過DNS的Round-Robin和Linux的LVS功能實現

　　　　3.數據庫備份。複製對備份頗有幫助，可是從服務器不是備份，不能徹底代替備份。

　　　　4.高可用性和故障轉移。經過複製創建的從服務器有助於故障轉移，減小故障的停機時間和恢復時間。

　　建議在從服務器上啓用read-only選項，保證從服務器上的數據僅與主服務器進行同步，避免其餘線程修改。[mysqld] read-only

　　啓用read-only選項後，若是操做從服務器的用戶沒有super權限，則對從服務器進行任何的修改都會拋出錯誤。