Amazon Redshift クラスターがメンテナンス期間外に再起動した原因を教えてください。

簡単な説明

次の原因で、Amazon Redshift クラスターはメンテナンス期間外に再起動します。

• Amazon Redshift がクラスターに問題を検出した。
• Amazon Redshift がクラスター内の障害があるノードを交換した。

メンテナンス期間外に発生するクラスターの再起動について通知を受けるには、イベント通知サブスクリプションを作成します。イベント通知では、そのクラスターをソースタイプとして指定したときにも通知されます。詳細については、「Amazon Redshift クラスターのイベント通知サブスクリプション」を参照してください。

解決策

Amazon Redshift がクラスターの問題を検出した

次の問題が原因で、クラスターが再起動する可能性があります。

リーダーノードでの OOM エラー

新しいバージョンにアップグレードしたクラスターでクエリを実行すると、メモリ不足 (OOM) 例外が発生する可能性があります。この問題を解決するには、パッチまたは障害が発生したパッチをロールバックします。

過去のドライババージョンに起因する OOM エラー

過去のドライバーバージョンを使用していて、クラスターが頻繁に再起動する場合は、最新の Java Database Connectivity (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 インスタンスが応答しない。
• ノード上のディスクに問題がある。
• 断続的に発生するネットワーク通信障害、または基盤ホストの問題により、ノード間の通信障害が発生する可能性があります。
• ノードまたはクラスターの検出のタイムアウト。
• ノードが過負荷になると、メモリ不足の問題が発生します。