無論邏輯備份還是物理備份，為了獲取一致性位點，都強依賴於FTWRL(Flush Table With Read Lock)。這個鎖殺傷力非常大，因為持有鎖的這段時間，整個資料庫實質上不能對外提供寫服務的。此外，由於FTWRL需要關閉表，如有大查詢，會導致FTWRL等待，進而導致DML堵塞的時間變長。 ...
無論邏輯備份還是物理備份，為了獲取一致性位點，都強依賴於FTWRL(Flush Table With Read Lock)。這個鎖殺傷力非常大，因為持有鎖的這段時間，整個資料庫實質上不能對外提供寫服務的。此外，由於FTWRL需要關閉表，如有大查詢，會導致FTWRL等待，進而導致DML堵塞的時間變長。即使是備庫，也有SQL線程在複製來源於主庫的更新，上全局鎖時，會導致主備庫延遲。FTWRL這把鎖持有的時間主要與非innodb表的數據量有關，如果非innodb表數據量很大，備份很慢，那麼持有鎖的時間就會很長。即使全部是innodb表，也會因為有mysql庫系統表存在，導致會鎖一定的時間。為瞭解決這個問題，Percona公司對Mysql的Server層做了改進，引入了BACKUP LOCK，具體而言，通過"LOCK TABLES FOR BACKUP"命令來獲取一致性數據(包括非innodb表)；通過"LOCK BINLOG FOR BACKUP"來獲取一致性位點，儘量減少因為資料庫備份帶來的服務受損，我們將這一特性引入到AliSQL，下麵詳細介紹這個特性。
功能介紹
在MysqlServer層新增2種類型MDL全局範圍鎖，backup-lock和binlog-lock，並新增了3種語法：
1.LOCK TABLES FOR BACKUP，執行語句申請backup-lock的共用鎖，通過unlock tables釋放鎖。
2.LOCK BINLOG FOR BACKUP，執行語句申請binlog-lock的共用鎖，通過unlock binlog釋放鎖。
3.UNLOCK BINLOG，釋放LOCK BINLOG FOR BACKUP持有的鎖。
對於backup-lock：
已經持有lock table for backup後，如果在本會話執行更新操作(非innodb表)，會報錯；如果在其它會話執行更新操作，會等待。show processlit 可以看到會話處於"Waiting for backup lock"狀態。
對於binlog-lock：
已經持有lock binlog for backup後，如果本會話執行更新操作，不會報錯，因為不會堵塞會話；如果其它會話執行，則會等待。show processlist 可以看到會話處於"Waiting for binlog lock"狀態。
下麵介紹具體的原理和相關介面的實現
A:備份操作
申請backup-lock，持有(backup,MDL_SHARED,MDL_EXPLICIT)鎖
B:庫的DDL操作
調用lock_schema_name加庫對象鎖(修改庫操作，schema_lock)
介面(mysql_create_db, mysql_alter_db, mysql_rm_db, mysql_upgrade_db等)
1.如果已經持有全局鎖(backup,global)，則報錯。
2.加庫的排它鎖(SCHEMA, MDL_EXCLUSIVE, MDL_TRANSACTION)
3.申請IX範圍鎖，避免後續的global和backup lock進來
(global,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)
(backup,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)
C:表的DDL操作
調用lock_table_names加表對象鎖(修改表操作)
介面(mysql_rename_tables, mysql_rm_table, mysql_drop_view, truncate_table等)
1.加表對象鎖(TABLE, MDL_EXCLUSIVE, MDL_TRANSACTION)
2.加上對應schema的對象鎖(SCHEMA,MDL_INTENTION_EXCLUSIVE,MDL_TRANSACTION),避免庫的ddl操作。
3.如果已經持有全局鎖(backup,global)，則報錯。
4.申請IX範圍鎖，避免後續的global和backup lock進來
(global,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)
(backup,MDL_INTENTION_EXCLUSIVE,MDL_STATEMENT)
D:表的DML操作
調用acquire_protection來申請IX範圍鎖
介面open_table
這裡只針對非innodb引擎，且是寫操作的表
mdl_request.type >= MDL_SHARED_WRITE && share->db_type()->flags & HTON_SUPPORTS_ONLINE_BACKUPS
引入備份鎖的優勢
LOCK TABLES FOR BACKUP
作用：獲取一致性數據
1.禁止非innodb表更新
2.禁止所有表的ddl
優化點：
1.不會被大查詢堵塞(沒有flush tables 導致關閉表操作)
2.不會堵塞innodb表的讀取和更新，這點非常重要，對於業務表全部是並innodb的情況，則備份過程中DML完全不受損
LOCK BINLOG FOR BACKUP
作用：獲取一致性位點。
1.禁止對位點更新的操作
優化點：
1.允許DDl和更新，直到寫binlog為止。
UNLOCK BINLOG
物理備份流程變化
修改前：
1. get redo-lsn
2. copy InnoDB data
3. FLUSH TABLES WITH READ LOCK;
4. copy .frm, MyISAM, etc.
5. get the binary log coordinates
6. finalize the background copy of REDO log
7. UNLOCK TABLES;
修改後：
1. get redo-lsn
2. copy InnoDB data
3. LOCK TABLES FOR BACKUP;
4. copy .frm, MyISAM, etc
5. LOCK BINLOG FOR BACKUP;
6. finalize the background copy of REDO log
7. UNLOCK TABLES;
8. get the binary log coordinates
9. UNLOCK BINLOG;
對應的Xtrabackup工具在執行命令流程需要相應的改動。
功能限制
1.對於Myisam表，當delay_key_write=ALL時，索引並沒有及時刷盤，導致xtrabackup無法獲取一致的備份，因此在這種情況下，加backup-lock失敗。
參考文檔
https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/
