InnoDB 中文參考手冊(cè) --- 6 備份和恢復(fù) InnoDB 數(shù)據(jù)庫
2024-07-21 02:08:52
供稿：網(wǎng)友
innodb 中文參考手冊(cè) --- 犬犬(心帆)翻譯 6 備份和恢復(fù) innodb 數(shù)據(jù)庫
安全的數(shù)據(jù)庫管理就是使用正規(guī)的數(shù)據(jù)備份。
innodb hot backup 是一個(gè)在線備份工具，你可以在 innodb 數(shù)據(jù)庫運(yùn)行時(shí)使用它來實(shí)現(xiàn)在線備份。innodb hot backup 不需要你關(guān)閉你的服務(wù)器也不需要加任何鎖或影響其它普通的數(shù)據(jù)操作。innodb hot backup 是一個(gè)非免費(fèi)的附加工具，它的費(fèi)用為每 mysql 服務(wù)器每年 400 歐元。瀏覽網(wǎng)頁 innodb hot backup homepage 可獲得更多的信息以及程序屏幕截圖。
如果你可以關(guān)閉你的 mysql 服務(wù)，那么可以通過下面幾個(gè)步驟進(jìn)行數(shù)據(jù)庫的“二進(jìn)制”備份：
關(guān)閉 mysql 數(shù)據(jù)庫服務(wù)，并確定在關(guān)閉時(shí)沒有發(fā)生任何錯(cuò)誤 將你的所有數(shù)據(jù)文件復(fù)制到一個(gè)安全的地方 將所有的 innodb 日志文件復(fù)制到一個(gè)安全的地方 將 my.cnf 配置文件復(fù)制到一個(gè)安全的地方 將所有的 innodb 表 .frm 文件復(fù)制到一個(gè)安全的地方
在需要高性能的數(shù)據(jù)庫服務(wù)站點(diǎn)上，可以通過 mysql 的復(fù)制特性來保持?jǐn)?shù)據(jù)庫的一個(gè)副本，mysql 的復(fù)制特性同樣適用于 innodb 表類型。
除了上面描述的二進(jìn)制備份方式之外，最好定期地使用 mysqldump 轉(zhuǎn)儲(chǔ)數(shù)據(jù)表。原因是二進(jìn)制文件可能會(huì)在你未注意時(shí)而被破壞，而表轉(zhuǎn)儲(chǔ)(dump)文件是以文本文件方式保存的，它與二進(jìn)制文件相比更簡(jiǎn)單、有更好的的可讀性。因?yàn)檗D(zhuǎn)儲(chǔ)文件更簡(jiǎn)單所以更容易發(fā)現(xiàn)表損壞， 重要數(shù)據(jù)損環(huán)的可能性很小。
一個(gè)好的主意就是在對(duì)數(shù)據(jù)庫做二進(jìn)制備份的同時(shí)也做一個(gè)轉(zhuǎn)儲(chǔ)(dump)備份。為了得到一致的數(shù)據(jù)快照，必須關(guān)閉所有客戶端的連接。然后就可以進(jìn)行二進(jìn)制備份，這樣你就有了數(shù)據(jù)一致的兩種格式的備份。
如了實(shí)現(xiàn)通過上面所述的二進(jìn)制備份方法將 innodb 數(shù)據(jù)庫恢復(fù)到當(dāng)前狀態(tài)，必須打開 mysql 的二進(jìn)制日志(binlogging)開關(guān)。這樣你就可以二進(jìn)制日志 與備份數(shù)據(jù)配合實(shí)現(xiàn)分時(shí)間點(diǎn)的恢復(fù)：
mysqlbinlog yourhostname-bin.123 | mysql
為了恢復(fù)一個(gè)崩潰了的 mysql 服務(wù)進(jìn)程，你所能做的唯一一件事就是重新啟動(dòng)。innodb 將自動(dòng)地檢查日志并完成數(shù)據(jù)庫的前滾(roll-forward)到當(dāng)前狀態(tài)。同時(shí)，innodb 將自動(dòng)回滾崩潰前未提交的事務(wù)。在恢復(fù)過程中，mysqld 將顯示如下所示的提示：
[email protected]:~/mysql-3.23.48/sql> mysqld 020204 23:08:31 innodb: database was not shut down normally. innodb: starting recovery from log files... innodb: starting log scan based on checkpoint at innodb: log sequence number 0 177573790 innodb: doing recovery: scanned up to log sequence number 0 177638912 innodb: doing recovery: scanned up to log sequence number 0 177704448 innodb: doing recovery: scanned up to log sequence number 0 177769984 innodb: doing recovery: scanned up to log sequence number 0 177835520 innodb: doing recovery: scanned up to log sequence number 0 177901056 innodb: doing recovery: scanned up to log sequence number 0 177966592 innodb: doing recovery: scanned up to log sequence number 0 178032128 innodb: doing recovery: scanned up to log sequence number 0 178097664 innodb: doing recovery: scanned up to log sequence number 0 178163200 innodb: doing recovery: scanned up to log sequence number 0 178228736 innodb: after this prints a line for every 10th scan sweep: innodb: doing recovery: scanned up to log sequence number 0 178884096 ... innodb: doing recovery: scanned up to log sequence number 0 193302016 innodb: doing recovery: scanned up to log sequence number 0 193957376 innodb: doing recovery: scanned up to log sequence number 0 194612736 020204 23:08:40 innodb: starting an apply batch of log records to the database. .. innodb: progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 innodb: apply batch completed innodb: doing recovery: scanned up to log sequence number 0 195268096 innodb: doing recovery: scanned up to log sequence number 0 195923456 ... innodb: doing recovery: scanned up to log sequence number 0 203132416 innodb: doing recovery: scanned up to log sequence number 0 203787776 innodb: doing recovery: scanned up to log sequence number 0 204443136 innodb: 5 uncommitted transaction(s) which must be rolled back innodb: trx id counter is 0 129792 innodb: starting rollback of uncommitted transactions innodb: rolling back trx with id 0 129400 innodb: rolling back of trx id 0 129400 completed innodb: rolling back trx with id 0 129217 innodb: rolling back of trx id 0 129217 completed innodb: rolling back trx with id 0 129098 innodb: rolling back of trx id 0 129098 completed innodb: rolling back trx with id 0 128743 innodb: rolling back of trx id 0 128743 completed innodb: rolling back trx with id 0 127939 innodb: rolling back of trx id 0 127939 completed innodb: rollback of uncommitted transactions completed 020204 23:08:51 innodb: starting an apply batch of log records to the database. .. innodb: progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 innodb: apply batch completed innodb: last mysql binlog file offset 0 40418561, file name ./donna-bin.001 020204 23:08:53 innodb: flushing modified pages from the buffer pool... 020204 23:09:03 innodb: started mysqld: ready for connections
如果數(shù)據(jù)庫遭到損壞或磁盤失敗，則不得不從一個(gè)備份文件恢復(fù)。在損壞的情況下，首先可以恢復(fù)一個(gè)未損壞的備份文件。然后依照 mysql 手冊(cè)提示從一般的日志文件中恢復(fù)數(shù)據(jù)。
在某些數(shù)據(jù)庫損壞的情況下，可能通過轉(zhuǎn)儲(chǔ)(dump)、撤銷(drop)和重新建立一個(gè)或多個(gè)損壞的表就足夠了。可憐通過 check table sql 命令檢查一個(gè)受損的表，雖然 check table 并不能發(fā)現(xiàn)所有的損壞類型。你可能使用 innodb_tablespace_monitor 來檢查數(shù)據(jù)文件時(shí)的文件空間管理的完整性。
在某些情況下，數(shù)據(jù)庫頁面顯示損壞，而實(shí)際上是由于操作系統(tǒng)的文件高速緩沖損壞，而磁盤上的數(shù)據(jù)文件還是好的。 這時(shí)最好先重起你的系統(tǒng)。這可能解決數(shù)據(jù)庫頁面錯(cuò)誤。
6.1 強(qiáng)制(forcing)恢復(fù)
如果出現(xiàn)數(shù)據(jù)庫頁面損壞，可以通過 select into outfile 從數(shù)據(jù)庫中轉(zhuǎn)儲(chǔ)出表數(shù)據(jù)，通常大部分的數(shù)據(jù)并未受損壞。 但是這些損壞可能引起 select * from table 或 innodb 后臺(tái)操作崩潰或中斷(assert)，甚至是 innodb 的前滾(roll-forward)恢復(fù)崩潰。從 innodb version 3.23.44 開始，在 my.cnf 中有個(gè)設(shè)置選項(xiàng)可以強(qiáng)制 innodb 啟動(dòng)，以及防止后臺(tái)操作的運(yùn)行，因而你可以轉(zhuǎn)儲(chǔ)數(shù)據(jù)。例如，你可以 my.cnf 在中加入如下設(shè)置：
set-variable = innodb_force_recovery = 4
innodb_force_recovery 代替選擇將在下面列出。 這個(gè)參數(shù)不能用于數(shù)據(jù)庫的其它方面！當(dāng)設(shè)置值大于 0 時(shí)，作為安全尺度，innodb 禁止用戶使用 insert, update, 或 delete 。
從 3.23.53 和 4.0.4 開始，即使強(qiáng)制恢復(fù)被使用你也可以使用 drop 或 create 一個(gè)表。 如果你確定表如引起回滾崩潰，你可以移除(drop)它。你也可以通過這個(gè)停止一個(gè)因?qū)氪罅繑?shù)據(jù)或 alter table 而引起的失控(runaway)回滾。你可以殺死 mysqld 進(jìn)程，并使用 my.cnf 設(shè)置項(xiàng) innodb_force_recovery=3 不使用回滾。然后就可以 drop 那個(gè)引起失控(runaway)回滾的表。
下面較大的數(shù)意味著包含所有較低數(shù)所對(duì)就的安全防范。為了能夠轉(zhuǎn)儲(chǔ)表設(shè)置至少為 4 ，這是相對(duì)安全的，僅僅只有一些損壞的頁面數(shù)據(jù)掉失。option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into b-trees and other database structures. 1 (srv_force_ignore_corrupt) 即使發(fā)現(xiàn)一個(gè)錯(cuò)誤也啟動(dòng)服務(wù)；試著使用 select * from table 跳過損壞的索引記錄和頁面，這將幫助轉(zhuǎn)儲(chǔ)表。 2 (srv_force_no_background) prevent the main thread from running: 如果在清理過程中將發(fā)生崩潰，這將預(yù)防它。 3 (srv_force_no_trx_undo) 恢復(fù)時(shí)不運(yùn)行事務(wù)回滾。 4 (srv_force_no_ibuf_merge) 防止插入緩沖區(qū)的歸并操作：如果他們將引起崩潰，最好不要操作他們；不要考慮表統(tǒng)計(jì)(table statistics)。 5 (srv_force_no_undo_log_scan) 當(dāng)啟動(dòng)數(shù)據(jù)庫時(shí)不撤銷日志(undo logs)：innodb 將未完成的事務(wù)已提交。 6 (srv_force_no_log_redo) do not do the log roll-forward in connection with recovery.
6.2 檢查點(diǎn)(checkpoints)
innodb 通過調(diào)用一個(gè)模糊的檢查點(diǎn)來實(shí)現(xiàn)檢查點(diǎn)機(jī)制。innodb 以很小的批量從緩沖池中刷新修改了的數(shù)據(jù)庫頁面。這就不需要在一個(gè)批量中刷新整個(gè)緩沖池，因這個(gè)實(shí)話上將可能停止用戶 sql 語句運(yùn)行進(jìn)程一段時(shí)間。
in crash recovery innodb 在崩潰修復(fù)時(shí)會(huì)檢查記錄在日志文件中的檢查點(diǎn)標(biāo)簽。它知道，在標(biāo)簽前所有對(duì)數(shù)據(jù)庫的修改已被記錄到數(shù)據(jù)庫的磁盤鏡像中。然后 innodb 掃描日志文件中檢查點(diǎn)后面的日志并將修改記入數(shù)據(jù)庫。
innodb 以一個(gè)環(huán)形方式記錄日志文件。所有使緩沖池中的數(shù)據(jù)庫頁面與磁盤鏡像不相同已提交了的修改必須記錄在日志文件中，以防 innodb 需要恢復(fù)。 這就意味著 innodb 以環(huán)形方式重新啟用一個(gè)日志文件，它必須確定將被重新使用的日志文件中的操作日志結(jié)果已被磁盤鏡像文件包含。用另一句話來說就是，innodb 必須時(shí)常地建立檢查點(diǎn)并將修改了的數(shù)據(jù)庫頁面更新到磁盤中。
上面所述要以解釋為什么將日志文件設(shè)置和大一點(diǎn)可以減少因建立檢查點(diǎn)所用的磁盤 i/o。 這就可以理解設(shè)置日志文件的總尺寸與緩沖池一樣大或更大。大的日志文件的缺點(diǎn)就是當(dāng)進(jìn)行崩潰修復(fù)時(shí)將需要很長(zhǎng)的時(shí)間，因?yàn)橛懈嗟牟僮魅罩拘枰碌綌?shù)據(jù)庫中。
注冊(cè)會(huì)員，創(chuàng)建你的web開發(fā)資料庫，
