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

2 分的閱讀內容

我的 Amazon Redshift 叢集在維護時間以外重新啟動。為什麼叢集會重新啟動？

簡短說明

由於以下原因，Amazon Redshift 叢集會在維護時間以外重新啟動：

偵測到 Amazon Redshift 叢集存在問題。
已取代叢集中的故障節點。

若要收到有關在維護時間以外的任何叢集重新啟動的通知，請為 Amazon Redshift 叢集建立事件通知。

解決方法

偵測到 Amazon Redshift 叢集有問題

以下是一些可能觸發叢集重新啟動的常見問題：

**引導節點上出現記憶體不足 (OOM) 錯誤：**在升級至較新版本的叢集上執行的查詢可能會導致 OOM 例外狀況，進而開始叢集重新啟動。若要解決此問題，請考量復原修補程式或故障的修補程式。
**由較舊的驅動程式版本導致的 OOM 錯誤：**如果您使用的是較舊的驅動程式版本，並且叢集經常重新啟動，請下載最新的 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 偵測到任何硬體問題或失敗時，將在以下維護時間中自動取代這些節點。請注意，在某些情況下，必須立即取代故障節點，才能確保叢集正常執行。

以下是叢集節點故障的一些常見原因：

**EC2 執行個體失敗：**發現 EC2 執行個體的基礎硬體出現故障時，就會取代故障節點以還原叢集效能。如果缺少回應或未能通過任何自動化運作狀態檢查，EC2 即會將基礎硬體標記為故障。
**由於節點磁碟機故障而導致的節點替換：**偵測到節點上的磁碟存在問題時，Amazon Redshift 會取代磁碟或重新啟動節點。如果 Amazon Redshift 叢集無法復原，則會取代或排定取代節點。
**節點間通訊失敗：**如果節點之間有通訊失敗，特定節點就不會在指定時間收到控制訊息。節點間通訊失敗是由間歇性網路連線問題或基礎主機問題所引起。
**探索逾時：**如果在指定時間內無法到達某個節點或叢集，則會觸發自動節點替換。
**記憶體不足 (OOM) 例外狀況：**微粒節點上的繁重負載可能會導致 OOM 問題，從而觸發節點替換。

建立 Amazon Redshift 事件通知

若要識別叢集重新啟動的原因，請建立 Amazon Redshift 事件通知，並訂閱任何叢集重新啟動。事件通知還會通知您是否已設定來源。