本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Aurora PostgreSQL 無限資料庫中的分散式死鎖
在資料庫碎片群組中,在不同路由器和碎片之間分佈的交易之間可能會發生死鎖。例如,會執行跨越兩個碎片的兩個並行分散式交易,如下圖所示。

交易會鎖定資料表,並在兩個碎片中建立等待事件,如下所示:
-
分散式交易 1:
UPDATE
table
SETvalue
= 1 WHERE key = 'shard1_key
';這會在碎片 1 上保留鎖定。
-
分散式交易 2:
UPDATE
table
SETvalue
= 2 WHERE key = 'shard2_key
';這會在碎片 2 上保留鎖定。
-
分散式交易 1:
UPDATE
table
SETvalue
= 3 WHERE key = 'shard2_key
';分散式交易 1 正在等待碎片 2。
-
分散式交易 2:
UPDATE
table
SETvalue
= 4 WHERE key = 'shard1_key
';分散式交易 2 正在等待碎片 1。
在此案例中,碎片 1 和碎片 2 都不會看到問題:交易 1 正在等待交易 2 在碎片 2 上,交易 2 正在等待交易 1 在碎片 1 上。從全域檢視,交易 1 正在等待交易 2,交易 2 正在等待交易 1。在這種情況下,兩個不同碎片上的兩個交易彼此等待,稱為分散式死鎖。
Aurora PostgreSQL 無限資料庫可以自動偵測和解析分散式死鎖。資料庫碎片群組中的路由器會在交易等待時間太長而無法取得資源時收到通知。接收通知的路由器開始從資料庫碎片群組中的所有路由器和碎片收集必要的資訊。路由器接著會繼續進行參與分散式死鎖的結束交易,直到資料庫碎片群組中的其餘交易可以繼續進行,而不會被彼此封鎖。
當您的交易是分散式死鎖的一部分,然後由路由器結束時,您會收到下列錯誤:
ERROR: aborting transaction participating in a distributed deadlock
rds_aurora.limitless_distributed_deadlock_timeout
資料庫叢集參數會設定每個交易在通知路由器檢查分散式死鎖之前等待資源的時間。如果您的工作負載較不容易發生死結情況,您可以增加參數值。預設值為1000
毫秒 (1 秒)。
找到並解決跨節點死鎖時,分散式死鎖週期會發佈至 PostgreSQL 日誌。鎖死中每個程序的相關資訊包括下列項目:
-
啟動交易的協調器節點
-
協調器節點上交易的虛擬交易 ID (xid),格式為
backend_id
/backend_local_xid
-
交易的分散式工作階段 ID