メニュー
Amazon Redshift
管理ガイド (API Version 2012-12-01)

Amazon Redshift クラスター

概要

Amazon Redshift データウェアハウスは、ノードと呼ばれるコンピューティングリソースのコレクションであり、これらはクラスターと呼ばれるグループを構成します。各クラスターは、1 つの Amazon Redshift エンジンを実行し、1 つ以上のデータベースを含みます。

注記

現時点では、Amazon Redshift バージョン 1.0 エンジンを利用できます。ただし、エンジンの更新に伴い、複数の Amazon Redshift エンジンバージョンを選択できるようになる可能性があります。

コンソールの [Cluster Version] フィールドで、クラスターの Amazon Redshift エンジンとデータベースのバージョンを決定できます。数字の最初の 2 つのセクションはクラスターのバージョンで、最後のセクションはクラスターのデータベースの固有の改訂番号です。次の例では、クラスターバージョンが 1.0 で、データベースの改訂番号が 884 です。

注記

コンソールでは、1 つのフィールドにこの情報が表示されますが、Amazon Redshift API では ClusterVersionClusterRevisionNumber の 2 つのパラメータになります。詳細については、Amazon Redshift API Reference の「クラスター」を参照してください。

Amazon Redshift には [Allow Version Upgrade] という設定があり、クラスターの Amazon Redshift エンジンの新しいバージョンが利用可能になると、エンジンを自動的にアップグレードするかどうかを指定できます。この設定はデータベースバージョンのアップグレードには影響しません。データベースバージョンは、クラスターに指定したメンテナンスウィンドウ中にアップグレードされます。Amazon Redshift エンジンのアップグレードはメジャーバージョンのアップグレードであり、Amazon Redshift データベースのアップグレードはマイナーバージョンのアップグレードです。バージョンの自動アップグレードは、メジャーバージョンに対してのみ無効にできます。マイナーバージョンアップグレードのメンテナンスウィンドウの詳細については、「メンテナンスウィンドウ」を参照してください。

Amazon Redshift のクラスターおよびノード

Amazon Redshift クラスターは、ノードで構成されています。クラスターごとに、リーダーノードと 1 つまたは複数のコンピューティングノードがあります。リーダーノードは、クライアントアプリケーションからクエリを受け取ってクエリを解析し、クエリ実行プランを作成します。次に、コンピューティングノードに対するこれらのプランの並列実行を調整し、コンピューティングノードから得た中間結果を集計してから、最終的にクライアントアプリケーションに結果を返します。コンピューティングノード、はクエリ実行プランを実行し、これらのクエリを処理するためにデータをコンピューティングノード間で伝送します。中間結果は、リーダーノードに送られて集計されてから、クライアントアプリケーションに送り返されます。リーダーノードおよびコンピューティングノードの詳細については、Amazon Redshift Database Developer Guide の「データウェアハウスシステムのアーキテクチャ」を参照してください。

クラスターを起動するときに、オプションの 1 つとしてノードタイプを指定します。ノードタイプによって、各ノードの CPU、RAM、ストレージ容量、およびストレージデバイスでのタイプが決まります。高密度ストレージ (DS) ノードタイプはストレージに最適化されています。高密度コンピューティング (DC) ノードタイプはコンピューティングに最適化されています。

DS2 ノードタイプは、大容量データのワークロードに合わせて最適化されており、ハードディスクドライブ (HDD) ストレージを使用します。

DC1 ノードはパフォーマンス多用するワークロードに適しています。DC1 ノードタイプはソリッドステートドライブ (SSD) ストレージを使用するため、DS ノードタイプに比べて I/O が高速ですが、ストレージスペースは少なくなります。

選択するノードタイプは、主に Amazon Redshift にインポートするデータの量、データベースで実行するクエリとオペレーションの複雑さ、それらのクエリとオペレーションに結果に依存するダウンストリームシステムの必要性によって決まります。

