Amazon Redshift でのクラスター管理の概要

クラスターの作成後、クラスターに対して実行できるオペレーションがいくつかあります。このオペレーションには、サイズ変更、一時停止、再開、名前変更、削除が含まれます。

Amazon Redshift でのクラスターのサイズ変更

データウェアハウスの容量とパフォーマンスのニーズが変わるため、クラスターサイズを変更して、Amazon Redshift のコンピューティングとストレージオプションを最大限に活用することができます。

サイズ変更操作には次の 2 つのタイプがあります。

• 伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードなど、ノードタイプを変更することもできます。伸縮自在なサイズ変更はすばやい操作で、通常は数分で完了します。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。

  • 既存のクラスターにノードを追加または削減するが、ノードタイプは変更しない場合 - これは一般的にインプレースサイズ変更と呼ばれます。このタイプのサイズ変更を実行すると、実行中のクエリの一部は正常に完了しますが、他のクエリは操作の一部として破棄される場合があります。伸縮自在なサイズ変更は数分で完了します。

  • クラスターのノードタイプの変更 - ノードタイプを変更すると、スナップショットが作成されて、ソースクラスターから新しいノードタイプで構成されるクラスターにデータが再分配されます。完了すると、実行中のクエリは破棄されます。インプレースのサイズ変更のように、すぐに完了します。

• 従来のサイズ変更 - ノードタイプ、ノード数、またはその両方を、伸縮自在なサイズ変更と同様に変更できます。従来のサイズ変更は完了するまでに時間がかかりますが、ノード数の変更または移行先のノードタイプが、伸縮自在なサイズ変更の範囲内に収まらない場合は便利です。例えば、ノード数の変更が非常に大規模な場合に当てはまります。従来のサイズ変更を使用してクラスターの暗号化を変更することもできます。たとえば、暗号化されていないクラスターが AWS KMS 暗号化するように修正できます。

サイズ変更のスケジューリング - クラスターのサイズ変更操作をスケジュールして、使用率の増加の予想に伴ってスケールアップしたり、コスト削減のためにスケールダウンしたりすることができます。スケジューリングは、伸縮自在なサイズ変更と従来のサイズ変更の両方に使えます。Amazon Redshift コンソールでスケジュールのセットアップできます。詳細については、[Managing clusters using the console] (コンソールを使ってクラスター管理) の「クラスターのサイズ変更」を参照してください。AWS CLI または Amazon Redshift API 操作を使用して、サイズ変更をスケジュールすることもできます。詳細については、AWS CLI コマンドリファレンスの「create-scheduled-action」または Amazon Redshift API リファレンスの「CreateScheduledAction」を参照してください。

伸縮自在なサイズ変更

同じタイプのノードを追加または削除する場合、伸縮自在なサイズ変更操作には、次の段階があります。

1. 伸縮自在なサイズ変更は、クラスターのスナップショットを作成します。該当する場合、このスナップショットには常にノード用にバックアップしないテーブルが含まれています。(RA3 など、一部のノードタイプには、バックアップしないテーブルがありません。) 自動スナップショットを無効にしているため、クラスターに最近のスナップショットがない場合、バックアップオペレーションに時間がかかることがあります。(サイズ変更操作を開始する前の時間を最小限に抑えるため、自動スナップショットを有効にするか、サイズ変更を開始する前に手動スナップショットを作成することをお勧めします。) 伸縮自在なサイズ変更を開始し、スナップショット操作が現在進行中の場合、スナップショット操作が数分以内に完了しないと、伸縮自在なサイズ変更が失敗することがあります。詳細については、「Amazon Redshift スナップショットとバックアップ」を参照してください。

2. このオペレーションはクラスターのメタデータを移行します。クラスターは数分間使用できません。クエリの大部分は一時的に停止され、接続は開いた状態になります。ただし、一部のクエリは削除される可能性があります。この段階は短い。

