クラスターのサイズ変更クラスターの一時停止と再開クラスターの名前変更クラスターのシャットダウンと削除

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

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

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

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

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

伸縮自在なサイズ変更 - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードなど、ノードタイプを変更することもできます。伸縮自在なサイズ変更はすばやい操作で、通常は数分で完了します。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。
- 既存のクラスターにノードを追加または削減するが、ノードタイプは変更しない場合 - これは一般的にインプレースサイズ変更と呼ばれます。このタイプのサイズ変更を実行すると、実行中のクエリの一部は正常に完了しますが、他のクエリは操作の一部として破棄される場合があります。伸縮自在なサイズ変更は数分で完了します。
- クラスターのノードタイプの変更 - ノードタイプを変更すると、スナップショットが作成されて、ソースクラスターから新しいノードタイプで構成されるクラスターにデータが再分配されます。完了すると、実行中のクエリは破棄されます。インプレースのサイズ変更のように、すぐに完了します。
従来のサイズ変更 - ノードタイプ、ノード数、またはその両方を、伸縮自在なサイズ変更と同様に変更できます。従来のサイズ変更は完了するまでに時間がかかりますが、ノード数の変更または移行先のノードタイプが、伸縮自在なサイズ変更の範囲内に収まらない場合は便利です。例えば、ノード数の変更が非常に大規模な場合に当てはまります。

伸縮自在なサイズ変更

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

伸縮自在なサイズ変更は、クラスターのスナップショットを作成します。該当する場合、このスナップショットには常にノード用にバックアップしないテーブルが含まれています。(RA3 など、一部のノードタイプには、バックアップしないテーブルがありません。) 自動スナップショットを無効にしているため、クラスターに最近のスナップショットがない場合、バックアップオペレーションに時間がかかることがあります。(サイズ変更操作を開始する前の時間を最小限に抑えるため、自動スナップショットを有効にするか、サイズ変更を開始する前に手動スナップショットを作成することをお勧めします。) 伸縮自在なサイズ変更を開始し、スナップショット操作が現在進行中の場合、スナップショット操作が数分以内に完了しないと、伸縮自在なサイズ変更が失敗することがあります。詳細については、「Amazon Redshift スナップショットとバックアップ」を参照してください。
このオペレーションはクラスターのメタデータを移行します。クラスターは数分間使用できません。クエリの大部分は一時的に停止され、接続は開いた状態になります。ただし、一部のクエリは削除される可能性があります。この段階は短い。
セッション接続が回復し、クエリが再開します。
伸縮自在なサイズ変更は、バックグラウンドでノードスライスにデータを再分配します。クラスターは読み取りと書き込み操作に利用できますが、一部のクエリは実行に時間がかかる可能性があります。
操作が完了すると、Amazon Redshift はイベント通知を送信します。

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

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

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

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

伸縮自在なサイズ変更とデータ共有クラスター - データ共有のプロデューサーであるクラスターでノードを追加または削除すると、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

注記

RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択 — RA3 ノードを含むクラスターから別のノードタイプ（DC2 や DS2 など）にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。

[従来のサイズ変更]

伸縮自在なサイズ変更でサポートされないクラスターサイズやノードタイプの変更が伴うユースケースは、従来のサイズ変更で処理します。従来のサイズ変更を実行すると、Amazon Redshift はターゲットクラスターを作成し、データとメタデータをソースクラスターからそのクラスターに移行します。

RA3 への従来のサイズ変更では、可用性が向上します

ターゲットノードタイプが RA3 の場合、従来のサイズ変更が強化されています。これを行うために、ソースとターゲットのクラスター間でバックアップと復元オペレーションを利用します。サイズ変更が始まると、ソースクラスターが再起動し、数分間使用できなくなります。その後、クラスターは読み取りおよび書き込みオペレーションで使用可能になり、サイズ変更はバックグラウンドで続行します。

クラスターの確認