ノードタイプは、さまざまなサイズで使用できます。DS2 ノードは、xlarge サイズと 8xlarge サイズで使用できます。DC1 ノードは、large サイズと 8xlarge サイズで使用できます。ノードサイズとノードの数によって、クラスターのストレージ総容量が決まります。

ノードタイプに応じて、1 つのノード (単一ノード) または複数のノード (複数ノード) を使用できます。8xlarge クラスターの最小ノード数は 2 です。単一ノードクラスターでは、ノードは機能上リーダーとコンピューティングで共有されます。マルチノードクラスターでは、リーダーノードとコンピューティングノードは分かれています。

Amazon Redshift は、各リージョンの各 AWS アカウントのリソースにクォータを適用します。クォータは、アカウントがリージョン内の特定のリソースタイプに作成できるリソースの数を制限します (ノードやスナップショットなど)。Amazon Redshift リソースに適用するデフォルトのクォータの詳細については、アマゾン ウェブ サービス全般のリファレンス の「Amazon Redshift の上限」を参照してください。上限緩和をご希望の場合は、Amazon Redshift 上限緩和申請を送信します。

クラスターのコストは、リージョン、ノードタイプ、ノードの数、ノードが事前に予約されているかどうかによって異なります。ノードのコストについては、「Amazon Redshift の料金表」ページを参照してください。

ノードタイプの詳細

以下のテーブルは、各ノードタイプとサイズのノード仕様をまとめたものです。最初の 2 つテーブルでは、以下の見出しに特定の意味があります。

  • vCPU は各ノードの仮想 CPU の数です。

  • ECU は、各ノードの Amazon EC2 計算ユニットの数です。

  • RAM は、各ノードのギビバイト (GiB) 単位のメモリ量です。

  • 1 ノードあたりのスライスとは、コンピューティングノードでパーティション分割されたスライスの数です。

  • ストレージは、各ノードのストレージの容量とタイプです。

  • ノード範囲とは、Amazon Redshift がサポートするノードタイプとサイズにおけるノードの最小数と最大数です。

    注記

    前述のように、指定したリージョン内の AWS アカウントに適用されたクォータによっては、さらに少ないノードに制限されることがあります。

  • 全容量とは、ノード範囲で指定されているノードの最大数をデプロイした場合のクラスターのストレージ合計容量です。

重要

DS1 ノードタイプは廃止されています。DS1 ノードタイプの既存のクラスターは引き続きサポートされますが、新しいクラスターは DS2 および DC1 でのみ使用可能です。新しい DS2 ノードタイプは DS1 より高いパフォーマンスを追加料金なしで提供します。DS1 リザーブドノードを購入した場合は、DS2 ノードタイプに移行するためのサポートについて、redshift-pm@amazon.com までお問い合わせください。

高密度ストレージノードタイプ

ノードサイズ vCPU ECU RAM (GiB) 1 ノードあたりのスライス 1 ノードあたりのストレージ ノード範囲 総容量
ds2.xlarge 4 13 31 2 2 TB HDD 1–32 64 TB
ds2.8xlarge 36 119 244 16 16 TB HDD 2–128 2 PB

高密度コンピューティングノードタイプ

ノードサイズ vCPU ECU RAM (GiB) 1 ノードあたりのスライス 1 ノードあたりのストレージ ノード範囲 総容量
dc1.large 2 7 15 2 160 GB SSD 1–32 5.12 TB
dc1.8xlarge 32 104 244 32 2.56 TB SSD 2–128 326 TB

ノードタイプの以前の名前

Amazon Redshift の以前のリリースでは、ノードタイプは異なる名前でした。Amazon Redshift API および AWS Command Line Interface (AWS CLI) の古い名前を使用できますが、それらの名前を参照するスクリプトを現在の名前を使用するように更新することをお勧めします。現在の名前と以前の名前は、次のとおりです。

ノードタイプの以前の名前

