MySQL數據備份

來源：NET Post Time：2006-04-10 Poster:colin　　

   在數據庫表丟失或損壞的情況下，備份你的數據庫是很重要的。如果發生系統崩潰，你肯定想能夠將你的表盡可能丟失最少的數據恢復到崩潰發生時的狀態。有時，正是 MySQL 管理員造成破壞。管理員已經知道表已破壞，用諸如 vi 或 Emacs 等編輯器試圖直接編輯它們，這對表絕對不是件好事！ 

　　備份數據庫兩個主要方法是用 mysqldump 程序或直接拷貝數據庫文件（如用 cp、cpio 或 tar 等）。每種方法都有其優缺點： 

　　mysqldump 與 MySQL 服務器協同操作。直接拷貝方法在服務器外部進行，并且你必須采取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份數據庫，也會發生同樣的問題：如果數據庫表在文件系統備份過程中被修改，進入備份的表文件主語不一致的狀態，而對以后的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對后者你完全控制了備份過程，這樣你能采取措施確保服務器讓表不受干擾。 

　　mysqldump 比直接拷貝要慢些。 

　　mysqldump 生成能夠移植到其它機器的文本文件，甚至那些有不同硬件結構的機器上。直接拷貝文件不能移植到其它機器上，除非你正在拷貝的表使用 MyISAM 存儲格式。ISAM 表只能在相似的硬件結構的機器上拷貝。在 MySQL 3.23 中引入的 MyISAM 表存儲格式解決了該問題，因為該格式是機器無關的，所以直接拷貝文件可以移植到具有不同硬件結構的機器上。只要滿足兩個條件：另一臺機器必須也運行 MySQL 3.23 或以后版本，而且文件必須以 MyISAM 格式表示，而不是 ISAM 格式。 

　　不管你使用哪種備份方法，如果你需要恢復數據庫，有幾個原則應該遵守，以確保最好的結果： 

　　定期實施備份。建立一個計劃并嚴格遵守。 

　　讓服務器執行更新日志。當你在崩潰后需要恢復數據時，更新日志將幫助你。在你用備份文件恢復數據到備份時的狀態后，你可以通過運行更新日志中的查詢再次運用備份后面的修改，這將數據庫中的表恢復到崩潰發生時的狀態。 

　　以文件系統備份的術語講，數據庫備份文件代表完全傾倒（full dump），而更新日志代表漸進傾倒（incremental dump）。 

　　使用一種統一的和易理解的備份文件命名機制。象 backup1、buckup2 等不是特別有意義。當實施你的恢復時，你將浪費時間找出文件里是什么東西。你可能發覺用數據庫名和日期構成備份文件名會很有用。例如： 

　　%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02 

　　%mysqldump menagerie >/usr/archives/mysql/menagerie.1999-10-02 

　　你可能想在生成備份后壓縮它們。備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁盤，就象你讓你的日志文件過期那樣。 

　　用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰，不僅清除了你的數據目錄，也清除了包含你的數據庫備份的磁盤驅動器，你將真正遇上了麻煩。 

　　也要備份你的更新日志。 

　　將你的備份文件放在不同于用于你的數據庫的文件系統上。這將降低由于生成備份而填滿包含數據目錄的文件系統的可能性。 

　　用于創建備份的技術同樣對拷貝數據庫到另一臺機器有用。最常見地，一個數據庫被轉移到了運行在另一臺主機上的服務器，但是你也可以將數據轉移到同一臺主機上的另一個服務器。 

　　1 使用 mysqldump 備份和拷貝數據庫 

　　當你使用 mysqldumo 程序產生數據庫備份文件時，缺省地，文件內容包含創建正在傾倒的表的 CREATE 語句和包含表中行數據的 INSERT 語句。換句話說，mysqldump 產生的輸出可在以后用作 mysql 的輸入來重建數據庫。 

　　你可以將整個數據庫傾倒進一個單獨的文本文件中，如下： 

　　%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02 

　　輸出文件的開頭看起來象這樣： 

　　# MySQL Dump 6.0# # Host: localhost Database: samp_db#------------- 

　　--------------------------# Server version 3.23.2-alpha-log## Table st 

　　ructure for table absence#CREATE TABLE absence( student_id int(10) 

　　unsigned DEFAULT 0 NOT NULL, date date DEFAULT 0000-00-00 NOT NUL 

　　L, PRIMARY KEY (student_id,date));## Dumping data for table absence 

　　#INSERT INTO absence valueS (3,1999-09-03);INSERT INTO absence value 

　　S (5,1999-09-03);INSERT INTO absence valueS (10,1999-09-08);...... 

　　文件剩下的部分有更多的INSERT和CREATE TABLE語句組成。如果你想壓縮備份，使用類似如下的命令： 

　　%mysqldump samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz 

