Amazon Redshift でのクラスター管理の概要 - Amazon Redshift
クラスターのサイズ変更クラスターの一時停止と再開クラスターの名前変更クラスターのシャットダウンと削除

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

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

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

データウェアハウスの容量やパフォーマンスのニーズを変更または拡大する場合、Amazon Redshift の提供するコンピューティングおよびストレージオプションを最大限に利用するためにクラスターのサイズを変更することができます。伸縮自在なサイズ変更を使用して、ノードのタイプと数を変更することで、クラスターをスケールすることができます。また、新しいノード構成で伸縮自在なサイズ変更を使用できない場合は、従来のサイズ変更を使用できます。

クラスターのサイズを変更するには、次のいずれかの方法を使用します。

  • 伸縮自在なサイズ変更 – ノードタイプ、ノードの数、またはその両方を変更するには、伸縮自在なサイズ変更を使用します。ノードの数のみを変更すると、クエリは一時的に停止され、可能であれば接続は開いたままになります。サイズ変更オペレーション中、クラスターは読み取り専用です。通常、伸縮自在なサイズ変更には 10～15 分かかります。可能な場合は、伸縮自在なサイズ変更を使用することをお勧めします。

  • 従来のサイズ変更 – ノードタイプ、ノードの数、またはその両方を変更するには、従来のサイズ変更を使用します。伸縮自在のサイズ変更では利用できない設定にサイズ変更する場合は、このオプションを選択します。1 つの例は、単一ノードクラスターへの接続または単一ノードクラスターからの接続です。サイズ変更オペレーション中、クラスターは読み取り専用です。通常、従来のサイズ変更には、データのサイズに応じて、2 時間～2 日間かかります。

  • スナップショットおよび従来のサイズ変更による復元 – クラスターのサイズ変更中にもクラスターを引き続き機能させるには、最初に既存のクラスターのコピーを作成してから、新しいクラスターをサイズ変更します。

クラスターのサイズ変更 (伸縮自在なサイズ変更と従来のサイズ変更の両方) は、スケジュールに基づいて行うことができます。新しい Amazon Redshift コンソールを使用すると、クラスターのサイズ変更を行うスケジュールを設定できます。詳細については、「クラスターのサイズ変更」を参照してください。また、AWS CLI または Amazon Redshift API のオペレーションを使用して、サイズ変更をスケジュールすることもできます。詳細については、AWS CLI Command Referenceの「create-scheduled-action」または Amazon Redshift API Referenceの「CreateScheduledAction」を参照してください。

伸縮自在なサイズ変更

伸縮自在なサイズ変更は、クラスターのサイズを変更する最速の方法です。伸縮自在なサイズ変更を使用して、既存のクラスターのノードを追加または削除し、ノードタイプを変更できます。

同じノードタイプで伸縮自在なサイズ変更を使用してクラスターのサイズを変更すると、新しいノードにデータを自動的に再分散します。このシナリオで新しいクラスターを作成しないため、伸縮自在なサイズ変更オペレーションは、素早く (通常は数分以内に) 完了します。バックグラウンドでデータが再分配されているとき、一部のクエリの実行時間がわずかに増加するのに気付くかも知れません。伸縮自在なサイズ変更オペレーションは、以下のステージで行われます。

  1. 伸縮自在なサイズ変更は、クラスターのスナップショットを作成します。

    伸縮自在なサイズ変更が作成するスナップショットには、バックアップしないテーブルが含まれています。自動スナップショットを無効にしているため、クラスターに最近のスナップショットがない場合、バックアップオペレーションには時間がかかります。サイズ変更オペレーションを開始する前の時間を最小限に抑えるため、自動スナップショットを有効にするか伸縮自在なサイズ変更を開始する前に手動スナップショットを作成することをお勧めします。詳細については、「Amazon Redshift スナップショット」を参照してください。

  2. 伸縮自在なサイズ変更がクラスターメタデータを移行している間、クラスターは一時的に使用できなくなります。

    このステージは非常に短く、長くても数分です。Amazon Redshift がセッション接続を保持し、クエリはキューに登録された状態を維持します。一部のセッションおよびクエリはタイムアウトする可能性があります。

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

  4. 伸縮自在なサイズ変更がバックグラウンドでノードスライスにデータを再分配します。

    クラスターは読み取り/書き込みオペレーションに使用できますが、一部のクエリの実行には時間がかかる可能性があります。

伸縮自在なサイズ変更を使用してクラスターのサイズを変更してノードタイプを変更すると、スナップショットが作成されます。スナップショットから最新のデータを使用して、新しいクラスターがプロビジョニングされます。データが新しいクラスターに転送されると、クラスターは一時的に書き込みできなくなります。これは、読み取りに使用できます。新しいクラスターにバックグラウンドで入力されます。新しいクラスターに完全に入力されると、クエリは最適なパフォーマンスになります。サイズ変更プロセスが完了間近になると、Amazon Redshift は新しいクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。

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