現在の名前 以前の名前
ds2.xlarge ds1.xlarge、dw.hs1.xlarge、dw1.xlarge
ds2.8xlarge ds1.8xlarge、dw.hs1.8xlarge、dw1.8xlarge
dc1.large dw2.large
dc1.8xlarge dw2.8xlarge

ノードの数の決定

選択するノードの数は、データセットのサイズおよび希望するクエリパフォーマンスによって決まります。例として高密度ストレージノードタイプを使用すると、32 TB のデータがある場合、16 個の ds2.xlarge ノードか、2 個の ds2.8xlarge ノードを選択できます。データの増分が少ない場合は、ds1.xlarge ノードサイズを選択すると 2 TB ずつ拡張できます。一般的に、データの増分が多い場合は、ds2.8xlarge ノードサイズを選択することをお勧めします。

Amazon Redshift はクラスターのすべてのコンピューティングノードにクエリを分散し、並列で実行するので、クラスターにノードを追加するとクエリパフォーマンスを向上させることができます。また、Amazon Redshift はクラスター内のすべてのコンピューティングノードにデータも分散します。2 つ以上のコンピューティングノードを持つクラスターを実行する場合は、各ノードのデータが常に別のノードのディスクにミラーリングされ、データ損失が発生するリスクが減少します。

どちらを選択しても、Amazon Redshift consoleと Amazon CloudWatch メトリクスのクエリパフォーマンスをモニタリングできます。また、必要に応じてノードを追加または削除して、最適に動作するようにストレージとパフォーマンスのバランスをとることもできます。追加のノードをリクエストしたときは、Amazon Redshift でデプロイメント、ロードバランシング、およびデータメンテナンスの詳細がすべて管理されます。クラスターパフォーマンスの詳細については、「Amazon Redshift クラスターのパフォーマンスをモニタリングする」を参照してください。

より長い期間 (1 年以上など)、継続してクラスターの実行を維持する予定の場合、1 年間または 3 年間、コンピューティングノードを予約することで、料金を大幅に節約することができます。コンピューティングノードを予約するには、リザーブドノードというサービスをご購入ください。予約する個々のコンピューティングノードについて、1 つのサービスを購入します。コンピューティングノードを予約した場合、クラスターが実行されているかどうかにかかわらず、固定の前払い料金と時間料金をお支払いいただきます。ただし、時間料金は、オンデマンドの使用料金よりも大幅に安くなります。詳細については、「Amazon Redshift リザーブドノードの購入」を参照してください。

クラスターのサイズ変更

最初にクラスターをプロビジョニングした後にストレージとパフォーマンスの要件が変更された場合、クラスターのサイズを変更できます。ノードを追加または削除してクラスターをスケールインまたはスケールアウトできます。また、別のノードタイプを指定してクラスターを拡大または縮小することもできます。

たとえば、さらにノードを追加したり、ノードタイプを変更したり、単一ノードクラスターをマルチノードクラスターに変更したり、マルチノードクラスターを単一ノードクラスターに変更したりすることができます。 ただし、変更後のクラスターが、現在のデータを保持するのに十分な大きさであることを確認する必要があります。変更後のサイズが不十分な場合、サイズの変更は失敗します。 API を使用するときは、ノードタイプ、ノードサイズ、ノードの数のいずれかのみを変更する場合でもすべて指定する必要があります。

以下にリサイズプロセスを示します。

  1. リサイズプロセスを開始すると、Amazon Redshift はリサイズリクエストを承認するイベント通知を送信し、新しい (ターゲット) クラスターのプロビジョニングを開始します。

  2. 新しい (ターゲット) クラスターがプロビジョニングされると、Amazon Redshift はリサイズが開始されたというイベント通知を送信し、読み取り専用モードで既存の (ソース) クラスターを再開します。再起動すると、クラスターへの既存の接続はすべて終了します。 すべての完了しなかったトランザクション (コピーも含めて) は、ロールバックされます。クラスターが読み取り専用モードの場合、クエリの読み取りはできますが、クエリの書き込みはできません。

  3. Amazon Redshift は、ソースクラスターからターゲットクラスターにデータをコピーし始めます。

  4. リサイズプロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。

  5. リサイズが完了すると、Amazon Redshift はリサイズが完了したというイベント通知を送信します。ターゲットクラスターに接続し、クエリの読み取りと書き取りの実行を再開できます。

