Amazon Redshift クラスターがメンテナンスウィンドウ外で再起動したのはなぜですか?

最終更新日: 2020 年 8 月 19 日

Amazon Redshift クラスターがメンテナンスウィンドウ外で再起動しました。クラスターはなぜ再起動したのでしょうか?

簡単な説明

Amazon Redshift クラスターは、次の理由により、メンテナンスウィンドウ外で再起動されます。

  • Amazon Redshift クラスターの問題が検出された。
  • クラスター内の障害のあるノードが置き換えられた。

メンテナンスウィンドウ外のクラスターの再起動についての通知を受け取るには、Amazon Redshift クラスターのイベント通知を作成します。

解決方法

Amazon Redshift クラスターの問題が検出された

クラスターの再起動をトリガーする可能性のある一般的な問題は次のとおりです。

  • リーダーノードでのメモリ不足 (OOM) エラー: 新しいバージョンにアップグレードされたクラスターでクエリを実行すると、OOM 例外が発生し、クラスターの再起動が実行される可能性があります。この問題を解決するには、パッチまたは失敗したパッチをロールバックすることを検討してください。
  • 古いバージョンのドライバーに起因する OOM エラー: 古いバージョンのドライバーで作業していて、クラスターが頻繁に再起動する場合は、最新バージョンの JDBC ドライバーをダウンロードしてください。実稼働環境で使用する前に、開発環境でドライバーのバージョンをテストする必要があります。

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