為什麼 Amazon Redshift 叢集會在維護時段以外重新啟動？

簡短描述

Amazon Redshift 叢集在維護時段以外重新啟動的原因如下：

• Amazon Redshift 偵測到您的叢集存在問題。
• Amazon Redshift 替換了叢集中的失敗節點。

若要收到維護時段以外發生的叢集重新啟動通知，請建立事件通知訂閱。當您指定叢集作為來源類型時，事件通知也可以通知您。如需詳細資訊，請參閱 Amazon Redshift 叢集事件通知訂閱。

解決方案

Amazon Redshift 偵測到您的叢集存在問題

以下問題可能會導致叢集重新啟動。

引導節點出現 OOM 錯誤

在升級到更新版本的叢集上執行的查詢可能會導致記憶體不足 (OOM) 例外狀況。若要解決此問題，請復原您的修補程式或失敗的修補程式。

由較舊驅動程式版本導致的 OOM 錯誤

如果您使用的是較舊的驅動程式版本，且叢集經常重新啟動，請下載最新的 Java 資料庫連線 (JDBC) 驅動程式版本。最佳做法是在聲閃環境中使用驅動程式版本之前，先在開發環境中測試驅動程式版本。

運作狀態檢查查詢失敗

Amazon Redshift 會持續監控其元件的可用性。當運作狀況檢查失敗時，Amazon Redshift 會進行重新啟動，以盡快使叢集恢復運作狀態良好，從而縮短停機時間。

大多數運作狀態檢查失敗發生在叢集具有長時間執行的未結交易時。當 Amazon Redshift 清理與長時間執行交易相關的記憶體時，叢集可能會鎖定。為了防止此問題，最佳做法是監控未關閉的連線和交易。

若要監控長時間執行的開啟連線，請執行下列範例查詢：

select s.process as process_id,
       c.remotehost || ':' || c.remoteport as remote_address,
       s.user_name as username,
       s.db_name,
       s.starttime as session_start_time,
       i.starttime as start_query_time,
       datediff(s,i.starttime,getdate())%86400/3600||' hrs '||
datediff(s,i.starttime,getdate())%3600/60||' mins ' ||
datediff(s,i.starttime,getdate())%60||' secs 'as running_query_time,
       i.text as query
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
          on c.pid = s.process
          and c.event = 'authenticated'
left join stv_inflight i
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

若要監控長時間執行的未結交易，請執行下列範例查詢：

select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' from svv_transactions
where lockable_object_type='transactionid' and pid<>pg_backend_pid() order by 3;

然後，執行以下查詢以查看未結帳交易：

select * from svl_statementtext where xid = <xid> order by starttime, sequence)

若要終止閒置工作階段並釋放連線，請使用 PG_TERMINATE_BACKEND 命令。

Amazon Redshift 取代了叢集中的失敗節點

每個 Amazon Redshift 節點都在個別的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上執行。失敗節點是指在監控過程中無法回應活動訊號的執行個體。活動訊號會定期監控 Amazon Redshift 叢集中運算節點的可用性。

當 Amazon Redshift 偵測到硬體問題或失敗時，它會在下一個維護時段自動取代節點。但是，有時 Amazon Redshift 會立即取代失敗節點，以使叢集可以繼續正常運作。

以下問題可能會導致 Amazon Redshift 取代叢集節點：

• EC2 執行個體沒有回應，因為執行個體的硬體存在根本問題，或自動運作狀態檢查失敗。
• 節點上的磁碟存在問題。
• 間歇性網路通訊失敗或基礎主機問題可能會導致節點之間的通訊失敗。
• 節點或叢集的探索逾時。
• 超載的節點會導致 OOM 問題。