傳統 FLUSH TABLES WITH READ LOCK (FTWRL) 為獲取一致性位點而鎖定全庫,導致寫入完全阻塞、大查詢引發連鎖阻塞、主備延遲飆升。Percona 引入 Backup Lock(LOCK TABLES FOR BACKUP、LOCK BINLOG FOR BACKUP),在 Server 層實現細粒度鎖控制,大幅降低備份對業務影響。本文深度解析其架構設計、鎖相容性矩陣、物理備份流程重構、工具鏈適配與限制場景。
| 鎖類型 | 語法 | 釋放語法 | 保護目標 | 業務影響 |
|---|---|---|---|---|
| Backup Lock | LOCK TABLES FOR BACKUP | UNLOCK TABLES | 非 InnoDB 表寫入、所有表 DDL | InnoDB 讀寫完全不受影響 |
| Binlog Lock | LOCK BINLOG FOR BACKUP | UNLOCK BINLOG | Binlog 位點推進(寫入 Binlog 瞬間) | 允許 DML/DDL 執行,僅阻塞寫 Binlog 瞬間 |
show processlist 顯示 Waiting for backup lockWaiting for binlog lock// 申請 Backup Lock 共享鎖 acquire_lock(backup_lock, MDL_SHARED, MDL_EXPLICIT);
// 1. 若已持有全局 Backup Lock → 直接報錯 // 2. 申請 Schema 排他鎖 acquire_lock(schema, MDL_EXCLUSIVE, MDL_TRANSACTION); // 3. 申請 IX 意向排他鎖,阻塞後續 Backup/Global Lock acquire_lock(global, MDL_INTENTION_EXCLUSIVE, MDL_STATEMENT); acquire_lock(backup, MDL_INTENTION_EXCLUSIVE, MDL_STATEMENT);
// 1. 申請 Table 排他鎖 acquire_lock(table, MDL_EXCLUSIVE, MDL_TRANSACTION); // 2. 申請 Schema IX 鎖 acquire_lock(schema, MDL_INTENTION_EXCLUSIVE, MDL_TRANSACTION); // 3. 檢測全局 Backup Lock → 報錯 // 4. 申請 Global/Backup IX 鎖
// open_table 階段
if (mdl_request.type >= MDL_SHARED_WRITE &&
engine->flags & HTON_SUPPORTS_ONLINE_BACKUPS) {
// InnoDB 等支援線上備份引擎:跳過 Backup Lock 申請
} else {
// MyISAM/MEMORY/CSV 等:申請 Backup Lock IX 鎖
acquire_lock(backup, MDL_INTENTION_EXCLUSIVE, MDL_STATEMENT);
}
| 階段 | 傳統 FTWRL 流程 | Backup Lock 新流程 |
|---|---|---|
| 1 | 獲取 Redo LSN | 獲取 Redo LSN |
| 2 | 複製 InnoDB 數據文件 | 複製 InnoDB 數據文件 |
| 3 | FLUSH TABLES WITH READ LOCK | LOCK TABLES FOR BACKUP |
| 4 | 複製 .frm、MyISAM、系統表 | 複製 .frm、MyISAM、系統表 |
| 5 | 獲取 Binlog 座標 | LOCK BINLOG FOR BACKUP |
| 6 | 完成 Redo Log 尾部複製 | 完成 Redo Log 尾部複製 |
| 7 | UNLOCK TABLES | UNLOCK TABLES |
| 8 | - | 獲取 Binlog 座標 |
| 9 | - | UNLOCK BINLOG |
關鍵優勢:
flush tables 關表操作,不被大查詢阻塞