クラスターのサイズを変更するとき、サイズ変更が完了するまでは読み取り専用モードのままです。 Amazon Redshift consoleのクラスターの [Status] タブでサイズ変更の進捗を確認することができます。クラスターのサイズ変更にかかる時間は、各ノードのデータ量に左右されます。通常、サイズ変更処理には数時間から 1 日かかります。ただし、データ量が多いクラスターではさらに時間がかかることもあります。これは、データが元のクラスターの各ノードからコピー先のクラスターのノードに並列コピーされるためです。クラスターのサイズ変更の詳細については、「チュートリアル: Amazon Redshift クラスターのサイズ変更」および「クラスターのサイズ変更」を参照してください。

サイズ変更の操作中、Amazon Redshift はテーブルをソートしません。クラスターのサイズを変更すると、Amazon Redshift は分散方式に基づいてデータベースのテーブルを新しいコンピューティングノードに分散し、ANALYZE を実行して統計を更新します。削除のマークが付いた行は転送されないため、テーブルを再ソートする必要がある場合のみ VACUUM を実行する必要があります。詳細については、Amazon Redshift Database Developer Guide の「テーブルのバキューム処理」を参照してください。

クラスターがパブリックであり、VPC 内に存在する場合、サイズ変更後もリーダーノードの elastic IP アドレス (EIP) は変更されません。クラスターがプライベートであり、VPC 内に存在する場合、サイズ変更後もリーダーノードのプライベート IP アドレスは変更されません。クラスターが VPC 内に存在しない場合、サイズ変更オペレーションの一部として、新しいパブリック IP アドレスがリーダーノードに割り当てられます。

クラスターのリーダーノード IP アドレスを取得するには、以下に示すように dig ユーティリティを使用します。

Copy
dig mycluster.abcd1234.us-west-2.redshift.amazonaws.com

リーダーノード IP アドレスは、以下に示すように結果の ANSWER SECTION の末尾にあります。

dig ユーティリティは、BIND ソフトウェアダウンロードの一部として入手できます。BIND の詳細については、Internet Systems Consortium のドキュメントの BIND に関する説明を参照してください。

クラスターの起動用にサポートされているプラットフォーム

Amazon Redshift クラスターは、選択した Amazon Redshift のノードタイプとサイズ用に構成された Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されます。EC2-Classic か EC2-VPC のどちらかのプラットフォームで Amazon Redshift クラスターを起動できます。これらのプラットフォームは、Amazon EC2 インスタンスに対してサポートされています。これらのプラットフォームの詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイド の「サポートされているプラットフォーム」を参照してください。利用可能なプラットフォームは、ご利用の AWS アカウントの設定によって異なります。

注記

SQL クライアントツールと Amazon Redshift データベース間の接続上の問題を防ぐために、ホストがパケットサイズを処理できるようにインバウンドルールを設定するか、あるいはご使用の Amazon EC2 インスタンスのネットワークインターフェース (NIC) で最大送信単位を 1500 に設定して TCP/IP のジャンボフレームを無効にしておくことをお勧めします。 上記の方法の詳細については、「クエリがハングして、クラスターに達しない場合がある」を参照してください。

EC2-Classic プラットフォーム

EC2-Classic プラットフォームでは、クラスターは他の AWS ユーザーと共有する単一のフラットネットワーク内で稼働します。EC2-Classic プラットフォームでクラスターをプロビジョニングする場合は、クラスターに 1 つ以上の Amazon Redshift クラスターセキュリティグループを関連付けて、クラスターへのアクセスを制御します。詳細については、「Amazon Redshift クラスターセキュリティグループ」を参照してください。