　　如果你要一個龐大的數據庫，輸出文件也將很龐大，可能難于管理。如果你愿意，你可以在 mysqldump 命令行的數據庫名后列出單獨的表名來傾到它們的內容，這將傾倒文件分成較小、更易于管理的文件。下例顯示如何將 samp_db 數據庫的一些表傾到進分開的文件中： 

　　%mysqldump samp_db student score event absence >grapbook.sql 

　　%mysqldump samp_db member president >hist-league.sql 

　　如果你生成準備用于定期刷新另一個數據庫內容的備份文件，你可能想用 --add- drop-table 選項。這告訴服務器將 DROP TABLE IF EXISTS 語句寫入備份文件，然后，當你取出備份文件并把它裝載進第二個數據庫時，如果表已經存在，你不會得到一個錯誤。 

　　如果你倒出一個數據庫以便能把數據庫轉移到另一個服務器，你甚至不必創建備份文件。要保證數據庫存在于另一臺主機，然后用管道傾倒數據庫，這樣 mysql 能直接讀取 mysqldump 的輸出。例如：你想從主機 pit- viper.snake.net 拷貝數據庫 samp_db 到 boa.snake.net，可以這樣很容易做到： 

　　%mysqladmin -h boa.snake.net create samp_db 

　　%mysqldump samp_db | mysql -h boa.snake.net samp_db 

　　以后，如果你想再次刷新 boa.snake.net 上的數據庫，跳過 mysqladmin 命令，但要對 mysqldump 加上--add-drop-table 以避免的得到表已存在的錯誤： 

　　%mysqldump --add-drop-table samp_db | mysql -h boa.snake.net samp_db 

　　mysqldump 其它有用的選項包括： 

　　--flush-logs 和 --lock-tables 組合將對你的數據庫檢查點有幫助。--lock-tables 鎖定你正在傾倒的所有表，而 --flush-logs 關閉并重新打開更新日志文件，新的更新日志將只包括從備份點起的修改數據庫的查詢。這將設置你的更新日志檢查點位備份時間。（然而如果你有需要執行個更新的客戶，鎖定所有表對備份期間的客戶訪問不是件好事。） 

　　如果你使用 --flush-logs 設置檢查點到備份時，有可能最好是傾倒整個數據庫。 

　　如果你傾倒單獨的文件，較難將更新日志檢查點與備份文件同步。在恢復期間，你通常按數據庫為基礎提取更新日志內容，對單個表沒有提取更新的選擇，所以你必須自己提取它們。 

　　缺省地，mysqldump 在寫入前將一個表的整個內容讀進內存。這通常確實不必要，并且實際上如果你有一個大表，幾乎是失敗的。你可用 --quick 選項告訴 mysqldump 只要它檢索出一行就寫出每一行。為了進一步優化傾倒過程，使用 --opt 而不是 --quick。--opt 選項打開其它選項，加速數據的傾倒和把它們讀回。 

　　用 --opt 實施備份可能是最常用的方法，因為備份速度上的優勢。然而，要警告你，--opt 選項確實有代價，--opt 優化的是你的備份過程，不是其他客戶對數據庫的訪問。--opt 選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何表。你可在一般數據庫訪問上很容易看到其效果。當你的數據庫一般非常頻繁地使用，只是一天一次地調節備份。 

　　一個具有 --opt 的相反效果的選項是 --dedayed。該選項使得 mysqldump 寫出 INSERT DELAYED 語句而不是 INSERT 語句。如果你將數據文件裝入另一個數據庫并且你想是這個操作對可能出現在該數據庫中的查詢的影響最小，--delayed 對此很有幫助。 

　　--compress 選項在你拷貝數據庫到另一臺機器上時很有幫助，因為它減少網絡傳輸字節的數量。下面有一個例子，注意到 --compress 對與遠端主機上的服務器通信的程序才給出，而不是對與本地主機連接的程序： 

　　%mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db 

　　2 使用直接拷貝數據庫的備份和拷貝方法 

　　另一種不涉及 mysqldump 備份數據庫和表的方式是直接拷貝數據庫表文件。典型地，這用諸如 cp、tar 或 cpio 實用程序。本文的例子使用 cp。 

　　當你使用一種直接備份方法時，你必須保證表不在被使用。如果服務器在你則正在拷貝一個表時改變它，拷貝就失去意義。 

　　保證你的拷貝完整性的最好方法是關閉服務器，拷貝文件，然后重啟服務器。如果你不想關閉服務器，要在執行表檢查的同時鎖定服務器。如果服務器在運行，相同的制約也適用于拷貝文件，而且你應該使用相同的鎖定協議讓服務器“安靜下來”。 

　　假設服務器關閉或你已經鎖定了你想拷貝的表，下列顯示如何將整個 samp_db 數據庫備份到一個備份目錄（DATADIR 表示服務器的數據目錄）： 

