Amazon Redshift クラスターの従来のサイズ変更が完了するまでに時間がかかる理由を教えてください。

解決策

Amazon Redshift クラスターが従来のサイズ変更を完了するのに必要な時間は、数時間から数日までさまざまです。クラスターの従来のサイズ変更に時間がかかる理由は以下のとおりです。

• ソースクラスターの読み取りワークロード
• 転送されるテーブルの数とサイズ
• テーブル定義と歪んだテーブル
• ソースクラスターとターゲットクラスターで使用するノードの数とタイプ

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

従来のサイズ変更に必要な時間を短縮するには、次のタスクを実行してください。

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

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

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

従来のサイズ変更の問題をトラブルシューティングするには、次のタスクを実行します。

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

関連情報

Amazon Redshift クラスターのサイズを変更する方法を教えてください。

Amazon Redshift クラスターのテーブルで消費されるディスクストレージ容量が予想よりも多かったり、少なかったりする理由を教えてください。