EC2-VPC プラットフォーム

EC2-VPC プラットフォームでは、クラスターは論理的に AWS アカウントに限定された Virtual Private Cloud (VPC) 内で稼働します。EC2-VPC プラットフォームのクラスターをプロビジョニングする場合は、クラスターに 1 つ以上の VPC のセキュリティグループを関連付けて、クラスターへのアクセスを制御します。詳細については、Amazon VPC ユーザーガイド の「VPC のセキュリティグループ」を参照してください。

VPC でクラスターを作成するには、最初に VPC のサブネット情報を指定して Amazon Redshift クラスターサブネットグループを作成してから、クラスターの起動時にサブネットグループを指定する必要があります。詳細については、「Amazon Redshift のクラスターサブネットグループ」を参照してください。

Amazon Virtual Private Cloud (Amazon VPC) に関する詳細については、Amazon VPC の製品詳細ページを参照してください。

プラットフォームの選択

AWS アカウントは、インスタンスを両方のプラットフォームで起動できるか、EC2-VPC だけで起動できるかが、リージョンごとに決まっています。アカウントがサポートしているプラットフォームを確認し、クラスターを起動するには、次の操作を行います。

  1. クラスターをデプロイする AWS リージョンを決定します。Amazon Redshift を利用できる AWS リージョンのリストについては、アマゾン ウェブ サービス全般のリファレンス の「リージョンとエンドポイント」を参照してください。

  2. 選択した AWS リージョンでアカウントがサポートしている Amazon EC2 プラットフォームを確認します。この情報は、Amazon EC2 コンソールで確認できます。手順については、Linux インスタンス用 Amazon EC2 ユーザーガイド の「サポートされているプラットフォーム」を参照してください。

  3. アカウントが両方のプラットフォームをサポートしている場合は、Amazon Redshift クラスターをデプロイするプラットフォームを選択します。アカウントが EC2-VPC のみをサポートしている場合は、VPC にクラスターをデプロイする必要があります。

  4. Amazon Redshift クラスターをデプロイします。Amazon Redshift consoleを使用して、または Amazon Redshift API、CLI、SDK ライブラリを使用してプログラムでクラスターをデプロイすることができます。これらのオプションや関連ドキュメントへのリンクについては、「Amazon Redshift とは?」を参照してください。

リージョンとアベイラビリティゾーンの考慮事項

Amazon Redshift は、複数の AWS リージョンで利用できます。デフォルトでは、Amazon Redshift は、選択した AWS リージョン内のランダムに選択されたアベイラビリティーゾーン (AZ) にクラスターをプロビジョニングします。すべてのクラスターノードが同じ AZ にプロビジョニングされます。

Amazon Redshift が特定の AZ で使用できる場合、オプションでその AZ をリクエストできます。たとえば、1 つの AZ で Amazon EC2 インスタンスが既に実行されている場合、同じ AZ 内に Amazon Redshift クラスターを作成して、レイテンシーを低減させることができます。また、可用性を高めるために別の AZ を選択することもできます。Amazon Redshift は、リージョン内のすべての AZ で使用可能というわけではありません。

Amazon Redshift クラスターをプロビジョニングすることができる、サポートされている AWS リージョンのリストについてはアマゾン ウェブ サービス全般のリファレンス の「リージョンとエンドポイント」を参照してください。

メンテナンスウィンドウ

Amazon Redshift は定期的にメンテナンスを実行して、クラスターにアップグレードを適用します。更新中は Amazon Redshift クラスターで通常の操作を実行することはできません。

