目錄
- 概述
- 分布式死鎖和單節(jié)點死鎖的比較單節(jié)點死鎖
- 分布式死鎖的檢測與消除
- 收集各節(jié)點的鎖信息
- 構(gòu)建等待關(guān)系
- 等待關(guān)系判環(huán)
- 消除死鎖
- 總結(jié)
概述
分布式數(shù)倉應(yīng)用場景中，我們經(jīng)常遇到數(shù)據(jù)庫系統(tǒng) hang 住的問題，所謂 hang 是指雖然數(shù)據(jù)庫系統(tǒng)還在運行，但部分或全部業(yè)務(wù)無法正常執(zhí)行。hang 問題的原因有很多，其中以分布式死鎖最為常見，本次主要分享在碰到死鎖時，如何快速地解決死鎖問題。
GaussDB(DWS) 作為分布式數(shù)倉，通過鎖機制來實行并發(fā)控制，因此也存在產(chǎn)生分布式死鎖的可能。雖然分布式死鎖無法避免，但幸運的是其提供了多種系統(tǒng)視圖，能夠保證在分布式死鎖發(fā)生之后，快速地對死鎖進行定位。
本文主要介紹了在 GaussDB(DWS) 中，如何通過 SQL 語句，對分布式死鎖進行檢測和恢復(fù)。本文介紹的方法大致分為 4 步：
1. 收集各節(jié)點的鎖信息。
2. 構(gòu)建等待關(guān)系。
3. 檢測循環(huán)等待。
4. 中止事務(wù)以消除死鎖。
本文介紹的方法使用簡單，門檻低，可以確保在分布式死鎖發(fā)生之后，快速解決問題，恢復(fù)業(yè)務(wù)。
分布式死鎖和單節(jié)點死鎖的比較單節(jié)點死鎖
單節(jié)點死鎖是指，死鎖中的所有鎖等待信息來自同一個節(jié)點，例如：
-- 事務(wù) transaction1
-- 所在節(jié)點：CN1
BEGIN;
TRUNCATE t1;
EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2';
COMMIT;
-- 事務(wù) transaction2
-- 所在節(jié)點：CN1
BEGIN;
TRUNCATE t2;
EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1';
COMMIT;
假設(shè)上述兩個事務(wù)的執(zhí)行順序如下：
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'
該執(zhí)行順序會導(dǎo)致死鎖的產(chǎn)生。由于事務(wù) transaction1 和 transaction2 都在 CN1 上執(zhí)行，死鎖中的所有鎖等待信息都在 CN1 上，因此該死鎖為單節(jié)點死鎖。
GaussDB(DWS) 支持自動處理單節(jié)點死鎖。當(dāng)某個節(jié)點上的多個事務(wù)陷入循環(huán)等待時，數(shù)據(jù)庫系統(tǒng)會自動將其中一個事務(wù)中止，從而消除死鎖。
分布式死鎖
分布式死鎖是指，死鎖中的鎖等待信息來自不同節(jié)點。例如：
-- 事務(wù) transaction1
-- 所在節(jié)點：CN1
BEGIN;
TRUNCATE t1;
EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2';
COMMIT;
-- 事務(wù) transaction2
-- 所在節(jié)點：CN2
BEGIN;
TRUNCATE t2;
EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1';
COMMIT;
本例與上一節(jié)中的例子相比，只有事務(wù) transaction2 的所在節(jié)點從 CN1 改為了 CN2。
假設(shè)兩個事務(wù)的執(zhí)行順序和上一節(jié)中的執(zhí)行順序一致，還是會產(chǎn)生死鎖，死鎖中的鎖等待信息如下：
這就是一個典型的分布式死鎖，單獨看 CN1 或 CN2 上的鎖等待信息，都看不出來有死鎖，但將多個節(jié)點的鎖等待信息放到一起看，就能找到有循環(huán)等待的現(xiàn)象。
發(fā)生分布式死鎖時，陷入死鎖的事務(wù)全部都無法繼續(xù)執(zhí)行下去，只有其中一個事務(wù)鎖等待超時，剩余事務(wù)才能繼續(xù)執(zhí)行。默認(rèn)情況下，鎖等待超時時間是 20 分鐘。
分布式死鎖的檢測與消除
當(dāng)我們觀察到數(shù)據(jù)庫系統(tǒng)出現(xiàn) hang 問題時，我們需要通過 SQL 語句檢測分布式死鎖，如果發(fā)現(xiàn)確實存在分布式死鎖，還需要對死鎖進行消除。接下來以之前的分布式死鎖為例，介紹分布式死鎖的檢測和消除的方法。
收集各節(jié)點的鎖信息
為了檢測分布式死鎖，首先需要獲得各節(jié)點的鎖信息。GaussDB(DWS) 中可以通過 PG_LOCKS 視圖查詢當(dāng)前節(jié)點的鎖信息，因此可以通過 EXECUTE DIRECT 語句在所有節(jié)點查詢 PG_LOCKS 視圖，并收集到當(dāng)前節(jié)點中。
注意此處有一個細節(jié)，PG_LOCKS 視圖中，很多信息是以 OID 類型給出的，例如一個鎖加在一個表上，PG_LOCKS 視圖會給出表的 OID。由于同一個表在各節(jié)點中的 OID 不一定相同，因此不能通過 OID 來標(biāo)識一個表。在收集鎖信息時，需要先將表的 OID 轉(zhuǎn)換成 SCHEMA 名加表名。其它 OID 信息例如分區(qū) OID 等也同理，需要轉(zhuǎn)化為對應(yīng)的名字。
執(zhí)行附件中的示例代碼 pgxc_locks.sql，就可以收集到各節(jié)點的鎖信息：
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)
構(gòu)建等待關(guān)系
收集到各節(jié)點的鎖信息之后，就可以開始構(gòu)建等待關(guān)系了。
事務(wù) A 等待事務(wù) B，需要滿足 3 個條件：
1. 兩個事務(wù)加鎖的資源相同（同一個表、同一個分區(qū)、同一個頁面或同一個元組等）。特別注意，如果事務(wù) A 對 DN1 的 t1 表的加鎖，事務(wù) B 對 DN2 的 t1 表的加鎖，則我們認(rèn)為它們加鎖的資源不同，只有同一節(jié)點上的同一資源才被認(rèn)為是相同的資源。
2. 事務(wù) B 已經(jīng)持有鎖，而事務(wù) A 還未持有鎖。
3. 事務(wù) A 和事務(wù) B 申請的鎖的級別互斥。
通過對上一步收集到的鎖信息進行處理，就可以構(gòu)建出事務(wù)的等待關(guān)系。
執(zhí)行附件中的示例代碼 pgxc_locks_wait.sql，就可以獲得等待關(guān)系：
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)
等待關(guān)系判環(huán)
構(gòu)建出事務(wù)的等待關(guān)系之后，就可以通過檢查等待關(guān)系是否成環(huán)，來判斷當(dāng)前是否有分布式死鎖。
一般情況下，等待關(guān)系不會太多，通過觀察就可以判斷出當(dāng)前有無分布式死鎖。通過觀察上一節(jié)中構(gòu)建的等待信息，可以很容易地判斷出事務(wù) transaction1 和 transaction2 發(fā)生了循環(huán)等待，即產(chǎn)生了死鎖。
消除死鎖
上一步最終可能會找到等待關(guān)系中的一個或多個環(huán)，對于每個環(huán)，需要中止環(huán)中的一個事務(wù)，才能消除死鎖。至于應(yīng)該選擇環(huán)中的哪個事務(wù)進行中止，需要我們從事務(wù)的重要性、已執(zhí)行時間等多方面進行考慮，最終選擇一個對業(yè)務(wù)影響最小的事務(wù)進行中止。
總結(jié)
通過 SQL 語句，我們可以很方便地處理分布式死鎖。當(dāng)我們在實際業(yè)務(wù)中遇到數(shù)據(jù)庫系統(tǒng) hang 住的問題時，可以借助本文提供的方法，檢查 hang 問題是否是分布式死鎖引起的，如果問題確實是由分布式死鎖引起的，還可以通過中止某個陷入死鎖的事務(wù)，來快速恢復(fù)業(yè)務(wù)。
以上就是詳解通過SQL進行分布式死鎖的檢測與消除的詳細內(nèi)容，更多關(guān)于通過SQL進行分布式死鎖的檢測與消除的資料請關(guān)注腳本之家其它相關(guān)文章！
您可能感興趣的文章:- java排查死鎖示例
- Java檢測死鎖案例
- 如何解決Java多線程死鎖問題
- MySQL鎖等待與死鎖問題分析
- postgresql表死鎖問題的排查方式
- 死鎖詳解
