mysqldump備份原理
備份的基本流程如下：
1.調用FTWRL(flush tables with read lock)，全局禁止讀寫
2.開啓快照讀，獲取此時的快照(僅對innodb表起作用)
3.備份非innodb表數據(*.frm,*.myi,*.myd等)
4.非innodb表備份完畢後，釋放FTWRL鎖
5.逐一備份innodb表數據
6.備份完成。
shell> mysqldump --all-databases --master-data --single-transaction > all_databases.sql
執行流程
（1）FLUSH TABLES
（2）FLUSH TABLES WITH READ LOCK
（3）SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
（4）START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
（5）SHOW MASTER STATUS
（6）UNLOCK TABLES
global read lock的持續時間很短，獲取當前binlog的位置信息後立即釋放；
注意： 在執行時如果當前有一個事務長時間沒有結束，那麼FLUSH TABLES WITH READ LOCK將會一直等待，而更加嚴重的是，阻塞的FLUSH TABLES WITH READ LOCK會進一步阻塞後續的DML，從而造成mysql hang；
Mydumper
Mydumper原理與Mysqldump原理類似，最大的區別是引入了多線程備份，每個備份線程備份一部分表，當然併發粒度可以到行級，達到多線程備份的目的。
如何保證備份的一致性，其實關鍵還是在於FTWRL。
對於非innodb表，在釋放鎖之前，需要將表備份完成。
對於innodb表，需要確保多個線程都能拿到一致性位點，這個動作同樣要在持有全局鎖期間完成，因爲此時數據庫沒有讀寫，可以保證位點一致
xtrabackup
innobackupex的基本流程如下：
1.開啓redo日誌拷貝線程，從最新的檢查點開始順序拷貝redo日誌；
2.開啓idb文件拷貝線程，拷貝innodb表的數據
3.idb文件拷貝結束，通過"LOCK BINLOG FOR BACKUP"來獲取一致性位點；
4.通過LOCK TABLES FOR BACKUP命令來備份非innodb表數據；
5.由於此時沒有新事務提交，等待redo日誌拷貝完成
6.最新的redo日誌拷貝完成後，相當於此時的innodb表和非innodb表數據都是最新的
7.獲取binlog位點，此時數據庫的狀態是一致的。
8.釋放鎖，備份結束。
LOCK TABLES FOR BACKUP
作用：備份數據
1.禁止非innodb表更新
2.禁止所有表的ddl
優化點：
1.不會被大查詢堵塞(關閉表)
2.不會堵塞innodb表的讀取和更新，這點非常重要，對於業務表全部是innodb的情況，則備份過程中DML完全不受損
UNLOCK TABLES
LOCK BINLOG FOR BACKUP
作用：獲取一致性位點。
1.禁止對位點更新的操作
優化點：
1.允許DDl和更新，直到寫binlog爲止。
UNLOCK BINLOG
FTWRL(flush tables with read lock)
無論是哪種備份工具，爲了獲取一致性位點，都強依賴於FTWRL。這個鎖殺傷力非常大，因爲持有鎖的這段時間，整個數據庫實質上不能對外提供寫服務的。
由於FTWRL需要關閉表，如有大查詢，會導致FTWRL等待，進而導致DML堵塞的時間變長。
即使是備庫，也有SQL線程在複製來源於主庫的更新，上全局鎖時，會導致主備庫延遲。
FTWRL這把鎖持有的時間主要與非innodb表的數據量有關，如果非innodb表數據量很大，備份很慢，那麼持有鎖的時間就會很長。
即使全部是innodb表，也會因爲有mysql庫系統表存在，導致會鎖一定的時間。