COPY 命令上的 Redshift 死鎖

Question

我正在執行一個曾經有效的簡單 COPY 命令：

echo " COPY table_name
FROM 's3://bucket/<date>/'  
iam_role 'arn:aws:iam::123:role/copy-iam'
format as json 's3://bucket/jupath.json' 
gzip ACCEPTINVCHARS ' ' TRUNCATECOLUMNS TRIMBLANKS MAXERROR 3;
" | psql

現在我得到：

INFO:  Load into table 'table_name' completed, 53465077 record(s) loaded successfully.
ERROR:  deadlock detected
DETAIL:  Process 26999 waits for AccessExclusiveLock on relation 3176337 of database 108036; blocked by process 26835.
Process 26835 waits for ShareLock on transaction 24230722; blocked by process 26999.

唯一的變化是從 dc2 實例類型移動到 ra3。 讓我補充一下，這是接觸該表的唯一命令，並且一次只有一個進程。

Answer 1

這里的關鍵細節在錯誤消息中：

進程 26999 在數據庫 108036 的關系 3176337 上等待 AccessExclusiveLock； 被進程 26835 阻塞。進程 26835 在事務 24230722 上等待 ShareLock； 被進程 26999 阻止。

我假設關系 3176337 是有問題的表 - COPY 的目標。 這應該通過運行類似的東西來確認：

select distinct(id) table_id
,trim(datname)   db_name
,trim(nspname)   schema_name
,trim(relname)   table_name
from stv_tbl_perm
join pg_class on pg_class.oid = stv_tbl_perm.id
join pg_namespace on pg_namespace.oid = relnamespace
join pg_database on pg_database.oid = stv_tbl_perm.db_id 
;

我不希望這里有任何驚喜，但最好檢查一下。 如果它是一些不同的表（對象），那么了解這一點很重要。

現在是肉。 錯誤消息中列出了 2 個進程 - PID 26999 和 PID 26835。進程是與數據庫或 session 的唯一連接。因此它們標識了與彼此鎖定的數據庫的 2 個連接。 因此，下一步最好是查看每個會話（進程或 PID）在做什么。 像這樣：

select xid, pid, starttime, max(datediff('sec',starttime,endtime)) as runtime, type, listagg(regexp_replace(text,'\\\\n*',' ')) WITHIN GROUP (ORDER BY sequence) || ';' as querytext
  from svl_statementtext
  where pid in (26999, 26835) 
  --where xid = 16627013
    and sequence < 320
    --and starttime > getdate() - interval '24 hours'
  group by starttime, 1, 2, "type" order by starttime, 1 asc, "type" desc ;

您可能會遇到的情況是，這些日志記錄表每隔幾天就會“回收”一次，因此來自這個確切故障的數據可能會丟失。

錯誤的下一部分是關於阻止 26835 繼續前進的開放事務。 此事務（由 XID 或事務 ID 標識）阻止 26835 進行，並且是進程 26999 的一部分，但 26999 需要 26835 在它移動之前完成某些操作 - 死鎖。 因此，查看此交易中的內容也會有所幫助：

select xid, pid, starttime, max(datediff('sec',starttime,endtime)) as runtime, type, listagg(regexp_replace(text,'\\\\n*',' ')) WITHIN GROUP (ORDER BY sequence) || ';' as querytext
  from svl_statementtext
  where xid = 24230722
    and sequence < 320
    --and starttime > getdate() - interval '24 hours'
  group by starttime, 1, 2, "type" order by starttime, 1 asc, "type" desc ;

同樣，數據可能由於時間而丟失。 我注釋掉了最后 2 個查詢的日期范圍 where 子句，以允許在這些表中進一步回顧。 您還應該知道 PID 和 XID 編號被重復使用，因此請檢查結果上的日期戳以確保來自不同會話的信息不會合並。 您可能需要一個新的 where 子句來專注於您關心的事件。

現在您應該擁有了解為什么會發生此死鎖所需的所有信息。 使用語句的時間戳查看每個 session（進程）發出語句的順序。 請記住，每個事務都以 COMMIT（或 ROLLBACK）結束，這將更改 session 中以下語句的 XID。一個簡單的修復可能是在“26999”流程中發出 COMMIT 以關閉該事務並讓其他進程進步。 但是，您需要了解這樣的提交是否會導致其他問題。

如果您能找到所有這些信息並且需要任何幫助，請聯系我們。

Answer 2

顯然是一個錯誤。

通過執行SHOW TABLE table_name將表從一個紅移克隆到另一個紅移，它提供：

 CREATE TABLE table_name (        
     message character varying(50) ENCODE lzo,         
     version integer ENCODE az64,                      
     id character varying(100) ENCODE lzo ,
     access character varying(25) ENCODE lzo,          
     type character varying(25) ENCODE lzo,            
     product character varying(50) ENCODE lzo,      
 )                                                     
 DISTSTYLE AUTO SORTKEY AUTO ;

刪除“噪音”后，命令照常完成，沒有錯誤：

 DROP TABLE table_name;
 CREATE TABLE table_name (        
     message character varying(50),         
     version integer,                      
     id character varying(100),
     access character varying(25),          
     type character varying(25),            
     product character varying(50),      
 );