對mysql數據進行備份，常見的方式如以下三種，可能有很多人對備份時數據一致性並不清楚
1、直接拷貝整個數據目錄下的所有文件到新的機器。優點是簡單、快速，只需要拷貝；缺點也很明顯，在整個備份過程中新機器處於完全不可用的狀態，且目的無法釋放源數據文件中因爲碎片導致的空間浪費和無法回收已發生擴展的innodb表空間。
2、用xtrabackup進行熱備。優點是備份過程中可繼續提供服務；缺點和第一種方法差不多，目的分區無法釋放源數據文件中因爲碎片導致的空間浪費和無法回收已發生擴展的innodb表空間。
3、使用官方自帶的mysqldump邏輯重做。優點是在整個備份過程中可以向外提供服務，最重要的一點是可以解決碎片浪費。
以上幾種方法相信大家也都很熟悉，就不再詳細介紹。下面主要講解一下mysqldump備份時如何保持數據的一致性。
mysqldump對不同類型的存儲引擎，內部實現也不一樣。主要是針對兩種類型的存儲引擎：支持事務的存儲引擎（如InnoDB）和不支持事務的存儲引擎（如MyISAM），下面分別看看這兩種存儲引擎的實現：
1、對於支持事務的引擎如InnoDB，參數上是在備份的時候加上--single-transaction保證數據一致性
--single-transaction實際上通過做了下面兩個操作：
①、在開始的時候把該session的事務隔離級別設置成repeatable read；
②、然後啓動一個事務（執行bigin），備份結束的時候結束該事務（執行commit）
有了這兩個操作，在備份過程中，該session讀到的數據都是啓動備份時的數據（同一個點）。可以理解爲對於innodb引擎來說加了該參數，備份開始時就已經把要備份的數據定下來了，備份過程中的提交的事務時是看不到的，也不會備份進去。
2、對於不支持事務的引擎如MyISAM，只能通過鎖表來保證數據一致性，這裏分三種情況：
①、導出全庫：加--lock-all-tables參數，這會在備份開始的時候啓動一個全局讀鎖（執行flush tables with read lock），其他session可以讀取但不能更新數據，備份過程中數據沒有變化，所以最終得到的數據肯定是完全一致的；
②、導出單個庫：加--lock-tables參數，這會在備份開始的時候鎖該庫的所有表，其他session可以讀但不能更新該庫的所有表，該庫的數據一致；
③、導出單個表：加--lock-tables參數，這會在備份開始的時候鎖該表，其他表不受影響，該表數據一致。
上面只是展示了對不同引擎來講加的參數只是爲了讓數據保持一致性，但在備份中業務並沒有停止，時刻可能有新的數據進行寫入，爲了讓我們知道備份時是備份了哪些數據，或者截止到那個指針（二進制日誌），我們可以再加入 --master-data參數，備份好的sql文件就會記錄從備份截至到哪個指針，指針之後的數據更新我們可以通過二進制日誌進行恢復。
# mysqldump -u root -p --single-transaction --master-data --flush-log --database test > test.sql --> --flush-log 表示備份開始之後的更行都切到下一個二進制日誌
可以在備份的test.sql文件中前幾行看到記錄着備份當時的二進制日誌信息
# vim test.sql --CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=436263492; ---- Current Database: `test` ..... # mysqlbinlog --start-position=436263492 mysql-bin.000004 > 00004.sql -->在全備恢復之後，我們可以通過之後的二進制日誌進行恢復
另外解釋下mysqldump備份時爲什麼要鎖表才能保持數據的一致性:
說明：
1、在t1時間點，用mysqldump啓動不鎖表備份；
2、先導出a表，共耗時5分鐘，因爲沒有鎖表，在這5分鐘內b表insert了10行數據；
3、到了t2時間點，a表導出完成，開始導出b表；
4、導出b表耗時10分鐘，在導出b表的過程中，a、b表均沒有數據變化；
5、到了t3時間點，b表導出完成，全部備份結束；
6、然後備機從t1時間點的binlog位置開始應用binlog，最後備機中b表的數據比主機多10行，數據不一致。
從這個圖可以看出，對於不支持事務的存儲引擎如MyISAM如果備份過程中不鎖表，不同表開始備份時對應的binlog和pos是不一致的，這時候所有表都從備份開始的點應用binlog，有很大肯會出現數據不一致（備份過程中所有表均無數據更新除外）。
本文來自我的個人博客：http://www.forgecode.cn/231.html