注記

Amazon Redshift 用の新しいコンソールが利用可能です。使用しているコンソールに基づき、[新しいコンソール] または [元のコンソール] の手順を選択します。新しいコンソールの手順はデフォルトで開いています。

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

Amazon Redshift コンソールを使用して伸縮自在なサイズ変更オペレーションの進捗状況をモニタリングするには、クラスターの詳細ページで、[ステータス] タブを選択します。

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

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

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

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

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

  • 新しいノード設定では、既存のデータに対して十分なストレージが必要です。ノードを追加するときでも、データが再分配される方法のために、新しい設定に十分なストレージがない場合があります。

  • dc2.large または ds2.xlarge ノードタイプの場合、元のクラスターのノード数のサイズを 2 倍にするか半分にすることができます。たとえば、4 ノードクラスターは伸縮自在なサイズ変更によって 8 ノードに増やすか、2 ノードに減らすことができます。別のノード数にサイズ変更するには、[従来のサイズ変更] を使用する必要があります。

  • dc2.8xlarge、ds2.8xlarge、ra3.4xlarge、または ra3.16xlarge ノードタイプの場合、ノード数を現在のノード数の半分から 2 倍にまで変更できます。たとえば、4 ノードクラスターは 2、3、5、6、7、または 8 ノードにサイズ変更できます。

注記

最大ノード制限をリセットするには、[従来のサイズ変更] を使用します。たとえば、4 ノードから 10 ノードに増やすには、まず従来のサイズ変更を使用して 5 ノードに変更します。

[従来のサイズ変更]

従来のサイズ変更オペレーションでは、データはコンピューティングノードまたはソースクラスターのノードから、コンピューティングノードまたはターゲットクラスターのノードに並列コピーされます。これに要する時間は、小さい方のクラスターにあるデータの量とノードの数によって異なります。数時間で終わることもあれば、2～3 日かかる可能性もあります。

サイズ変更オペレーションを開始すると、Amazon Redshift はサイズ変更が完了するまで、既存のクラスターを読み取り専用モードにします。この間、データベースから読み取るクエリのみを実行できます。読み取り/書き込みクエリを含め、データベースに書き込むクエリを実行することはできません。詳細については、Amazon Redshift Database Developer Guide の書き込みおよび読み取り/書き込み操作を参照してください。

注記

本番稼働環境への影響を最小限に抑えてサイズ変更するには、次の スナップショット、リストア、およびサイズ変更 セクションのステップを使用できます。これらのステップを使用して、クラスターのコピーを作成し、コピーのサイズを変更してサイズ変更を完了してから、接続のエンドポイントをサイズ変更したクラスターに切り替えます。

従来のサイズ変更の方法でもスナップショットと復元を使用する方法でも、新しいクラスターにユーザーのテーブルとデータをコピーします。システムテーブルおよびデータは保持されません。従来のサイズ変更またはスナップショットと復元では、ソースクラスターで監査ログを有効にしていた場合、Amazon S3 のログに引き続きアクセスできます。これらの方法では、ソースクラスターを削除した後でも、ログに引き続きアクセスできます。これらのログは、指定したデータポリシーに応じて保持または削除することができます。伸縮自在なサイズ変更では、システムログテーブルが保持されます。

Amazon Redshift によりソースクラスターが読み取り専用モードになった後、ターゲットクラスターである新しいクラスターをプロビジョンします。これは、ノードタイプ、クラスタータイプ、およびノードの数について指定する情報を使用して実行されます。次に Amazon Redshift はソースクラスターからターゲットクラスターにデータをコピーします。これが完了すると、すべての接続がターゲットクラスターを使用するように切り替わります。この切り替え時点で処理中のクエリがある場合、接続が失われるため、ターゲットクラスターでクエリを再起動する必要があります。サイズ変更の進行状況は、Amazon Redshift console で確認できます。

Amazon Redshift はサイズ変更オペレーション中にテーブルをソートしないため、既存のソート順序が維持されます。クラスターのサイズを変更すると、Amazon Redshift は分散スタイルに基づいてデータベーステーブルを新しいノードに分散し、ANALYZE コマンドを実行して統計を更新します。削除対象としてマークされた行は転送されないため、テーブルの再ソートが必要な場合のみ VACUUM コマンドを実行する必要があります。詳細については、 Amazon Redshift Database Developer Guide のテーブルのバキューム処理を参照してください。

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 は前述のプロセスの最後に移動されます。

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

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

クラスターのサイズ変更の詳細

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

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

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

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

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

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

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

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

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

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

クラスターがパブリックであり、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 アラームを、Amazon Redshift コンソールで Amazon SNS イベント通知を更新できます。クラスターのロードおよびクエリデータには、名前変更前と名前変更後のデータが引き続き表示されます。ただし、パフォーマンスデータは、名前変更プロセスの完了後にリセットされます。

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

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

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

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

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