RA3 クラスターへの従来のサイズ変更を実行したときに最高のパフォーマンスと結果を得るには、次のチェックリストを完了します。チェックリストに従わないと、読み取りまたは書き込みオペレーションの実行など、RA3 ノードでの従来のサイズ変更のメリットの一部が得られない場合があります。

データのサイズは 400 TB 未満でなければなりません。データのサイズを検証するには、スナップショットを作成してそのサイズを確認します。次のクエリを実行してサイズを確認することもできます。
```
SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;
```
svv_table_info テーブルはスーパーユーザーにのみ表示されます。
ターゲットクラスターのノードタイプは RA3 である必要があり、ターゲットクラスターには少なくとも 2 つのノードが必要です。ターゲットノードタイプが RA3 であっても、シングルノードクラスターへの従来のサイズ変更は長引く場合があります。
従来のサイズ変更を開始する前に、10 時間以内の手動スナップショットがあることを確認してください。存在しない場合は、スナップショットを作成します。
従来のサイズ変更の実行に使用したスナップショットは、テーブルの復元やその他の目的には使用できません。
クラスターは VPC 内にある必要があります。

RA3 への従来のサイズ変更によるソートおよび分散オペレーション

RA3 への従来のサイズ変更中に、均等分散として移行された分散キーテーブルは、バックグラウンドのオペレーションを使用して元の分散スタイルに戻されます。この期間は、データのサイズとクラスターの負荷状況によって異なります。クエリワークロードは、データ移行よりも実行が優先されます。詳細については、「分配スタイル」を参照してください。この移行プロセス中は、データベースの読み取りと書き込みの両方が機能しますが、クエリパフォーマンスが低下する可能性があります。ただし、同時実行スケーリングでは、クエリワークロード用のリソースを追加することでパフォーマンスを向上させることができます。svl_restore_alter_table_progress ビューの結果を使用して、データ移行の進捗状況を確認できます。モニタリングの詳細については、以下を参照してください。

クラスターのサイズが完全に変更されると、次のソート動作が発生します。

サイズ変更によってクラスターのスライス数が増えると、KEY 分散テーブルは部分的にソートされなくなりますが、EVEN テーブルはソートされたままになります。また、ソートされたデータの量に関する情報は、サイズ変更の直後は最新でない可能性があります。キーの回復後、自動バキュームによってテーブルが時間の経過とともにソートされます。
サイズ変更によってクラスターのスライス数が少なくなると、KEY 分散テーブルと EVEN 分散テーブルの両方が部分的にソートされなくなります。自動バキュームにより、テーブルが時間の経過とともにソートされます。

テーブルの自動バキュームの詳細については、「テーブルのバキューム処理」を参照してください。コンピューティングノードのスライスの詳細については、「データウェアハウスシステムアーキテクチャ」を参照してください。

ターゲットクラスターが RA3 である場合の従来のサイズ変更手順

従来のサイズ変更は、ターゲットクラスタータイプが RA3 で、前のセクションで説明した前提条件を満たしている場合、次の手順で構成されます。

ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。

BACKUP NO で作成したテーブルやマテリアライズドビューなどのデータベースリレーションは、従来のサイズ変更では保持されないことに注意してください。詳細については、「REFRESH MATERIALIZED VIEW」を参照してください。
再起動後、データベースは読み取りと書き込みが可能になります。さらに、データ共有が再開されます。これにはさらに数分かかります。
データがターゲットクラスターに移行されます。ターゲットノードタイプが RA3 の場合、データ移行中に読み取りと書き込みが可能です。
サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。
サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。

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

注記

RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択 — RA3 ノードを含むクラスターから別のノードタイプ (DC2 や DS2 など) にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。

ターゲットクラスターが RA3 である場合の従来のサイズ変更のモニタリング

進行中のプロビジョニングされたクラスターの従来のサイズ変更 (KEY 分散を含む) をモニタリングするには、svl_restore_alter_table_progress を使用します。変換中のテーブルの完了率が表示されます。データにアクセスするには、スーパーユーザーである必要があります。サンプルクエリを以下に示します。