3. セッション接続が回復し、クエリが再開します。

4. 伸縮自在なサイズ変更は、バックグラウンドでノードスライスにデータを再分配します。クラスターは読み取りと書き込み操作に利用できますが、一部のクエリは実行に時間がかかる可能性があります。

5. 操作が完了すると、Amazon Redshift はイベント通知を送信します。

伸縮自在なサイズ変更を使用してノードタイプを変更すると、同じタイプのノードを追加または削除する場合と同様に操作できます。まず、スナップショットが作成されます。新しいターゲットクラスターはスナップショットの最新データでプロビジョニングされ、データはバックグラウンドの新しいクラスターに転送されます。この期間中、データは読み取りのみ可能です。サイズ変更が完了間近になると、Amazon Redshift はエンドポイントを更新して新しいクラスターを指し、ソースクラスターへのすべての接続が破棄されます。

リザーブドノード (DS2 リザーブドノードなど) がある場合、サイズ変更を実行する際に RA3 リザーブドノードへのアップグレードができます。このアップグレードは、伸縮自在なリサイズを実行するか、コンソールを使用してスナップショットからの復元を実行するときに使用できます。このコンソールは、このプロセスについて説明します。RA3 ノードへのアップグレードの詳細については、「RA3 ノードタイプへのアップグレード」を参照してください。

新しいコンソール

Amazon Redshift コンソールを使用してサイズ変更オペレーションの進捗状況をモニタリングするには、[CLUSTERS (クラスター)] を選択してから、サイズ変更するクラスターを選択して詳細を表示します。

伸縮自在なサイズ変更は、テーブルをソートせず、ディスクスペースを回復しないため、バキューム操作に代わるものではありません。詳細については、「テーブルのバキューム処理」を参照してください。

伸縮自在なサイズ変更には以下の制約があります。

• 伸縮自在なサイズ変更とデータ共有クラスター - データ共有のプロデューサーであるクラスターでノードを追加または削除すると、Amazon Redshift がクラスターメタデータを移行している間、コンシューマーから接続できません。同様に、伸縮自在なサイズ変更を実行して新しいノードタイプを選択した場合、接続がドロップされ、新しいターゲットクラスターに転送される間、データ共有は利用できません。どちらのタイプの伸縮自在なサイズ変更でも、プロデューサーは数分間利用できません。

• 単一ノードクラスター - 伸縮自在なサイズ変更を使用して単一ノードクラスターから変更、または単一ノードクラスターにサイズ変更することはできません。

• 共有スナップショットからデータを転送しているクラスターで伸縮自在なサイズ変更を実行するには、クラスターで少なくとも 1 つのバックアップを使用できる必要があります。バックアップは、Amazon Redshift コンソールのスナップショットのリスト、describe-cluster-snapshots CLI コマンド、または DescribeClusterSnapshots API オペレーションで表示できます。

• プラットフォーム制限 - 伸縮自在なサイズ変更は、EC2-VPC プラットフォームを使用するクラスターでのみ利用できます。詳細については、「クラスターの作成時に EC2-VPC を使用する」を参照してください。

• ストレージの考慮事項 - 新しいノード設定では、既存データに十分なストレージを確保する必要があります。ノードの追加または設定の変更が必要な場合があります。

• ソース vs ターゲットクラスターサイズ - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類は、ソースクラスターのノード数と、サイズ変更したクラスター用に選択されたノードタイプによって決まります。使用可能な設定を確認するには、コンソールを使用します。また、action-type resize-cluster オプションで describe-node-configuration-options AWS CLI コマンドを使用することもできます。Amazon Redshift コンソールを使用したメタデータの編集の詳細については、クラスターのサイズ変更 を参照してください。

  次の CLI コマンドの例では、使用可能な設定オプションを確認できます。この例では、mycluster という名前のクラスターは dc2.large 8 ノードクラスターです。

  aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

  このコマンドは、各オプションの推奨ノードタイプ、ノード数、およびディスク使用率を含むオプションリストを返します。返される設定は、特定の入力クラスターに基づいて異なります。resize-cluster CLI コマンドのオプションを指定するときに、これらの返された設定のいずれかを選択できます。