Amazon Redshift により、1 週間 (月曜日から日曜日まで) のうちのランダムな日に、リージョンごとに決められた 8 時間のうちのランダムな 30 分間、メンテナンスウィンドウが割り当てられます。次のリストは、デフォルトでメンテナンスウィンドウが割り当てられる各リージョンの時間を示します。

  • 米国東部(バージニア北部) リージョン: 03:00–11:00 UTC

  • 米国東部 (オハイオ) リージョン: 03:00–11:00 UTC

  • 米国西部 (北カリフォルニア) リージョン: 06:00–14:00 UTC

  • 米国西部 (オレゴン) リージョン: 06:00–14:00 UTC

  • カナダ (中部) リージョン: 03:00–11:00 UTC

  • アジアパシフィック (ムンバイ) リージョン: 16:30–00:30 UTC

  • アジアパシフィック (ソウル) リージョン: 13:00–21:00 UTC

  • アジアパシフィック (シンガポール) リージョン: 14:00–22:00 UTC

  • アジアパシフィック (シドニー) リージョン: 12:00–20:00 UTC

  • アジアパシフィック (東京) リージョン: 13:00–21:00 UTC

  • 欧州 (フランクフルト) リージョン: 06:00–14:00 UTC

  • 中国 (北京) リージョン: 13:00–21:00 UTC

  • 欧州 (アイルランド) リージョン: 22:00–06:00 UTC

  • 欧州 (ロンドン) リージョン: 22:00–06:00 UTC

  • 南米 (サンパウロ) リージョン: 19:00–03:00 UTC

メンテナンスイベントが特定の週に予定されている場合、割り当てられた 30 分のメンテナンスウィンドウ中に開始されます。メンテナンスの実行中、Amazon Redshift で実行中のクエリまたはその他の操作は終了します。ほとんどのメンテナンスは 30 分のメンテナンスウィンドウ中に完了しますが、メンテナンスタスクの一部はウィンドウが閉じた後も実行を続ける場合があります。スケジュールされたメンテナンスウィンドウの間に実行されるメンテナンスタスクがない場合、クラスターは次にスケジュールされたメンテナンスウィンドウまで通常どおり稼働します。

クラスターをプログラムで、または Amazon Redshift consoleを使用して変更すると、スケジュールされたメンテナンスウィンドウを変更できます。ウィンドウは 30 分以上、24 時間以内である必要があります。詳細については、「コンソールを使ったクラスターの管理」を参照してください。

デフォルトのディスク容量アラーム

Amazon Redshift クラスターを作成するとき、クラスターのすべてのノードで使用されているディスク容量の平均比率を監視するように Amazon CloudWatch アラームを任意で設定できます。このアラームをデフォルトのディスク容量アラームと言います。

デフォルトのディスク容量アラームの目的は、クラスターのストレージ容量を監視することです。このアラームは、データウェアハウスのニーズを基に設定できます。たとえば、別のノードタイプにするかノードを追加するため、または今後の拡張に備えてリザーブドノードを購入するためにクラスターのサイズを変更する必要性の指標として警告を使用できます。

ディスクの使用量が、指定した期間、特定の回数の指定した割合に達したとき、または超えたとき、デフォルトのディスク容量アラームがトリガーされます。デフォルトでは、指定した割合に達し、かつ 5 分以上その割合かそれ以上の状態が続いたとき、このアラームがトリガーされます。デフォルトの値は、クラスターを起動した後編集できます

CloudWatch アラームがトリガーされると、Amazon Simple Notification Service (Amazon SNS) により、指定された受取人に、割合がしきい値に達したことを警告する通知が送信されます。Amazon SNS は、トピックを使用して通知を送信する受取人とメッセージを指定します。既存の Amazon SNS トピックを使用できますが、クラスターの起動時に指定した設定に基づいてトピックを作成することもできます。このアラームのトピックは、クラスターを起動した後編集できます。Amazon SNS トピック作成の詳細については、「Amazon Simple Notification Service の使用開始」を参照してください。