select * from svl_restore_alter_table_progress;

結果は次のとおりです。


  tbl   | progress |                          message                          
--------+----------+-----------------------------------------------------------
 105614 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105610 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105594 | 0.00%    | Table waiting for alter diststyle conversion.
 105602 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105606 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105598 | 100.00%  | Restored to distkey successfully.

従来のサイズ変更を実行するときに不要なテーブルを削除します。これを行うと、既存のテーブルをより迅速に分散できます。

ターゲットクラスターが RA3 でない場合の従来のサイズ変更手順

ターゲットノードタイプが RA3 以外 (DS2 など) である場合、従来のサイズ変更は次の手順で構成されます。

ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。

BACKUP NO で作成したテーブルやマテリアライズドビューなどのデータベースリレーションは、従来のサイズ変更では保持されないことに注意してください。詳細については、「CREATE MATERIALIZED VIEW」を参照してください。
再起動後、データベースは読み取り専用になります。データ共有が再開されます。これにはさらに数分かかります。
データがターゲットクラスターに移行されます。データベースは読み取り専用のままです。
サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。
サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。

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

注記

ターゲットクラスターが RA3 でない場合、または前のセクションで説明した RA3 ターゲットクラスターの前提条件を満たしていない場合、大量のデータを含むクラスターのサイズを変更するには、数日または場合によっては数週間かかることがあります。

また、クラスターの使用済みストレージ容量は、従来のサイズ変更後に増加する可能性があることにも注意してください。これは、従来のサイズ変更の結果としてクラスターにデータスライスが追加された場合、通常のシステム動作です。クラスター内のノード数が同じままでも、こうした追加容量の使用が発生する場合があります。

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

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

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

サイズ変更のスケジューリング

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

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

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

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

既存のクラスターのスナップショットを作成します。既存のクラスターがソースクラスターです。
スナップショットを作成した時刻を記録します。そうすることで、スナップショット後のデータをターゲットデータベースにロードするための抽出、処理、ロード (ETL) プロセスを再実行する必要がある時点を識別できるようにします。
新しいクラスターにスナップショットを復元します。この新しいクラスターがターゲットクラスターです。サンプルデータがターゲットクラスターにあることを確認します。
ターゲットクラスターのサイズを変更します。ターゲットクラスターに関して、新しいノードタイプ、ノード数、その他の設定を選択します。
ソースクラスターのスナップショット作成後に発生した ETL プロセスでロードされたデータを確認します。ターゲットクラスターには、同じデータを同じ順序で再ロードしてください。進行中のデータロードがある場合、ソースクラスターとターゲットクラスターのデータが同じになるまで、このプロセスを数回繰り返します。
ソースクラスターで実行中のすべてのクエリを停止します。これを行うには、クラスターを再起動するか、スーパーユーザーとしてログオンし、PG_CANCEL_BACKEND コマンドおよび PG_TERMINATE_BACKEND コマンドを使用できます。クラスターを再起動すると、クラスターが使用できないことを最も簡単に確認できます。
ソースクラスター名を変更します。たとえば、examplecluster から examplecluster-source に変更します。
変更前のソースクラスター名を使用して、ターゲットクラスターの名前を変更します。たとえば、ターゲットクラスターの名前を examplecluster に変更します。これ以降、examplecluster を含むエンドポイントを使用するアプリケーションは、ターゲットクラスターに接続します。
ターゲットクラスターに切り替えた後、ソースクラスターを削除し、すべてのプロセスが期待どおりに動作することを確認します。

または、データをターゲットクラスターに再ロードする前にソースとターゲットクラスターの名前を変更することもできます。このアプローチは、依存するシステムやレポートをすぐに最新状態にしてターゲットクラスターに反映する必要がない場合に有効です。この場合、ステップ 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 の料金表ページを参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

クラスター

使用制限の管理