• 追加ノードの上限 - 伸縮自在なサイズ変更には、クラスターに追加できるノードに制限があります。例えば、dc2 クラスターでは、ノード数が 2 倍までの伸縮自在なサイズ変更をサポートします。例えば、4 ノード型 dc2.8xlarge クラスターにノードを追加して 5 ノードのクラスターにしたり、8 ノードになるまでさらにノードを追加できます。

  ra3 ノードタイプには、ノード数を既存の数の 4 倍まで増やすことができるものもあります。例えば、クラスターが ra3.4xlarge ノードまたは ra3.16xlarge ノードで構成されているとします。この場合、伸縮自在なサイズ変更を使用して、8 ノードのクラスターのノード数を 32 に増やすことができます。または、制限値を下回る値も選択できます。(クラスターを 4 倍に拡張できるかどうかは、ソースクラスターのサイズによることに注意してください。) クラスターに ra3.xlplus ノードがある場合、制限値は 2 倍になります。

  すべての ra3 ノードタイプでは、ノード数を既存の数の 4 分の 1 に減らすことができます。例えば、ra3.4xlarge ノードを持つクラスターのサイズを 12 ノードから 3 ノードに、または最小値を超えた値に減らすことができます。

  次の表は、伸縮自在なサイズ変更がサポートされている各ノードタイプの増加の制限値と削減の制限値を示しています。

  ノードの種類	増加制限値	削減制限値
  ra3.16xlarge	4 倍 (例えば、4 ノードから 16 ノード)	数字の 4 分の 1 (例えば、16 から 4 ノード)
  ra3.4xlarge	4 倍	数字の 4 分の 1
  ra3.xlplus	2 倍 (例えば、4 ノードから 8 ノード)	数字の 4 分の 1
  dc2.8xlarge	2 倍	数字の 2 分の 1 (例えば、16 から 8 ノード)
  dc2.large	2 倍	数字の 2 分の 1
  ds2.8xlarge	2 倍	数字の 2 分の 1
  ds2.xlarge	2 倍	数字の 2 分の 1

[従来のサイズ変更]

従来のサイズ変更は、クラスターサイズまたはノードタイプの変更が、伸縮自在なサイズ変更でサポートされる仕様の範囲外である場合、対処します。従来のサイズ変更は、過去数時間または数日かかっていた大量のデータの移行をより迅速に完了するため、パフォーマンスが向上しました。ソースとターゲットクラスター間のバックアップと復元操作を利用することでこれを実行します。また、より効率的な分散を使用して、データをターゲットクラスターにマージします。

準備段階として、サイズ変更を開始する前に、ソースクラスターのバックアップスナップショットを取るか、スナップショットを取ることが重要です。

従来のサイズ変更には、次のステージが含まれます。

1. ソースクラスターからターゲットクラスターへの初期移行。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。クラスターがデータ共有のプロデューサーである場合、これにはコンシューマーからの接続も含まれます。再起動後、クラスターは読み取り専用モードになり、データ共有が再開されます。これらのプロセスには数分かかる場合があります。次に、データがターゲットクラスターに移行され、読み取りと書き込みの両方が使用可能になります。

2. 均等分散として移行された分散キーテーブルは、バックグラウンドワーカーを使用して元の分散スタイルに戻されます。このフェーズの期間は、データセットのサイズによって異なります。詳細については、「分配スタイル」を参照してください。

   このプロセスでは、データベースへの読み取りと書き込みの両方が機能します。クエリのパフォーマンスが低下する可能性があります。

3. サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーロールを引き受けます。

4. サイズ変更が完了すると、Amazon Redshift はイベント通知を送信します。

