標籤：www 災難恢複 檔案系統 優點 線上 不能啟動 一致性 邏輯備份 無法
我們不打算包括的話題： 安全（訪問備份，恢複資料的許可權，檔案是否需要加密） 備份儲存在哪裡，包括他們應該離來源資料多遠，以及如何將資料從源頭移動到目的地 保留原則、審計、法律要求，以及相應的條款 儲存解決方案和介質，壓縮，以及增量備份 儲存的格式 對備份的監控和報告 儲存層內建備份功能，或者其他專用裝置，例如預製式檔案伺服器 還原意味著從備份檔案中擷取資料，可以載入這些檔案到MySQL裡，也可以將這些檔案放置到MySQL期望的路徑中。恢複一般意味著當某些異常發生後對一個系統或者其部分的拯救，包括從備份中還原資料，以及使伺服器完恢複功能的所有必要操作，例如重啟MySQL、改變更配置置和預熱伺服器的緩衝等。儲存引擎的奔潰恢複要求資料和記錄檔一致。要確保資料檔案中只包含已經提交的事務所做的修改，恢複操作會將日誌中還沒有應用到資料檔案的食物重新執行。
為什麼要備份 災難恢複：硬體故障、一個不經意的Bug導致資料損毀，或者伺服器及其資料由於某些原因不可擷取或無法使用等。 人們改變想法：刪除某些資料和又想要恢複這些資料 審計： 資料快照，過去某個時間點的資料狀態 測試：取資料到測試環境做測試使用
定義恢複需求
不僅僅要有備份系統，還要有一個強大的恢複系統。 規劃恢複策略時，有兩個重要的需求可以協助思考：復原點目標（PRO)和恢復目標（RTO）。他們定義了可以容忍丟失多少資料，以及需要等待多久將資料恢複。在定義RPO和RTO是，先嘗試回答下面幾類問題：
- 在不導致嚴重後果的情況下，可以容忍丟失多少資料？需要故障恢複，還是可以接受自從上次日常備份後所有的工作全部丟失？是否有法律法規的要求？
- 恢複需要在多長時間內完成？哪種類型的宕機是可以接受的？哪些影響（例如，部分服務不可用）是應用和使用者可以接受的？當那些情境發生時，又該如何持續服務？
- 需要恢複什嗎？常見的需求是恢複整個伺服器，單個資料庫，單個表，或僅僅是特定的事務或語句
複製！=備份： 例如Drop table後需要恢複，複製就恢複不了，需要靠備份才能恢複，當然延遲複製有可能的。
設計MySQL備份方案
細節之前的建議：
- 在生產實踐中，大資料庫來說，物理備份是必須的：邏輯備份太慢並且受資源限制，邏輯備份中恢複需要很長時間。基於快照的備份，例如Perconna XtraBackup和MySQL Enterprise Backup是最好的選擇。
- 保留多個備份組
- 定期從邏輯備份（或者物理備份）中抽取資料進行恢複測試
- 儲存二進位日誌以用於基於故障時間點的恢複。expire_logs_days應該設定的足夠長.至少大於全量備份的間隔時間。
- 完不藉助備份工具本身來監控備份和備份的過程。需要另外驗證備份是否正常。
- 通過演練整個恢複過程來測試備份和恢複。測算恢複所需要的資源（CPU、磁碟空間、實際時間，以及網路頻寬等）
- 對安全性要仔細考慮。
線上備份還是離線備份 規劃備份是，有一些與效能相關的因素需要考慮：
- 鎖時間：需要持有鎖多長時間，例如備份期間持有的全域FLUSH TABLES WITH READ LOCK?
- 備份時間： 複本備份到目的地需要多久
- 備份負載：在複本備份到目的地時對伺服器效能的影響有多少
- 恢復：把備份鏡像從儲存位置複製到MySQL伺服器，重放二進位日誌需要多久？
最大的權衡是備份時間與備份負載。提高備份的優先順序，代價是降低伺服器效能。
邏輯備份還是物理備份 邏輯備份（也叫"匯出"）和直接複製原始檔案的物理備份。 邏輯備份有如下的優點：
- 邏輯備份可以使用編輯器或grep和sed之類的命令查看和操作的普通檔案。
- 恢複非常簡單。直接匯入。
- 可以通過網路來備份和恢複
- 可以在類似Amazon RDS這樣不能訪問底層檔案系統中使用
- 非常靈活，因為mysqldump大部分人喜歡的工具.
- 與儲存引擎無關
- 有助於避免資料損毀，物理備份可能磁碟損壞
邏輯備份的缺點：
- 必須由資料庫伺服器完成組建邏輯備份的工作，因此要使用更多的cpu周期
- 邏輯備份在某些情境下筆資料庫檔案本身更大
- 無法保證到處後再還原出倆的一定是同樣的資料
- 從邏輯備份中還原需要MySQL載入和解釋語句，轉化為儲存格式，並重建索引，所有這一切會很慢
最大的缺點是恢複，測試恢複所需要的時間將非常重要. 物理備份有如下好處：
- 基於檔案的物理備份，只需要將需要的檔案複製到其他地方即可完成備份。不需要其他額外的工作來產生原始檔案
- 恢複更簡單，取決於儲存引擎。對於MyISAM複製到目的地即可。InnoDB需要停止資料庫服務採取其他的步驟
- InnoDB和MyISAM的物理備份非常容易跨平台、作業系統和MySQL版本
- 從屋裡備份中恢複會更快，因為不需要執行任何SQL或構建索引
事實上，邏輯備份最可怕的地方就是不確定的還原時間。物理備份的缺點：
- InnoDB的原始檔案通常比相應的邏輯備份要大的多。InnoDB的資料表空間包含很多未使用的空間。還有很多空間被用來做儲存資料意外的用途（插入緩衝、復原段等）
- 物理備份不總是可以跨平台、作業系統以及MySQL版本。檔案名稱大小寫敏感和浮點格式是可能會遇到的麻煩。很可能因浮點格式不同而不能移動檔案到另一個系統
備份什麼
恢複的需求決定需要備份什麼，最簡單的測率是指備份資料和表定義下面是MySQL備份需要考慮的幾點：
- 非顯著資料： 容易被忽略的資料，例如二進位日誌和InnoDB交易記錄
- 代碼 ： 觸發器和預存程序
- 複製配置： 有複製關係的。二進位日誌、中繼日誌、日誌索引檔案和info檔案
- 伺服器配置： 設定檔
- 選定的作業系統檔案管理指令碼等
鄭亮備份和差異備份： 差異備份是對自上次全備份後所有改變的部分而做的備份，而增量備份則是自從任意類型的上次備份後所有修改做的備份下面是一些建議：
- 使用Percona XtraBackup和MySQL Enterprise Backup中的增量備份特性
- 備份二進位日誌。
- 不要備份沒有改變的表。
- 不要備份沒有改變的行
- 某些資料根本不需要備份
- 備份所有的資料，然後發送到一個有去重特性的目的地。
增量備份的缺點包括增加恢複復雜性，額外的風險，以及更長的恢復。如果可全備，考慮到簡便性，我們建議盡量做全備。
儲存引擎和一致性
資料一致性：只要伺服器上使用REPEATABLE READ交易隔離等級，並且沒有任何DDL，就一定會有完美的一致性，以及基於時間點的資料快照，且在備份過程中不會阻塞任何後續的工作。 檔案一致性:如果是MyISAM，可能是鎖住並重新整理表。 複製：從悲苦中備份最大的好處是可以不干擾主庫，避免在主庫上增加額外的負載。
管理和備份二進位日誌 伺服器的二進位日誌是備份的最重要因素之一。 MySQL 5.6版本的mysqlbinlog有一個非常方便的特性，可以串連到伺服器上來即時對二進位日誌做鏡像。 二進位日誌格式: 使用mysqlbinlog工具查看二進位日誌的內容。時間的日誌和時間、原伺服器的伺服器ID，end_log_pos,下一個時間的位移位元組值、時間類型，元伺服器上執行時間的線程ID，對於審計和執行CONNECTION_ID()函數很重要。 exec_time,在原伺服器上時間產生的錯誤碼。 如果使用的是MySQL5.1中基於行的日誌，事件將不再是SQL。而是可讀性較差的由語句對錶所做變更的”鏡像“。 安全清理二進位日誌：expire_log_days 變數來告訴MySQL定期清理日誌。這個變數是MySQL 4.1才引入。之前都是rm mysql-bin.[0-9]*直接刪除 在新版本中不要這樣做，用rm刪除日誌會導致mysql-bin.index轉檯檔案與磁碟上的檔案不一致，有些語句，例如show master logs可能會受到影響而悄然失敗，手動修改mysql-bin.index檔案也不會修複這個問題應該iyong雷利下面的cron命令： /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATA - INTERVAL N DAY" expire_logs_days 設定在伺服器啟動或MySQL切換二進位日誌時生效，因此，如果二進位日誌從沒有增長和切換，伺服器不會清楚老條目。此設定是通過產看日誌的修改時間而不是內容來決定哪個檔案需要被清除的。
備份資料
邏輯備份： SQL匯出和符號分隔檔案 SQL匯出：mysqldump不是產生sql邏輯備份的唯一工具。例如，也可以用mydumper或phpmyadmin工具來建立。 SQL邏輯備份缺點：
- schema和資料存放區在一起
- 巨大的SQL語句
- 單個巨大的檔案
- 邏輯備份的成本很高
符號分割檔案備份：可以使用SQL命令SELECT INTO OUTFILE以符號分割檔案格式建立資料的邏輯備份。（可以用mysqldump --tab選項到處到符號分隔檔案中)。 優點是備份與還原速度更快。 可以使用LOAD DATA INFILE方法載入資料到表中 SELECT INTO OUTFILE方法的一些限制：
- 只能備份到運行MySQL伺服器的機器上的檔案中
- 運行MySQL的系統使用者必須有檔案目錄的寫入權限，因為是由MySQL伺服器來執行檔案的寫入，而不是運行SQL命令的使用者。
- 出於安全原因，不能覆蓋已經存在的檔案，不管檔案許可權如何
檔案系統快照： 一種非常好的線上備份的方法。支援快照的檔案系統能夠瞬間建立用來備份的內容一致的景象。支援快照的檔案系統和裝置包括FreeBSD的檔案系統、ZFS檔案系統、GNU/Linux的邏輯卷管理(LVM)，以及許多的SAN系統和檔案儲存體解決方案，例如NetApp儲存. lvm方式應該用不到的，看了一下，不寫了。
從備份中恢複 如何恢複資料取決於是怎麼備份的。可能需要一下部分或全部步驟：
- 停止MySQL伺服器
- 記錄伺服器的配置和檔案許可權
- 將資料從備份中移到MySQL資料目錄
- 改變更配置置
- 改變檔案許可權
- 以限制訪問模式重啟伺服器，等待完成啟動
- 載入邏輯備份檔案
- 檢查和重放二進位日誌
- 檢測已經還原的資料
- 以完全許可權重啟伺服器
在恢複過程中，保證MySQL除了恢複進程外不接受其他訪問，這一點往往比較重要。加參數 --skip-networking 和 --socket=/tmp/mysql_recover.sock來啟動MySQL 恢複物理備份： 檢查目錄的許可權、設定檔的參數、觀察錯誤記錄檔還原邏輯備份： mysql < backup.sql 載入符號分割符文劍: LOAD DATA INFILE 或者使用mysqlimport基於時間點的恢複：常見方法是還原最近一次全備份，然後從那個時間點開始重放二進位日誌。623頁 更進階的恢複技術： 用於快速回複的延時複製：搭建一個延時資料庫 使用Log Service器進行恢複：
InnoDB崩潰恢複
根據記錄檔將事務應用到資料檔案，將未提交的變更從資料檔案中復原 InnoDB損壞的原因：硬體有關的（例如電力問題或記憶體損壞而導致損壞頁的寫入）。錯誤配置的硬體是更多的問題之源。常見的錯誤配置包括開啟了不包含電池備份單元的RAID卡的回寫緩衝，或開啟iale硬碟本身的詼諧緩衝。嚴重的損壞會使InnoDB或MySQL奔潰，而不是那麼嚴重的損壞則可能只是由於記錄檔未真正同步到磁碟而丟掉了某些事務。
如何恢複損壞的InnoDB資料
InnoDB損壞有三種主要類型：
- 二級索引損壞： 一般可以用optimize table 來修複損壞的二級索引；也可以使用select into outfile,刪除和重建表，然後 LOAD DATA INFILE的方法。這些都是通過構建一個新表受影響的索引，來修複損壞的索引資料。
- 聚簇索引損壞：也許只能使用 innodb_force_recovery選項匯出表.筆者就曾遇到過不止一次，都是因為意外斷電導致，或者儲存掛掉。
- 損壞系統結構：包括InnoDB交易記錄、資料表空間的撤銷日誌(undo log)地區和資料字典。這種損壞可能需要整個資料庫的匯出和還原，因為InnoDB內部絕大部分的工作都可能受到影響。
如果InnoDB的資料損毀到根本不能啟動MySQL的程度，還可以使用Percona出品的InnoDB Recovery Toolkit從資料表空間的資料檔案裡面直接抽取資料。擷取地址： http://www.percona.com/softwarePercona Server還有允許伺服器在某些表損壞時仍能啟動並執行選項，而不是像MySQL那樣單個表損害頁被檢測出時就預設強制崩潰.
備份和恢複工具
- MySQL Enterprise Backup : 之前叫做InnoDB Hot Backup 或ibbackup。備份不需要停止MySQL，也不需要設定鎖或中斷正常的資料庫活動。支援類似壓縮備份、增量備份和到其他伺服器的流備份特性。官方的備份工具
- Percona XtraBackup: 開源並且免費，支援類似流、增量、壓縮和多線程（並行）備份操作。工作方式是在後台線程不斷追蹤InnoDB記錄檔尾部，然後複製InnoDB資料檔案。這是個輕量級的侵入過程，依靠特別的檢測機制確保複製的資料是一致的。 還有XtraBack Manager項目：http://code.google.com/p/xtrabackup-manager
- mylvmbackup： http://lenz.homelinux.org/mylvmbackup 是一個perl指令碼，通過LVM快照協助MySQL自動備份。此工具首先獲全域讀鎖，建立快照，釋放鎖。然後通過tar壓縮資料並移除快照。它通過備份時的時間戳記命名壓縮包。
- Zmanda Recovery Manager： http://www.zmanda.com。配置、備份、驗證、恢複、報告和調度，分免費和商業兩種版本。
- mydumper: mysqldump的替代品。多線程備份與還原： http://www.mydumper.org
- mysqldump: 與mysql一起發行的程式。最常見。
--all-databases 備份所有的資料庫 --databases sakila > dump.sql 備份資料庫單個 mysqldump sakila actor > dump.sql 備份sakila.actor表 --result-file=dump.sql 指定輸出檔案 --opt 啟用一組最佳化選項，包括關閉緩衝區，匯出資料時把更多的資料卸載更少的SQL語句裡 --allow-keyworkds,--quote-names 是使用者在匯出和恢複表時，可以使用保留字作為表的名字 --complete-insert 使使用者能在不完全相同列的表之間移動資料 --tz-utc 使使用者能在具有不同時區的伺服器之間移動資料 --locak-all-tables 使用FLUSH TABLE WITH READ LOCK來擷取全域一致的備份 --tab 用select into outfile 匯出檔案 --skip-extended-insert 使每一行資料都有自己的insert語句。 --single-transaction 對於InnoDB備份，這回使用InnoDB的MVCC特性在單個時間點建立一個一致的備份，而不需要使用LOCK TABLES鎖定所有表 --master-data 備份會包括在備份時伺服器的二進位記錄檔位置，這對基於時間點的恢複和設定複製非常有協助。
總結： 每個人都知道需要備份，但並不是每個人都意識到需要的是可恢複的備份。我們需要明確並記錄復原點目標和恢復目標，並且在選擇備份系統時將其作為參考。
----內容摘自《高效能MySQL 第三版》
高效能MySQL之【第十五章 備份與恢複】學習記錄
