MySQL備份鎖

     不管邏輯備份仍是物理備份，爲了獲取一致性位點，都強依賴於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/doc/percona-server/5.6/management/backup_locks.html#interaction-with-other-global-locks

https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/