僅4步,就可通過SQL進行分散式死鎖的檢測與消除

華為雲開發者社群發表於2020-12-31
摘要:本文主要介紹在 GaussDB(DWS) 中,如何通過 SQL 語句,對分散式死鎖進行檢測和恢復。

分散式數倉應用場景中,我們經常遇到資料庫系統 hang 住的問題,所謂 hang 是指雖然資料庫系統還在執行,但部分或全部業務無法正常執行。hang 問題的原因有很多,其中以分散式死鎖最為常見,本次主要分享在碰到死鎖時,如何快速地解決死鎖問題。

GaussDB(DWS) 作為分散式數倉,通過鎖機制來實行併發控制,因此也存在產生分散式死鎖的可能。雖然分散式死鎖無法避免,但幸運的是其提供了多種系統檢視,能夠保證在分散式死鎖發生之後,快速地對死鎖進行定位。

本文主要介紹了在 GaussDB(DWS) 中,如何通過 SQL 語句,對分散式死鎖進行檢測和恢復。本文介紹的方法大致分為 4 步:

1. 收集各節點的鎖資訊。

2. 構建等待關係。

3. 檢測迴圈等待。

4. 中止事務以消除死鎖。

本文介紹的方法使用簡單,門檻低,可以確保在分散式死鎖發生之後,快速解決問題,恢復業務。

通過 SQL 語句進行分散式死鎖的檢測與消除

分散式死鎖和單節點死鎖的比較

單節點死鎖

單節點死鎖是指,死鎖中的所有鎖等待資訊來自同一個節點,例如:

-- 事務 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;

假設上述兩個事務的執行順序如下:

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 上,因此該死鎖為單節點死鎖。

僅4步,就可通過SQL進行分散式死鎖的檢測與消除

GaussDB(DWS) 支援自動處理單節點死鎖。當某個節點上的多個事務陷入迴圈等待時,資料庫系統會自動將其中一個事務中止,從而消除死鎖。

僅4步,就可通過SQL進行分散式死鎖的檢測與消除

分散式死鎖

分散式死鎖是指,死鎖中的鎖等待資訊來自不同節點。例如:

-- 事務 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。

假設兩個事務的執行順序和上一節中的執行順序一致,還是會產生死鎖,死鎖中的鎖等待資訊如下:

僅4步,就可通過SQL進行分散式死鎖的檢測與消除

這就是一個典型的分散式死鎖,單獨看 CN1 或 CN2 上的鎖等待資訊,都看不出來有死鎖,但將多個節點的鎖等待資訊放到一起看,就能找到有迴圈等待的現象。

發生分散式死鎖時,陷入死鎖的事務全部都無法繼續執行下去,只有其中一個事務鎖等待超時,剩餘事務才能繼續執行。預設情況下,鎖等待超時時間是 20 分鐘。

僅4步,就可通過SQL進行分散式死鎖的檢測與消除

分散式死鎖的檢測與消除

當我們觀察到資料庫系統出現 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。

 

點選關注,第一時間瞭解華為雲新鮮技術~

相關文章