サイズ変更の進行状況は、Amazon Redshift コンソールで確認できます。クラスターのサイズ変更にかかる時間は、データ量に左右されます。

注記

大量のデータを含むクラスターに従来のサイズ変更を実行するときにノードが RA3 ではない場合、データ移行が非常に遅くなる可能性があります。数テラバイトのデータを含むクラスターを移行するには、数日かかる場合があります。RA3 ノードのデータ転送は、はるかに迅速に完了します。

伸縮自在なサイズ変更 vs 従来のサイズ変更

次の表は、2 つのサイズ変更タイプの動作を比較しています。

伸縮自在なサイズ変更 vs 従来のサイズ変更
Behavior	伸縮自在なサイズ変更	[従来のサイズ変更]	コメント
システムデータ保持	伸縮自在なサイズ変更は、システムログデータを保持します。	従来のサイズ変更は、システムテーブルとデータを保持しません。	ソースクラスターで監査ログ記録を有効にしている場合、サイズ変更をしたあと、Amazon S3 または CloudWatch でログへのアクセスを継続できます。これらのログは、指定したデータポリシーに応じて保持または削除することができます。
ノードタイプの変更	ノードタイプが変わらない場合、伸縮自在なサイズ変更: インプレースのサイズ変更すると、ほとんどのクエリが保持されます。 新しいノードタイプを選択した状態で伸縮自在なサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセスが完了すると、クエリは破棄されます。	クラシックサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセス中にクエリは破棄されます。
セッションとクエリの保持	伸縮自在なサイズ変更では、ソースクラスターとターゲットでノードタイプが同じである場合、セッションとクエリが保持します。新しいノードタイプを選択する場合、クエリは破棄されます。	クラシックサイズ変更では、セッションとクエリは保持されません。クエリが破棄されます。	クエリが破棄されると、ある程度のパフォーマンス低下が予想されます。サイズ変更操作は、使用負荷が低い時間に行うのが最適です。
テーブルソート	テーブルはサイズ変更操作の一部としてソートされません。	テーブルはサイズ変更操作の一部としてソートされません。	Amazon Redshift はサイズ変更オペレーション中にテーブルをソートしないため、既存のソート順序が維持されます。クラスターのサイズを変更すると、Amazon Redshift はデータベーステーブルを新しいノードに分配し、ANALYZE コマンドを実行して統計を更新します。削除対象としてマークされた行は転送されないため、テーブルの再ソートが必要な場合のみ VACUUM コマンドを実行する必要があります。詳細については、「Amazon Redshift データベースデベロッパーガイド」の「テーブルのバキューム」を参照してください。
サイズ変更操作のキャンセル	伸縮自在なサイズ変更をキャンセルすることはできません。	Amazon Redshift コンソールのクラスター詳細から [Cancel resize (サイズ変更のキャンセル)] を選択すると、従来のサイズ変更オペレーションが完了する前にキャンセルできます。	サイズ変更のキャンセルに要する時間は、キャンセルするとき、サイズ変更オペレーションのどのステージにあるかによって異なります。この操作を実行すると、キャンセル操作が完了するまでクラスターを利用できません。サイズ変更操作が最終ステージに達している場合、キャンセルできません。

スナップショット、リストア、およびサイズ変更

伸縮自在なサイズ変更は、Amazon Redshift クラスターのサイズを変更する最速の方法です。伸縮自在なサイズ変更オプションを選択できず、クラスターにほぼ恒常的な書き込みアクセスが必要な場合は、次のセクションで説明している、スナップショットと復元オペレーションを使用します。この方法では、スナップショットが作成された後でソースクラスターに書き込まれたデータは、ターゲットクラスターに切り替えた後、手動でコピーする必要があります。コピーにかかる時間によっては、両方のクラスター内のデータが同じになるまで、この操作を数回繰り返す必要がある場合もあります。その後で、ターゲットクラスターに切り替えられます。このプロセスは、ターゲットクラスターのすべてのデータが使用可能になるまでに、既存のクエリに悪影響を及ぼす可能性があります。ただし、データベースへの書き込みができない時間は最短になります。

