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"來擷取一致性位點，盡量減少因為Database 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/

MySQL備份鎖