クラスターを起動した後、[CloudWatch Alarms] の下のクラスターの [Status] ウィンドウからアラームを表示したり編集したりすることができます。名前は percentage-disk-space-used-default-<string です。アラームを開いて、関連付けられている Amazon SNS トピックを表示し、アラームの設定を編集することができます。既存の Amazon SNS トピックを使用するように選択していない場合、作成されるトピックの名前は、<clustername-default-alarms (<recipient>) です。たとえば、xamplecluster-default-alarms (notify@example.com) のようになります。

デフォルトのディスク容量アラームを設定して編集する方法については、「クラスターの作成」および「デフォルトのディスク容量アラームの編集」を参照してください。

注記

クラスターを削除すると、クラスターに関連付けられているアラームは削除されませんが、トリガーされることもありません。必要がなくなったら、CloudWatch コンソールからアラームを削除できます。

クラスターの名前変更

クラスターに別の名前を使用する必要がある場合は、クラスターの名前を変更できます。クラスターのエンドポイントには、クラスター名 (クラスター識別子とも呼ばれる) が含まれているため、名前の変更が完了した後、新しい名前を使用するようにエンドポイントを変更します。たとえば、既存の examplecluster という名前のクラスターを、newcluster という名前に変更した場合は、newcluster 識別子を使用するようにエンドポイントを変更します。このクラスターに接続するアプリケーションは、新しいエンドポイントで更新する必要があります。

アプリケーションのエンドポイントを変更せずに、アプリケーションが接続するクラスターを変更する必要がある場合も、クラスターの名前を変更することができます。この場合は、最初に元のクラスターの名前を変更してから、新しく接続するクラスターの名前を元のクラスターの名前に変更する必要があります。クラスター識別子はアカウントとリージョン内で一意にする必要があり、元のクラスターと変更後のクラスターを同じ名前にできないため、この操作が必要になります。スナップショットからクラスターを復元するときに、依存アプリケーションの接続プロパティを変更したくない場合も、この操作を行います。

注記

元のクラスターを削除する場合は、不要なクラスターのスナップショットを削除してください。

クラスターの名前を変更すると、クラスターの状態は、このプロセスが終了するまで renaming に変わります。クラスターに使用していた古い DNS 名は直ちに削除されますが、キャッシュには数分間残っています。名前を変更したクラスターの新しい DNS 名は、10 分以内で有効になります。名前を変更したクラスターは、新しい名前が有効になるまで使用できません。クラスターが再起動され、クラスターへの既存の接続は削除されます。これが完了すると、新しい名前を使用するようにエンドポイントが変更されます。そのため、名前の変更を開始する前にクエリの実行を停止し、名前の変更後に再起動する必要があります。

クラスターのスナップショットは保持され、クラスターに関連付けられたすべてのスナップショットは、クラスターの名前を変更した後も関連付けを維持します。たとえば、本番稼働用データベースにサービスを提供するクラスターがあり、そのクラスターに複数のスナップショットがあるとします。クラスターの名前を変更し、スナップショットのある本番環境に置き換えると、名前を変更したクラスターに既存のスナップショットが関連付けられます。

Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) イベントの通知は、クラスター名に関連付けられます。クラスターの名前を変更した場合、それに応じてこれらの通知も更新する必要があります。Events ペインの CloudWatch コンソールで CloudWatch アラームを、Amazon Redshift コンソールで Amazon SNS イベント通知を更新できます。クラスターのロードおよびクエリデータには、名前変更前と名前変更後のデータが引き続き表示されます。ただし、パフォーマンスデータは、名前変更プロセスの完了後にリセットされます。

詳細については、「クラスターの変更」を参照してください。

クラスターのシャットダウンと削除

クラスターの実行を停止して料金の発生を防ぐ場合は、クラスターをシャットダウンできます。シャットダウンするときに、オプションで最終スナップショットを作成できます。最終スナップショットを作成する場合、Amazon Redshift はクラスターの手動スナップショットを作成した後、クラスターをシャットダウンします。後でクラスターの実行とデータのクエリを再開する場合は、そのスナップショットを復元できます。