スナップショット、復元、従来のサイズ変更アプローチでは、次のプロセスを使用します。

1. 既存のクラスターのスナップショットを作成します。既存のクラスターがソースクラスターです。

2. スナップショットを作成した時刻を記録します。そうすることで、スナップショット後のデータをターゲットデータベースにロードするための抽出、処理、ロード (ETL) プロセスを再実行する必要がある時点を識別できるようにします。

3. 新しいクラスターにスナップショットを復元します。この新しいクラスターがターゲットクラスターです。サンプルデータがターゲットクラスターにあることを確認します。

4. ターゲットクラスターのサイズを変更します。ターゲットクラスターに関して、新しいノードタイプ、ノード数、その他の設定を選択します。

5. ソースクラスターのスナップショット作成後に発生した ETL プロセスでロードされたデータを確認します。ターゲットクラスターには、同じデータを同じ順序で再ロードしてください。進行中のデータロードがある場合、ソースクラスターとターゲットクラスターのデータが同じになるまで、このプロセスを数回繰り返します。

6. ソースクラスターで実行中のすべてのクエリを停止します。これを行うには、クラスターを再起動するか、スーパーユーザーとしてログオンし、PG_CANCEL_BACKEND コマンドおよび PG_TERMINATE_BACKEND コマンドを使用できます。クラスターを再起動すると、クラスターが使用できないことを最も簡単に確認できます。

7. ソースクラスター名を変更します。たとえば、examplecluster から examplecluster-source に変更します。

8. 変更前のソースクラスター名を使用して、ターゲットクラスターの名前を変更します。たとえば、ターゲットクラスターの名前を examplecluster に変更します。これ以降、examplecluster を含むエンドポイントを使用するアプリケーションは、ターゲットクラスターに接続します。

9. ターゲットクラスターに切り替えた後、ソースクラスターを削除し、すべてのプロセスが期待どおりに動作することを確認します。

または、データをターゲットクラスターに再ロードする前にソースとターゲットクラスターの名前を変更することもできます。このアプローチは、ターゲットクラスター用の依存システムとレポートをすぐに最新状態にする要件がない場合に適しています。この場合、ステップ 6 は前述のプロセスの最後に移動されます。

名前変更プロセスは、アプリケーションが引き続き同じエンドポイントを使用してクラスターに接続する必要がある場合にのみ必要になります。これが必要ない場合は、クラスターの名前を変更せずにそのクラスターに接続するアプリケーションを、ターゲットクラスターのエンドポイントを使用するように更新することもできます。

クラスター名を再利用するのには、いくつかの利点があります。最初に、エンドポイントが変わらないため、基盤となるクラスターを変更しても、アプリケーションの接続文字列を更新する必要がありません。次に、Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) の通知などの関連項目が、クラスター名に固定されます。これは、クラスターにセットアップした同じアラームと通知を継続して使用することができるということです。この継続的な使用は、アラームや通知などの関連項目を再設定することなく、柔軟にクラスターのサイズを変更する必要がある本番稼働用環境では特に重要です。

リーダーノードの IP アドレスの取得

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

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

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

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

クラスターの一時停止と再開

特定の時間帯にのみ使用可能にする必要があるクラスターがある場合は、そのクラスターを一時停止して後で再開することができます。クラスターが一時停止している間は、オンデマンド課金は一時停止されます。課金されるのは、クラスターのストレージのみです。料金の詳細については、Amazon Redshift 料金表を参照してください。

