Amazon Redshift クラスターの従来のサイズ変更にとても時間がかかるのはなぜですか?

最終更新日: 2020 年 11 月 17 日

クラシックサイズ変更を開始しましたが、Amazon Redshift クラスターで処理が進んでいないように見えるか、時間がかかりすぎています。従来のサイズ変更を完了するためのダウンタイムをより正確に予測する方法を教えてください。

解決方法

Amazon Redshift クラスターが従来のサイズ変更を完了するのに必要な時間はまちまちです (数時間から数日かかります)。クラスターの従来のサイズ変更に時間がかかる原因に、以下が挙げられます。

  • ソースクラスターの読み取りワークロード
  • 転送対象のテーブルの数とサイズ
  • テーブル定義とそのスキュー
  • ソースクラスターとターゲットクラスターで使用されるノード設定 (ノードの数とタイプ)

詳細については、Amazon Redshift でのクラスターのサイズ変更クラスターのサイズ変更の詳細を参照してください。

従来のサイズ変更のダウンタイムを短縮する

従来のサイズ変更に必要な時間を短縮するには、次のアプローチを検討してください。

  • Amazon Redshift コンソールを使用して、サイズ変更操作のステータスをモニタリングします。クラスターの詳細ページで [ステータス] タブを選択します。[ステータス] タブには、平均転送速度、経過時間、および残り時間が表示されます。
  • 偏ったテーブルを修正し、適切な分散キーを選択します。詳細については、Amazon Redshift エンジニアリングの高度なテーブル設計プレイブック: 分散スタイルと分散キーを参照してください。
  • 未使用のテーブルを削除します。未使用のテーブルを特定するには、GitHub ウェブサイトで unscanned table summary.sql スクリプトを実行します。
    注: スキャンされていないテーブルの概要には、過去数日間の最近の履歴のみが表示されます。長期間にわたる使用状況データをキャプチャするには、GitHub ウェブサイトの SystemTablePersistence ユーティリティを使用します。
  • 伸縮自在なサイズ変更を使用します。伸縮自在なサイズ変更は、既存の Amazon Redshift クラスター上のノードを追加または削除し、データを新しいノードに自動的に再分散します。伸縮自在なサイズ変更では新しいクラスターが作成されないため、ダウンタイムは従来のサイズ変更のダウンタイムよりも大幅に短縮されます。伸縮自在なサイズ変更の詳細については、クラスターのサイズ変更を参照してください。

サイズ変更のパフォーマンスを最適化する方法の詳細については、Amazon Redshift のパフォーマンスチューニング手法のトップ 10 を参照してください。

従来のサイズ変更のトラブルシューティング

  • AWS コマンドラインインターフェイス (AWS CLI) でクラスターのステータスが「NONE」の場合、ターゲットクラスターはまだプロビジョニングされています。ターゲットクラスターがプロビジョニングされるまで待ちます。コピーが完了すると、ステータスは「IN_PROGRESS」に変わります。
    注: AWS CLI コマンドの実行時にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください
  • ディスク容量が不足しているというエラーメッセージが表示された場合は、データがターゲットクラスターに適合していないことを示しています。より多くのノード、異なる分散スタイル、または異なるノードタイプを使用して、Amazon Redshift クラスターのサイズを変更します。詳細については、Amazon Redshift でのクラスターのサイズ変更を参照してください。
  • サイズ変更操作が完了する前にキャンセルするには、Amazon Redshift コンソールのクラスターの詳細から [サイズ変更のキャンセル] を選択します。または、AWS CLI の cancel-resize コマンドを使用することもできます。
    注: 最終段階の場合、サイズ変更の操作をキャンセルすることはできません。