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 イベント通知を作成し、クラスターの再起動をサブスクライブします。イベント通知では、ソースが設定されているかどうかも通知されます。