　　%cd DATADIR%cp -r samp_db /usr/archive/mysql 

　　單個表可以如下備份： 

　　%cd DATADIR/samp_db%cp member.* /usr/archive/mysql/samp_db%cp score.* 

　　/usr/archive/mysql/samp_db .... 

　　當你完成了備份時，你可以重啟服務器（如果關閉了它）或釋放加在表上的鎖定（如果你讓服務器運行）。 

　　要用直接拷貝文件把一個數據庫從一臺機器拷貝到另一臺機器上，只是將文件拷貝到另一臺服務器主機的適當數據目錄下即可。要確保文件是 MyIASM 格式或兩臺機器有相同的硬件結構，否則你的數據庫在另一臺主機上有奇怪的內容。你也應該保證在另一臺機器上的服務器在你正在安裝數據庫表時不訪問它們。 

　　3 復制數據庫（Replicating Database） 

　　復制（Replication）類似于拷貝數據庫到另一臺服務器上，但它的確切含義是實時地保證兩個數據庫的完全同步。這個功能將在 3.23 版中出現，而且還不很成熟，因此本文不作詳細介紹。 

　　4 用備份恢復數據 

　　數據庫損壞的發生有很多原因，程度也不同。如果你走運，你可能僅損壞一兩個表（如掉電），如果你倒霉，你可能必須替換整個數據目錄（如磁盤損壞）。在某些情況下也需要恢復，比如用戶錯誤地刪除了數據庫或表。不管這些倒霉事件的原因，你將需要實施某種恢復。 

　　如果表損壞但沒丟失，嘗試用 myisamchk 或 isamchk 修復它們，如果這樣的損壞可有修復程序修復，你可能根本不需要使用備份文件。

　　恢復過程涉及兩種信息源：你的備份文件和個更新日志。備份文件將表恢復到實施備份時的狀態，然而一般表在備份與發生問題之間的時間內已經被修改，更新日志包含了用于進行這些修改的查詢。你可以使用日志文件作為 mysql 的輸入來重復查詢。這已正是為什么要啟用更新日志的原因。 

　　恢復過程視你必須恢復的信息多少而不同。實際上，恢復整個數據庫比單個表跟容易，因為對于數據庫運用更新日志比單個表容易。 

　　4.1 恢復整個數據庫 

　　首先，如果你想恢復的數據庫是包含授權表的 mysql 數據庫，你需要用 --skip -grant-table 選項運行服務器。否則，它會抱怨不能找到授權表。在你已經恢復表后，執行 mysqladmin flush-privileges 告訴服務器裝載授權標并使用它們。 

　　將數據庫目錄內容拷貝到其它某個地方，如果你在以后需要它們。 

　　用最新的備份文件重裝數據庫。如果你用 mysqldump 產生的文件，將它作為 mysql 的輸入。如果你用直接從數據庫拷貝來的文件，將它們直接拷回數據庫目錄，然而，此時你需要在拷貝文件之前關閉數據庫，然后重啟它。 

　　使用更新日志重復做備份以后的修改數據庫表的查詢。對于任何可適用的更新日志，將它們作為 mysql 的輸入。指定 --one-database 選項使得 mysql 只執行你有興趣恢復的數據庫的查詢。如果你知道你需要運用所有更新日志文件，你可以在包含日志的目錄下使用這條命令： 

　　% ls -t -r -1 update.[0-9]* | xargs cat | mysql --one-database db_name 

　　ls 命令生成更新日志文件的一個單列列表，根據服務器產生它們的次序排序（主意：如果你修改任何一個文件，你將改變排序次序，這導致更新日志一錯誤的次序被運用。） 

　　很可能你會是運用某幾個更新日志。例如，自從你備份以來產生的更新日志被命名為 update.392、update.393 等等，你可以這樣重新運行： 

　　%mysql --one-database db_name < update.392 

　　%mysql --one-database db_name < update.393 

　　..... 

　　如果你正在實施恢復且使用更新日志恢復由于一個錯誤建議的 DROP DATABASE、DROP TABLE 或 DELETE 語句造成丟失的信息，在運用更新日志之前，要保證從其中刪除這些語句。 

　　4.2 恢復單個表 

　　恢復單個表較為復雜。如果你用一個由 mysqldump 生成的備份文件，并且它不包含你感興趣的表的數據，你需要從相關行中提取它們并將它們用作 mysql 的輸入。這是容易的部分。難的部分是從只運用于該表的更新日志中拉出片斷。你會發覺 mysql_find_rows 實用程序對此很有幫助，它從更新日志中提取多行查詢。 

　　另一個可能性是使用另一臺服務器恢復整個數據庫，然后拷貝你想要的表文件到原數據庫中。這可能真的很容易！當你將文件拷回數據庫目錄時，要確保原數據庫的服務器關閉。