資料庫的備份是極其重要的事情。如果沒有備份，遇到下列情況就會抓狂：
update or delete whitout where…
table was dropped accidentally…
innodb was corrupt…
entire datacenter loses power…
從資料安全的角度來說，伺服器磁碟都會做raid，mysql本身也有主從、drbd等容災機制，但它們都無法完全取代備份。容災和高可用能幫我們有效的應對物理的、硬體的、機械的故障，而對我們犯下的邏輯錯誤卻無能為力。每一種邏輯錯誤發生的概率都極低，但是當多種可能性疊加的時候，小概率事件就放大成很大的安全隱患，這時候備份的必要性就凸顯了。那麼在眾多的mysql備份方式中，哪一種才是適合我們的呢？
mysql本身為我們提供了mysqldump、mysqlbinlog遠端備份工具，percona也為我們提供了強大的xtrabackup，加上開源的mydumper，還有基於主從同步的延遲備份、從庫冷備等方式，以及基於檔案系統快照的備份，其實選擇已經多到眼花繚亂。而備份本身是為了恢復，所以能夠讓我們在出現故障後迅速、準確恢復的備份方式，就是最適合我們的，當然，同時能夠省錢、省事，那就非常完美。下面就我理解的幾種備份工具進行一些比較，**下它們各自的適用場景。
1. 盡量不用myisam表。
2. xtrabackup增加了–rsync選項，通過兩次rsync來減少持有全域性鎖的時間。
缺點：需要獲取全域性鎖，如果遇到長查詢，等待時間將不可控，因此要做好監控，必要時殺死長查詢或自殺；遇到超大的例項，備份過程較長，redo log太大會影響恢復速度，這種情況下最好採用延遲備份。
上述所有的備份方式，都只能把資料庫恢復到備份的某個時間點：mysqldump和mydumper，以及snapshot是備份開始的時間點；xtrabackup是備份結束的時間點。要想實現point in time的恢復，還必須備份binlog。同時binlog也是實現增備的寶貴資源。
幸運的是，mysql 5.6為我們提供了遠端備份binlog的選項：
mysqlbinlog --raw --read-from-remote-server --stop-never
它會偽裝成mysql從庫，從遠端獲取binlog然後進行轉儲。這對線上主庫容量不夠無法儲存較多binlog的場景非常有用。但是，它畢竟不像真正的mysql從庫例項，狀態監控和同步都需要單獨部署。因此個人覺得採用blackhole來備份全量的binlog是更好的選擇。筆者曾經實現過乙個自動搭建blackhole從庫的工具，稍加修改，就可以完美搭建出blackhole從庫。一旦同步起來，基本一勞永逸，很少出問題，主從切換的時候跟著切了就行。
備份方式各有千秋，而對我們來說，面對數千例項，選擇合適的備份工具來實現統一配置、統一規劃，構建智慧型排程的備份雲平台才是王道。畢竟，多種備份方式共存的運維成本是不容忽視的。
從使用經驗來看，用xtrabackup全備資料，用blackhole增備binlog，並定期對備份資料的有效性進行驗證，是當下比較好的選擇。
為MySQL選擇合適的備份方式
資料庫的備份是極其重要的事情。如果沒有備份，遇到下列情況就會抓狂 update or delete whitout where table was dropped accidentally innodb was corrupt entire datacenter loses power 從資料安全的...
mysql 備份 為MySQL選擇合適的備份方式
資料庫的備份是極其重要的事情。如果沒有備份，遇到下列情況就會抓狂 update or delete whitout where table was dropped accidentally innodb was corrupt entire datacenter loses power 從資料安全的...
為Mysql選擇合適的資料型別
前提 使用適合儲存引擎。選擇原則 根據選定的儲存引擎，確定如何選擇合適的資料型別。下面的選擇方法按儲存引擎分類 對於innodb資料表，內部的行儲存格式沒有區分固定長度和可變長度列 所有資料行都使用指向資料列值的頭指標 因此在本質上，使用固定長度的char列不一定比使用可變長度varchar列簡單。...