程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL備份鎖,mysql備份

MySQL備份鎖,mysql備份

編輯:MySQL綜合教程

MySQL備份鎖,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/

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved