MySQL Backup & Copy
重要的是在表丟失和毀壞時備份數據庫。如果系統發生崩潰，您就能夠將表恢復到崩潰時刻的狀態，並盡可能不丟失數據。同樣，錯發DROP DATABASE 或DROP TABLE 命令的用戶可能會向您請求進行數據恢復。有時，這是由MySQL管理員引起的破壞，管理員試圖通過使用像vi 或emacs 這樣的編輯器直接編輯表文件而毀壞了它們。這樣做對表來說肯定是幹了壞事。
備份數據庫的兩種主要方法是使用mysqldump 程式或直接拷貝數據庫文件（如便用cp、tar 或cpio）。每種方法都有自己的優點和缺點：
mysqldump 與MySQL伺服器聯合進行操作。直接拷貝方法與伺服器相脫離，因此必須採取措施確保在進行拷貝時沒有客戶機在修改這些表。這個問題與利用文件系統備份來備份數據庫的問題相同：如果數據庫表在文件系統備份時進行更新，則進行備份的表文件處於非一致的狀態，並且對於今後恢復該表沒有意義。文件系統備份和直接拷貝文件的區別是：對於後者，您具有控製備份進度的權利，因此可以採取措施確保伺服器使表處於靜止狀態。
mysqldump比直接拷貝技術要慢
mysqldump 產生可移植到其他機器、甚至具有不同硬體結構的機器上的文本文件。直接拷貝文件不能夠移植到其他機器上，除非要拷貝的表使用MyISAM存儲格式。ISAM 表只能在具有相同硬體結構的機器之間進行拷貝。例如，將文件從SPARC 的Solaris 機器拷貝到Intel的Solaris 機器（或者相反）是行不通的。由MySQL3.23 引進的MyISAM表存儲格式可以解決這個問題，因為該格式與機器獨立。因此，如果以下兩個條件都滿足的話，直接拷貝文件可以移植到具有不同硬體結構的機器上：即另一台機器上也必須運行MySQL3.23以上的版本，並且文件必須表示成MyISAM 表，而不是ISAM 表。
不論選擇哪種備份方法，都有某些原則，您必須堅持這些原則，才能確保在需要恢複數據庫內容時得到最好的結果：
定期執行備份。設置一個時間表並堅持使用它。告訴伺服器運行更新日誌。更新日誌在您需要恢復崩潰後的數據庫時給予幫助。在使用備份文件將數據庫恢復到備份時刻的狀態後，可以通過運行更新日誌中的查詢，重新運行備份之後所做的改變。這個操作將數據庫中的表恢復到了崩潰時刻的狀態。在文件系統備份語言中，數據庫備份文件表示完全轉儲（full dump），而更新日誌則表示增量轉儲。使用一致和可理解的備份文件命名模式。像b a c k up 1、backup2 等名字沒有特殊的含義。當需要它執行恢復時，還得浪費時間去查看文件中的內容。您會發現使用數據庫名和花時間去構造備份文件名是有好處的。例如：
% mysqldump samp_db> /usr/archives/mysql/samp_db. 1999-10-02
% mysqldump menagerie> /usr/archives/mysql/menagerie.1999-10-02
在產生備份文件後您可能需要將它們壓縮。畢竟備份文件都比較大，所以您可能還需要終止備份文件以避免它們填滿磁片，這與終止日誌文件類似。您可以用相同的技術終止備份文件：
用文件系統備份來備份您的備份文件。如果您遭受了一個完全崩潰，不僅毀壞了數據目錄而且還破壞了包含數據庫備份的磁片驅動器，那將造成真正的麻煩。您還應該備份更新日誌。
將備份文件放在與您的數據庫不同的文件系統上。這將減少含有數據字典的文件系統被生成的備份文件填滿的可能性。
創建備份的技術對於將數據庫拷貝到另一個伺服器上也是很有幫助的。將數據庫轉移到運行在另一個主機上的伺服器是很平常的，但您還可以將數據轉移到運行在相同主機上的另一個伺服器。如果正為一個新版本的MySQL運行伺服器，並且想用成品伺服器上的某些真實數據來測試它時，可能會這樣做。還有一種可能，那就是您得到了一台新的機器並要將所有的數據庫移動到新機器上。
用mysqldump 備份和拷貝數據庫
當使用mysqldump 程式產生數據庫備份文件時，缺省設置是該文件的內容由CREATE TABLE語句組成，這些語句創建被轉儲的表以及包含表中的行數據的INSERT 語句。換句話說，mysqldump創建在今後可作為對mysql的輸入使用的輸出結果，以重建數據庫。
可以將整個數據庫按以下命令轉儲到單獨的文本文件中：
該文件的其餘部分由更多的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 > gradebook.sql
% mysqldump samp_db member president > hist-league.sql
如果您正在生成備份文件並打算用這些備份文件來定期刷新另一個數據庫的內容，則可能要使用 –add-drop-table選項。此選項告訴mysqldump 將DROP TABLE IF EXISTS語句寫到備份文件中。然後，當您取出該備份文件並將其載入到第二個數據庫時，如果表已經存在將不會出現錯誤資訊。如果您正在運行第二個數據庫，可使用此技術利用從第一個數據庫中的數據拷貝來定期地載入它。
如果您正在轉儲數據庫使該數據庫可以轉換到另一個伺服器上，則無須創建備份文件。應確保該數據庫存在於另一台主機上，然後用一個管道使mysql直接讀取mysqldump的輸出結果來轉儲數據庫。例如，如果想要將samp_db 數據庫從pit_viper.snake.net 拷貝到boa.snake.net，操作如下：
% mysqladmin -h boa.snake.netcreate samp_db
% mysqldump samp_db | mysql-h boa.snake.net samp_db
稍後，如果想要在boa.snake.net 中再次刷新該數據庫，可跳過mysqladmin 命令，但要將–add-drop-table增加到mysqldump 中，以避免得到有關“表已經存在”的錯誤：
% mysqldump --add-drop-table samp_db |
mysql-h boa-snake.net samp_db
mysqldump 的其他選項包括如下所示的幾個：
–flush-log 和–lock-tables 的結合有助於檢查數據庫。–lock-table鎖定所有正在轉儲的表，而–flush-log關閉並重新打開更新日誌文件。如果正在產生後續的更新日誌，則新的更新日誌將只包含從備份的那一點開始修改數據庫的查詢。這時檢查對於該備份時間的更新日誌的檢查點（然而，鎖定所有的表對於備份期間客戶機訪問來說不太好，如果您有需要執行更新操作的客戶機的話）。
如果用–flush- logs檢查對於備份時間的更新日誌檢查點，最好轉儲整個數據庫。如果轉儲單個文件，則將更新日誌的檢查點與備份文件同步是比較難的。在恢復操作中，您通常在總數據庫（per- database）的基礎上抽取更新日誌的內容。對於抽取單個表的更新日誌來說沒有選項，因此您必須自己抽取它們。
缺省設置時，mysqldump將表的全部內容在寫之前讀到記憶體中。這實際上不是必須的，事實上，如果您真的有大型表的話，這幾乎是一個失敗的方法。可以用–quick選項告訴mysqldump 寫每一行（只要是被檢索的）。要想進一步優化該轉儲過程，可用- - opt來代替- - quick。– opt 選項開啟其他的選項，這些選項將加快轉儲數據和讀回數據的速度。由於快速備份的好處，使得用–opt 執行備份成為最常用的方法。但是，要當心， - -opt 選項有一個代價： –opt所優化的是您的備份過程，而不是由其他客戶機對數據庫的訪問。–opt 選項可防止任何人更新被鎖定的正在轉儲的任何表。您會很容易地發現在常規數據庫訪問中在這一點上所做的努力。試著在一天中數據庫通常最繁忙的時刻運行一個備份。這不會花費太多的時間。
與–opt 作用有點相反的選項是- delayed。該選項導致mysqldump 寫INSERT DELAYED語句而非INSERT語句。如果您將一個資料檔案載入到另一個數據庫中並且想要使該操作對其他查詢（這些查詢可能正在數據庫中發生）造成的影響最小，則- -delayed將有助於達到這個目的。
–compress選項有助於將數據庫拷貝到另一台機器上，因為它可以減少網路傳輸中的字節數量。這裡有一個例子，請注意，為了使程式與遠程主機上的伺服器進行通信（而不是與本地主機通信），給出了–compress選項：
% mysqldump --opt samp_db |
mysql--compress -h boa.snake.net samp_db
mysqldump 有許多選項，詳細資訊請參考附錄E。
使用直接拷貝數據庫備份和拷貝方法不用mysqldump 來備份數據庫或表的另一種方法是直接拷貝表文件。通常可利用像cp、tar 或cpio這樣的實用程式來進行。本節的例子使用的是c p。
使用直接拷貝備份（direct-copy backup）方法時，必須確保沒有使用這些表。如果在拷貝一個表的同時伺服器正在修改它，則拷貝無效。
確保拷貝完整性的最好方法是關閉伺服器，拷貝文件，然後重新啟動伺服器。如果不想關閉伺服器，則應參考第13章，查閱有關在執行表檢查點時鎖定伺服器的介紹。如果伺服器在運行中，則相同的約束都適用於拷貝文件，您應該用同樣的鎖定協議使伺服器保持靜止狀態。
假定伺服器關閉，或者已經鎖定了想要拷貝的表，下面的例子將說明怎樣將整個samp_db 數據庫備份到備份目錄中（ DATADIR代表伺服器的數據目錄）：
% cd DATADIR % cp -r samp_db /usr/archive/mysql
單個表可按如下進行拷貝：
% cd DATADIR/samp_db
% cd member.* /usr/archive/mysql/samp_db
% cd score.* /usr/archive/mysql/samp_db ...
當完成備份時，可以重新啟動伺服器（如果已使它關閉），或者釋放在表上施加的鎖（如果保持伺服器運行）。要想用直接拷貝文件將數據庫從一台機器拷貝到另一台機器，只要將這些文件拷貝到另一台伺服器主機上的相應數據庫上即可。應確保這些文件是對 MyISAM表的或者兩台機器都有相同的硬體結構。否則這些表在第二個主機上看起來好象有很奇怪的內容。還應該確保第二台主機的伺服器不會在您安裝這些表時去訪問它們。
複製數據庫
術語“複製”的含義簡單地說有點像“拷貝數據庫到另一個伺服器”，或者是包含在主數據庫的內 容發生變化時次數據庫的有效更新（live updating）的含義。如果想簡單地將數據庫拷貝到另一個伺服器上，則可以使用在前面已經討論的那些命令。自MySQL3.23版本以來，就已經開始出現對基於有效更新的複製的支援。但它的功能仍未成熟，因此，在這方面筆者沒有什麼可討論的，如果有興趣，您可以注意一下當前的新版本，看看有些什麼新的開發功能。
Leave a Comment
備份數據庫的兩種主要方法是使用mysqldump 程式或直接拷貝數據庫文件（如便用cp、tar 或cpio）。每種方法都有自己的優點和缺點：
mysqldump 與MySQL伺服器聯合進行操作。直接拷貝方法與伺服器相脫離，因此必須採取措施確保在進行拷貝時沒有客戶機在修改這些表。這個問題與利用文件系統備份來備份數據庫的問題相同：如果數據庫表在文件系統備份時進行更新，則進行備份的表文件處於非一致的狀態，並且對於今後恢復該表沒有意義。文件系統備份和直接拷貝文件的區別是：對於後者，您具有控製備份進度的權利，因此可以採取措施確保伺服器使表處於靜止狀態。
mysqldump比直接拷貝技術要慢
mysqldump 產生可移植到其他機器、甚至具有不同硬體結構的機器上的文本文件。直接拷貝文件不能夠移植到其他機器上，除非要拷貝的表使用MyISAM存儲格式。ISAM 表只能在具有相同硬體結構的機器之間進行拷貝。例如，將文件從SPARC 的Solaris 機器拷貝到Intel的Solaris 機器（或者相反）是行不通的。由MySQL3.23 引進的MyISAM表存儲格式可以解決這個問題，因為該格式與機器獨立。因此，如果以下兩個條件都滿足的話，直接拷貝文件可以移植到具有不同硬體結構的機器上：即另一台機器上也必須運行MySQL3.23以上的版本，並且文件必須表示成MyISAM 表，而不是ISAM 表。
不論選擇哪種備份方法，都有某些原則，您必須堅持這些原則，才能確保在需要恢複數據庫內容時得到最好的結果：
定期執行備份。設置一個時間表並堅持使用它。告訴伺服器運行更新日誌。更新日誌在您需要恢復崩潰後的數據庫時給予幫助。在使用備份文件將數據庫恢復到備份時刻的狀態後，可以通過運行更新日誌中的查詢，重新運行備份之後所做的改變。這個操作將數據庫中的表恢復到了崩潰時刻的狀態。在文件系統備份語言中，數據庫備份文件表示完全轉儲（full dump），而更新日誌則表示增量轉儲。使用一致和可理解的備份文件命名模式。像b a c k up 1、backup2 等名字沒有特殊的含義。當需要它執行恢復時，還得浪費時間去查看文件中的內容。您會發現使用數據庫名和花時間去構造備份文件名是有好處的。例如：
% mysqldump samp_db> /usr/archives/mysql/samp_db. 1999-10-02
% mysqldump menagerie> /usr/archives/mysql/menagerie.1999-10-02
在產生備份文件後您可能需要將它們壓縮。畢竟備份文件都比較大，所以您可能還需要終止備份文件以避免它們填滿磁片，這與終止日誌文件類似。您可以用相同的技術終止備份文件：
用文件系統備份來備份您的備份文件。如果您遭受了一個完全崩潰，不僅毀壞了數據目錄而且還破壞了包含數據庫備份的磁片驅動器，那將造成真正的麻煩。您還應該備份更新日誌。
將備份文件放在與您的數據庫不同的文件系統上。這將減少含有數據字典的文件系統被生成的備份文件填滿的可能性。
創建備份的技術對於將數據庫拷貝到另一個伺服器上也是很有幫助的。將數據庫轉移到運行在另一個主機上的伺服器是很平常的，但您還可以將數據轉移到運行在相同主機上的另一個伺服器。如果正為一個新版本的MySQL運行伺服器，並且想用成品伺服器上的某些真實數據來測試它時，可能會這樣做。還有一種可能，那就是您得到了一台新的機器並要將所有的數據庫移動到新機器上。
用mysqldump 備份和拷貝數據庫
當使用mysqldump 程式產生數據庫備份文件時，缺省設置是該文件的內容由CREATE TABLE語句組成，這些語句創建被轉儲的表以及包含表中的行數據的INSERT 語句。換句話說，mysqldump創建在今後可作為對mysql的輸入使用的輸出結果，以重建數據庫。
可以將整個數據庫按以下命令轉儲到單獨的文本文件中：
該文件的其餘部分由更多的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 > gradebook.sql
% mysqldump samp_db member president > hist-league.sql
如果您正在生成備份文件並打算用這些備份文件來定期刷新另一個數據庫的內容，則可能要使用 –add-drop-table選項。此選項告訴mysqldump 將DROP TABLE IF EXISTS語句寫到備份文件中。然後，當您取出該備份文件並將其載入到第二個數據庫時，如果表已經存在將不會出現錯誤資訊。如果您正在運行第二個數據庫，可使用此技術利用從第一個數據庫中的數據拷貝來定期地載入它。
如果您正在轉儲數據庫使該數據庫可以轉換到另一個伺服器上，則無須創建備份文件。應確保該數據庫存在於另一台主機上，然後用一個管道使mysql直接讀取mysqldump的輸出結果來轉儲數據庫。例如，如果想要將samp_db 數據庫從pit_viper.snake.net 拷貝到boa.snake.net，操作如下：
% mysqladmin -h boa.snake.netcreate samp_db
% mysqldump samp_db | mysql-h boa.snake.net samp_db
稍後，如果想要在boa.snake.net 中再次刷新該數據庫，可跳過mysqladmin 命令，但要將–add-drop-table增加到mysqldump 中，以避免得到有關“表已經存在”的錯誤：
% mysqldump --add-drop-table samp_db |
mysql-h boa-snake.net samp_db
mysqldump 的其他選項包括如下所示的幾個：
–flush-log 和–lock-tables 的結合有助於檢查數據庫。–lock-table鎖定所有正在轉儲的表，而–flush-log關閉並重新打開更新日誌文件。如果正在產生後續的更新日誌，則新的更新日誌將只包含從備份的那一點開始修改數據庫的查詢。這時檢查對於該備份時間的更新日誌的檢查點（然而，鎖定所有的表對於備份期間客戶機訪問來說不太好，如果您有需要執行更新操作的客戶機的話）。
如果用–flush- logs檢查對於備份時間的更新日誌檢查點，最好轉儲整個數據庫。如果轉儲單個文件，則將更新日誌的檢查點與備份文件同步是比較難的。在恢復操作中，您通常在總數據庫（per- database）的基礎上抽取更新日誌的內容。對於抽取單個表的更新日誌來說沒有選項，因此您必須自己抽取它們。
缺省設置時，mysqldump將表的全部內容在寫之前讀到記憶體中。這實際上不是必須的，事實上，如果您真的有大型表的話，這幾乎是一個失敗的方法。可以用–quick選項告訴mysqldump 寫每一行（只要是被檢索的）。要想進一步優化該轉儲過程，可用- - opt來代替- - quick。– opt 選項開啟其他的選項，這些選項將加快轉儲數據和讀回數據的速度。由於快速備份的好處，使得用–opt 執行備份成為最常用的方法。但是，要當心， - -opt 選項有一個代價： –opt所優化的是您的備份過程，而不是由其他客戶機對數據庫的訪問。–opt 選項可防止任何人更新被鎖定的正在轉儲的任何表。您會很容易地發現在常規數據庫訪問中在這一點上所做的努力。試著在一天中數據庫通常最繁忙的時刻運行一個備份。這不會花費太多的時間。
與–opt 作用有點相反的選項是- delayed。該選項導致mysqldump 寫INSERT DELAYED語句而非INSERT語句。如果您將一個資料檔案載入到另一個數據庫中並且想要使該操作對其他查詢（這些查詢可能正在數據庫中發生）造成的影響最小，則- -delayed將有助於達到這個目的。
–compress選項有助於將數據庫拷貝到另一台機器上，因為它可以減少網路傳輸中的字節數量。這裡有一個例子，請注意，為了使程式與遠程主機上的伺服器進行通信（而不是與本地主機通信），給出了–compress選項：
% mysqldump --opt samp_db |
mysql--compress -h boa.snake.net samp_db
mysqldump 有許多選項，詳細資訊請參考附錄E。
使用直接拷貝數據庫備份和拷貝方法不用mysqldump 來備份數據庫或表的另一種方法是直接拷貝表文件。通常可利用像cp、tar 或cpio這樣的實用程式來進行。本節的例子使用的是c p。
使用直接拷貝備份（direct-copy backup）方法時，必須確保沒有使用這些表。如果在拷貝一個表的同時伺服器正在修改它，則拷貝無效。
確保拷貝完整性的最好方法是關閉伺服器，拷貝文件，然後重新啟動伺服器。如果不想關閉伺服器，則應參考第13章，查閱有關在執行表檢查點時鎖定伺服器的介紹。如果伺服器在運行中，則相同的約束都適用於拷貝文件，您應該用同樣的鎖定協議使伺服器保持靜止狀態。
假定伺服器關閉，或者已經鎖定了想要拷貝的表，下面的例子將說明怎樣將整個samp_db 數據庫備份到備份目錄中（ DATADIR代表伺服器的數據目錄）：
% cd DATADIR % cp -r samp_db /usr/archive/mysql
單個表可按如下進行拷貝：
% cd DATADIR/samp_db
% cd member.* /usr/archive/mysql/samp_db
% cd score.* /usr/archive/mysql/samp_db ...
當完成備份時，可以重新啟動伺服器（如果已使它關閉），或者釋放在表上施加的鎖（如果保持伺服器運行）。要想用直接拷貝文件將數據庫從一台機器拷貝到另一台機器，只要將這些文件拷貝到另一台伺服器主機上的相應數據庫上即可。應確保這些文件是對 MyISAM表的或者兩台機器都有相同的硬體結構。否則這些表在第二個主機上看起來好象有很奇怪的內容。還應該確保第二台主機的伺服器不會在您安裝這些表時去訪問它們。
複製數據庫
術語“複製”的含義簡單地說有點像“拷貝數據庫到另一個伺服器”，或者是包含在主數據庫的內 容發生變化時次數據庫的有效更新（live updating）的含義。如果想簡單地將數據庫拷貝到另一個伺服器上，則可以使用在前面已經討論的那些命令。自MySQL3.23版本以來，就已經開始出現對基於有效更新的複製的支援。但它的功能仍未成熟，因此，在這方面筆者沒有什麼可討論的，如果有興趣，您可以注意一下當前的新版本，看看有些什麼新的開發功能。
Leave a Comment
Comments
Post a Comment