無論邏輯備份還是物理備份,為了獲取一致性位點,都強依賴於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/