我們的大多數客戶使用mysql。雖然他們中的多數進行了備份，但是這當中存在許多錯誤，也從未進行過測試。
為什麼會發生這樣的問題，如何發生的？有很多種可能，所以我們先來看一下備份mysql的好方法和壞方法的區別。
從 庫 - 很多人認為備份從庫是個不錯的辦法。但是即便他們正確地（實際上未必）備份了mysql資料庫，這也不是個好注意。為什麼？因為從資料庫的資料經常會與主 資料庫相不一致。為什麼？很多原因，其中包含mysql本身的問題，也有可能是一些sql語句沒有被從資料庫正確的複製（看到過日誌裡面的warning 資訊吧？）。或者複製由於某種錯誤類似死鎖和超時而停止，然後被不正確地重新啟動或跳過。又或者在系統執行中的某個時刻(也許是多年以前)曾有認識不足的 skip操作或配置修改，從而導致了資料的不一致。
基本上，你不應該相信從庫資料是正確無誤的，因此應該避免在從庫上備份資料庫，除非主庫非常繁忙或者出於其他原因不能處理效能或有關備份鎖定的問題。即便是這種情況，您依然應該使用類似percona的複製檢查工具來檢查同步工作從而確認從庫資料是否正確無誤。
鎖 問題 – 我們接手的多數客戶過去使用了難於備份的myisam表（乙個糟糕的主意，參考其他部落格）。 對於myisam來說唯一好的備份辦法就是在備份期間鎖住整個資料庫，通常是幾分鐘甚至幾小時，事實上造成了**長時間內的功能不正常。 這個問題可以通過使用innodb引擎來避免，但有些客戶採用了其他方法：如使用mysqlbackup在乙個非鎖模式下進行備份，又或者使用或不使用快 照來直接備份檔案，等等。 這些其他的方法都沒用，因為資料可能被損壞或者不一致。
myisam/innodb 引擎混合使用問題。很多客戶同時使用mysam和inndb表，他們嘗試使用標準的innodb single transaction單事務模式進行資料備份，但是對於myisam資料表來說這是乙個錯誤的方法（直到他們恢復資料的時候，才會發現）。有時會更糟， 很多客戶不知道他們使用的是myisam資料引擎，開發人員在沒有檢查預設資料引擎的情況下建立了很多myisam表，並且毫不知情。 在5.1或更早的mysql版本中，預設引擎就是myisam。我們的監控系統會發現這種情況，但是多數客戶對此並不清楚還在備份不一致的資料。
正 確的方式 – 正確的做法是仔細規劃和選擇備份選項，主要基於是否存在myisam表。首先，盡可能備份主庫。其次，如果全是innodb表，使用single transaction模式或者lvm快照方式進行備份，並且確認不存在myisam表(系統自帶的mysql庫不算)。第三，如果存在myisam表， 那麼使用percona工具檢測主從資料庫的一致性，此時如有需要可備份從庫。
備份mysql資料庫不容易做到完美，它需要優秀的知識、工具和監控。長久以來，我們一直致力於這些問題，以確保客戶資料的安全性和可靠性。
mysql的備份指令碼 mysql的備份指令碼
1 描述 我相信很多朋友在工作都都會有這種需求，老闆或領導讓你每天都要備份mysql資料庫，你該如何實現呢，是每天到一定的時間在伺服器上敲一遍mysql的備份命令，還是想寫個指令碼，定時定點的自動備份呢？我相信大家都想讓它自動備份，接下來我通 shell指令碼 定時任務 的方式來實現自動備份mysq...
mysql備份 MySQL備份指令碼
第乙個指令碼 bin bash mysql備份指令碼bak dir data backup date y m d mysqldb 資料庫名mysqluser 使用者mysqlpwd 密碼mysqlcmd usr bin mysqldumpmysqlser 資料庫伺服器mysqlport 埠if d ...
mysql月備份 MySQL 備份
備份資料庫 匯出全部資料庫 all databases,a 匯出幾個資料庫。引數後面所有名字參量都被看作資料庫名 databases,b 匯出儲存過程以及自定義函式 routines,r 匯出事件 events,e 不緩衝查詢，直接匯出到標準輸出。預設為開啟狀態，使用 skip quick取消該選項...