摘要:本文主要介紹在 GaussDB(DWS) 中,如何經過 SQL 語句,對分佈式死鎖進行檢測和恢復。
分佈式數倉應用場景中,咱們常常遇到數據庫系統 hang 住的問題,所謂 hang 是指雖然數據庫系統還在運行,但部分或所有業務沒法正常執行。hang 問題的緣由有不少,其中以分佈式死鎖最爲常見,本次主要分享在碰到死鎖時,如何快速地解決死鎖問題。node
GaussDB(DWS) 做爲分佈式數倉,經過鎖機制來實行併發控制,所以也存在產生分佈式死鎖的可能。雖然分佈式死鎖沒法避免,但幸運的是其提供了多種系統視圖,可以保證在分佈式死鎖發生以後,快速地對死鎖進行定位。sql
本文主要介紹了在 GaussDB(DWS) 中,如何經過 SQL 語句,對分佈式死鎖進行檢測和恢復。本文介紹的方法大體分爲 4 步:數據庫
1. 收集各節點的鎖信息。併發
2. 構建等待關係。app
3. 檢測循環等待。分佈式
4. 停止事務以消除死鎖。post
本文介紹的方法使用簡單,門檻低,能夠確保在分佈式死鎖發生以後,快速解決問題,恢復業務。fetch
經過 SQL 語句進行分佈式死鎖的檢測與消除
分佈式死鎖和單節點死鎖的比較
單節點死鎖
單節點死鎖是指,死鎖中的全部鎖等待信息來自同一個節點,例如:ui
-- 事務 transaction1 -- 所在節點:CN1 BEGIN; TRUNCATE t1; EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'; COMMIT; -- 事務 transaction2 -- 所在節點:CN1 BEGIN; TRUNCATE t2; EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'; COMMIT;
假設上述兩個事務的執行順序以下:spa
1. [transaction1] TRUNCATE t1
2. [transaction2] TRUNCATE t2
3. [transaction1] EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'
4. [transaction2] EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'
該執行順序會致使死鎖的產生。因爲事務 transaction1 和 transaction2 都在 CN1 上執行,死鎖中的全部鎖等待信息都在 CN1 上,所以該死鎖爲單節點死鎖。
GaussDB(DWS) 支持自動處理單節點死鎖。當某個節點上的多個事務陷入循環等待時,數據庫系統會自動將其中一個事務停止,從而消除死鎖。
分佈式死鎖
分佈式死鎖是指,死鎖中的鎖等待信息來自不一樣節點。例如:
-- 事務 transaction1 -- 所在節點:CN1 BEGIN; TRUNCATE t1; EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'; COMMIT; -- 事務 transaction2 -- 所在節點:CN2 BEGIN; TRUNCATE t2; EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'; COMMIT;
本例與上一節中的例子相比,只有事務 transaction2 的所在節點從 CN1 改成了 CN2。
假設兩個事務的執行順序和上一節中的執行順序一致,仍是會產生死鎖,死鎖中的鎖等待信息以下:
這就是一個典型的分佈式死鎖,單獨看 CN1 或 CN2 上的鎖等待信息,都看不出來有死鎖,但將多個節點的鎖等待信息放到一塊兒看,就能找到有循環等待的現象。
發生分佈式死鎖時,陷入死鎖的事務所有都沒法繼續執行下去,只有其中一個事務鎖等待超時,剩餘事務才能繼續執行。默認狀況下,鎖等待超時時間是 20 分鐘。
分佈式死鎖的檢測與消除
當咱們觀察到數據庫系統出現 hang 問題時,咱們須要經過 SQL 語句檢測分佈式死鎖,若是發現確實存在分佈式死鎖,還須要對死鎖進行消除。接下來以以前的分佈式死鎖爲例,介紹分佈式死鎖的檢測和消除的方法。
收集各節點的鎖信息
爲了檢測分佈式死鎖,首先須要得到各節點的鎖信息。GaussDB(DWS) 中能夠經過 PG_LOCKS 視圖查詢當前節點的鎖信息,所以能夠經過 EXECUTE DIRECT 語句在全部節點查詢 PG_LOCKS 視圖,並收集到當前節點中。
注意此處有一個細節,PG_LOCKS 視圖中,不少信息是以 OID 類型給出的,例如一個鎖加在一個表上,PG_LOCKS 視圖會給出表的 OID。因爲同一個表在各節點中的 OID 不必定相同,所以不能經過 OID 來標識一個表。在收集鎖信息時,須要先將表的 OID 轉換成 SCHEMA 名加表名。其它 OID 信息例如分區 OID 等也同理,須要轉化爲對應的名字。
執行附件中的示例代碼 pgxc_locks.sql,就能夠收集到各節點的鎖信息:
locktype | nodename | datname | usename | nspname | relname | partname | page | tuple | virtualxid | transactionid | virtualtransaction | mode | granted | client_addr | application_name | pid | xact_start | query_start | state | query_id | query ---------------+--------------+----------+---------+---------+---------+----------+------+-------+------------+---------------+--------------------+---------------------+---------+-------------+------------------+-----------------+----------------------------+----------------------------+---------------------+-------------------+----------------------------------------------------- virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 12/94 | | 12/94 | ExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1'; virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 9/298 | | 9/298 | ExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1; virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 6/161 | | 6/161 | ExclusiveLock | t | | WLMArbiter | 140110762325760 | 2020-12-25 17:20:18.613815 | 2020-12-25 16:53:35.027585 | active | 0 | WLM arbiter sync info by CCN and CNs virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 5/162 | | 5/162 | ExclusiveLock | t | | WorkloadMonitor | 140110779119360 | 2020-12-25 17:20:27.16458 | 2020-12-25 16:53:35.027217 | active | 0 | WLM monitor update and verify local info virtualxid | cn_5002 | postgres | tyx_1 | | | | | | 3/325 | | 3/325 | ExclusiveLock | t | | workload | 140110846744320 | 2020-12-25 17:20:25.372654 | 2020-12-25 16:53:35.02741 | active | 72339069014641297 | WLM fetch collect info from data nodes advisory | cn_5002 | postgres | tyx_1 | | | | | | | | 12/94 | ShareLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1'; relation | cn_5002 | postgres | tyx_1 | public | t1 | | | | | | 9/298 | AccessExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1; relation | cn_5002 | postgres | tyx_1 | public | t1 | | | | | | 12/94 | AccessShareLock | f | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1'; transactionid | cn_5002 | postgres | tyx_1 | | | | | | | 10269 | 12/94 | ExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1'; transactionid | cn_5002 | postgres | tyx_1 | | | | | | | 10266 | 9/298 | ExclusiveLock | t | ::1/128 | cn_5001 | 140110672164608 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:40.479682 | idle in transaction | 0 | TRUNCATE t1; relation | cn_5002 | postgres | tyx_1 | public | t2 | | | | | | 12/94 | AccessExclusiveLock | t | | gsql | 140110481323776 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:19:37.715447 | active | 0 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1'; virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 17/433 | | 17/433 | ExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1; virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 23/692 | | 23/692 | ExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2; virtualxid | dn_6001_6002 | postgres | tyx_1 | | | | | | 2/1607 | | 2/1607 | ExclusiveLock | t | | workload | 140552945264384 | | 2020-12-25 16:53:35.041283 | active | 0 | WLM fetch collect info from data nodes transactionid | dn_6001_6002 | postgres | tyx_1 | | | | | | | 10266 | 17/433 | ExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1; relation | dn_6001_6002 | postgres | tyx_1 | | | | | | | | 23/692 | AccessExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2; relation | dn_6001_6002 | postgres | tyx_1 | | | | | | | | 17/433 | AccessExclusiveLock | t | ::1/128 | cn_5001 | 140552375822080 | 2020-12-25 17:18:40.478704 | 2020-12-25 17:18:50.513948 | idle in transaction | 0 | TRUNCATE t1; relation | dn_6001_6002 | postgres | tyx_1 | public | t2 | | | | | | 23/692 | ShareLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2; relation | dn_6001_6002 | postgres | tyx_1 | public | t2 | | | | | | 23/692 | AccessExclusiveLock | t | ::1/128 | cn_5002 | 140552359040768 | 2020-12-25 17:18:54.238933 | 2020-12-25 17:18:56.830053 | idle in transaction | 0 | TRUNCATE t2; 省略若干行 (55 rows)
構建等待關係
收集到各節點的鎖信息以後,就能夠開始構建等待關係了。
事務 A 等待事務 B,須要知足 3 個條件:
1. 兩個事務加鎖的資源相同(同一個表、同一個分區、同一個頁面或同一個元組等)。特別注意,若是事務 A 對 DN1 的 t1 表的加鎖,事務 B 對 DN2 的 t1 表的加鎖,則咱們認爲它們加鎖的資源不一樣,只有同一節點上的同一資源才被認爲是相同的資源。
2. 事務 B 已經持有鎖,而事務 A 還未持有鎖。
3. 事務 A 和事務 B 申請的鎖的級別互斥。
經過對上一步收集到的鎖信息進行處理,就能夠構建出事務的等待關係。
執行附件中的示例代碼 pgxc_locks_wait.sql,就能夠得到等待關係:
locktype | nodename | datname | acquire_lock_pid | hold_lock_pid | acquire_lock_event | hold_lock_event ----------+----------+----------+------------------+-----------------+-------------------------------------------------------------------------+-------------------------------------------------------- relation | cn_5001 | postgres | 140508814374656 | 140508792350464 | usename : tyx_1 +| usename : tyx_1 + | | | | | nspname : public +| nspname : public + | | | | | relname : t2 +| relname : t2 + | | | | | partname : +| partname : + | | | | | page : +| page : + | | | | | tuple : +| tuple : + | | | | | virtualxid : +| virtualxid : + | | | | | transactionid : +| transactionid : + | | | | | virtualtransaction: 11/13 +| virtualtransaction: 12/1323 + | | | | | mode : AccessShareLock +| mode : AccessExclusiveLock + | | | | | client_addr : +| client_addr : ::1/128 + | | | | | application_name : gsql +| application_name : cn_5002 + | | | | | xact_start : 2020-12-25 17:18:40.478704 +| xact_start : 2020-12-25 17:18:54.238933 + | | | | | query_start : 2020-12-25 17:19:23.0923 +| query_start : 2020-12-25 17:18:54.239319 + | | | | | state : active +| state : idle in transaction + | | | | | query_id : 0 +| query_id : 0 + | | | | | query : EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t2';+| query : TRUNCATE t2; + | | | | | ------------------------------------------------------ | ------------------------------------------------------ relation | cn_5002 | postgres | 140110481323776 | 140110672164608 | usename : tyx_1 +| usename : tyx_1 + | | | | | nspname : public +| nspname : public + | | | | | relname : t1 +| relname : t1 + | | | | | partname : +| partname : + | | | | | page : +| page : + | | | | | tuple : +| tuple : + | | | | | virtualxid : +| virtualxid : + | | | | | transactionid : +| transactionid : + | | | | | virtualtransaction: 12/94 +| virtualtransaction: 9/298 + | | | | | mode : AccessShareLock +| mode : AccessExclusiveLock + | | | | | client_addr : +| client_addr : ::1/128 + | | | | | application_name : gsql +| application_name : cn_5001 + | | | | | xact_start : 2020-12-25 17:18:54.238933 +| xact_start : 2020-12-25 17:18:40.478704 + | | | | | query_start : 2020-12-25 17:19:37.715447 +| query_start : 2020-12-25 17:18:40.479682 + | | | | | state : active +| state : idle in transaction + | | | | | query_id : 0 +| query_id : 0 + | | | | | query : EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t1';+| query : TRUNCATE t1; + | | | | | ------------------------------------------------------ | ------------------------------------------------------ (2 rows)
等待關係判環
構建出事務的等待關係以後,就能夠經過檢查等待關係是否成環,來判斷當前是否有分佈式死鎖。
通常狀況下,等待關係不會太多,經過觀察就能夠判斷出當前有無分佈式死鎖。經過觀察上一節中構建的等待信息,能夠很容易地判斷出事務 transaction1 和 transaction2 發生了循環等待,即產生了死鎖。
消除死鎖
上一步最終可能會找到等待關係中的一個或多個環,對於每一個環,須要停止環中的一個事務,才能消除死鎖。至於應該選擇環中的哪一個事務進行停止,須要咱們從事務的重要性、已執行時間等多方面進行考慮,最終選擇一個對業務影響最小的事務進行停止。
總結
經過 SQL 語句,咱們能夠很方便地處理分佈式死鎖。當咱們在實際業務中遇到數據庫系統 hang 住的問題時,能夠藉助本文提供的方法,檢查 hang 問題是不是分佈式死鎖引發的,若是問題確實是由分佈式死鎖引發的,還能夠經過停止某個陷入死鎖的事務,來快速恢復業務。
附件下載: lock.zip 2.29KB
本文分享自華爲雲社區《如何經過SQL進行分佈式死鎖的檢測與消除》,原文做者:tyxxjtu。