クラスターとそのデータが不要になった場合は、最終スナップショットを作成しないでシャットダウンすることができます。この場合、クラスターとデータは完全に削除されます。クラスターのシャットダウンと削除の詳細については、「クラスターの削除」を参照してください。

クラスターのシャットダウン時に最終的な手動スナップショットを作成するかどうかにかかわらず、クラスターのシャットダウン後、クラスターに関連付けられた自動スナップショットはすべて削除されます。クラスターに関連付けられた手動スナップショットは保持されます。オプションの最終スナップショットも含めて、保持された手動スナップショットは、クラスターをシャットダウンするときに実行中のクラスターが他にない場合、または、実行中の Amazon Redshift クラスターで利用できる無料ストレージ枠を超えている場合、Amazon Simple Storage Service ストレージ料金が課金されます。スナップショットのストレージ料金の詳細については、Amazon Redshift の料金表ページを参照してください。

クラスターステータス

クラスター状態は、クラスターの現在のステータスを表示します。 次の表では、各クラスターステータスについて説明します。

ステータス 説明
available クラスターは実行されていて、利用可能です。
creating Amazon Redshift はクラスターを作成しています。 詳細については、「クラスターの作成」を参照してください。
deleting Amazon Redshift はクラスターを削除しています。 詳細については、「クラスターの削除」を参照してください。
final-snapshot Amazon Redshift は、クラスターを削除する前に最後のスナップショットを取得しています。 詳細については、「クラスターの削除」を参照してください。
hardware-failure

クラスターにハードウェア障害が生じました。

単一ノードクラスターがある場合、そのノードを置き換えることはできません。 クラスターを復元するには、スナップショットを使います。 詳細については、「Amazon Redshift スナップショット」を参照してください。

incompatible-hsm Amazon Redshift は、ハードウェアセキュリティモジュール (HSM) に接続できません。 クラスターと HSM 間の HSM 設定を確認してください。 詳細については、「Amazon Redshift でのハードウェアセキュリティモジュールを使用した暗号化について」を参照してください。
incompatible-network 基本的なネットワーク設定に問題があります。 クラスターを起動する VPC が存在すること、そして設定が正しいことを確認してください。 詳細については、「Amazon Virtual Private Cloud (VPC) でクラスターを管理する」を参照してください。
incompatible-parameters 関連付けられたパラメータグループの 1 つ以上のパラメータ値に問題があり、パラメータ値の適用ができません。 パラメータグループを変更し、無効な値を更新してください。 詳細については、「Amazon Redshift パラメータグループ」を参照してください。
incompatible-restore スナップショットからクラスターを復元時に問題が発生しました。 別のスナップショットでクラスターの復元を再度お試しください。 詳細については、「Amazon Redshift スナップショット」を参照してください。
modifying Amazon Redshift は、クラスターへの変更を加えています。 詳細については、「クラスターの変更」を参照してください。
rebooting Amazon Redshift は、クラスターを再起動しています。 詳細については、「クラスターの再起動」を参照してください。
renaming Amazon Redshift は、クラスターに新しい名前を適用しています。 詳細については、「クラスターの名前変更」を参照してください。
resizing Amazon Redshift は、クラスターのサイズを変更しています。 詳細については、「クラスターのサイズ変更」を参照してください。
rotating-keys Amazon Redshift は、クラスターの暗号化キーを更新しています。 詳細については、「Amazon Redshift での暗号化キーの更新について」を参照してください。
storage-full クラスターがストレージ容量限に達しました。 ノードを追加するためにクラスターのサイズ変更をするか、または別のノードサイズを選択してください。 詳細については、「クラスターのサイズ変更」を参照してください。
updating-hsm Amazon Redshift は HSM 設定を更新しています。 詳細については、「Amazon Redshift でのハードウェアセキュリティモジュールを使用した暗号化について」を参照してください。