クラスターを一時停止すると、Amazon Redshift はスナップショットを作成し、クエリの終了を開始して、クラスターを一時停止状態にします。一時停止したクラスターを最終スナップショットをリクエストせずに削除した場合、そのクラスターを復元することはできません。一時停止または再開オペレーションは、開始後にキャンセルまたはロールバックすることはできません。

クラスターの一時停止と再起動は、Amazon Redshift コンソール、AWS CLI、または Amazon Redshift API オペレーションで行うことができます。

クラスターの一時停止と再開は、アクションをスケジュールして行うことができます。新しい Amazon Redshift コンソールを使用して一時停止と再開を行う定期的なスケジュールを作成すると、選択した日付範囲に対して 2 つのスケジュールされたアクションが作成されます。スケジュールされたアクションの名前には、末尾に -pause と -resume が付けられます。名前の合計の長さは、スケジュールされたアクション名の最大サイズに収まる必要があります。

次のタイプのクラスターは一時停止できません。

• EC2-Classic クラスター。

• アクティブではないクラスター (例: 現在変更中のクラスターなど)。

• ハードウェアセキュリティモジュール (HSM) クラスター。

• 自動スナップショットが無効になっているクラスター。

クラスターを一時停止する場合は、次の点を考慮してください。

• クラスターへの接続またはクエリは行えません。

• 一時停止したクラスターのクエリのモニタリング情報を Amazon Redshift コンソールに表示することはできません。

• 一時停止したクラスターを変更することはできません。クラスターでスケジュールされたアクションは実行されません。これには、スナップショットの作成、クラスターのサイズ変更、クラスターのメンテナンスなどのオペレーションが含まれます。

• ハードウェアのメトリクスは作成されません。作成されないメトリクスに CloudWatch のアラームを設定している場合は、アラームを更新してください。

• 一時停止したクラスターの最新の自動スナップショットを手動スナップショットにコピーすることはできません。

• クラスターが一時停止している間は、一時停止オペレーションが完了するまで再開することはできません。

• クラスターを一時停止すると、課金は一時停止されます。ただし、一時停止オペレーションは、クラスターのサイズに応じて通常 15 分以内に完了します。

• 監査ログはアーカイブされ、再開時には復元されません。

• クラスターを一時停止すると、一時停止前に発生した問題のトラブルシューティングにトレースとログが使用できなくなる場合があります。

• クラスター上のバックアップしないテーブルは、再開時に復元されません。バックアップしないテーブルの詳細については、「スナップショットのテーブルを除く」を参照してください。

クラスターを再開する場合は、次の点を考慮してください。

• 再開されたクラスターのクラスターバージョンは、クラスターのメンテナンスウィンドウに基づいてメンテナンスバージョンに更新されます。

• 一時停止したクラスターに関連付けられているサブネットを削除すると、互換性のないネットワークが存在することになる場合があります。その場合は、最新のスナップショットからクラスターを復元してください。

• クラスターの一時停止中に Elastic IP アドレスを削除すると、新しい Elastic IP アドレスを求められます。

• Amazon Redshift が前の Elastic Network Interface でクラスターを再開できない場合、Amazon Redshift は新しい Elastic Network Interface を割り当てようとします。

• クラスターを再開すると、ノードの IP アドレスが変更される場合があります。それらの新しい IP アドレスを Secure Shell (SSH) の COPY や Amazon EMR の COPY などの機能でサポートするように、VPC の設定を更新する必要がある場合があります。

• 一時停止していないクラスターを再開しようとすると、再開オペレーションはエラーを返します。再開オペレーションがスケジュールされたアクションの一部である場合は、今後のエラーを防ぐためにスケジュールされたアクションを変更または削除してください。

• クラスターのサイズによっては、クラスターを再開してクエリを処理できるようになるまでに数分かかる場合があります。また、再開の完了後にクラスターが元の状態に戻るまでは、クエリのパフォーマンスにある程度の時間影響がある場合があります。

クラスターの名前変更

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

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

注記

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

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

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

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

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

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

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

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

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