Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# クラスターオペレーション
クラスターを作成したら、クラスターオペレーションを実行してパフォーマンスを最適化し、コストを制御し、高可用性を確保できます。クラスターオペレーションを使用すると、データウェアハウスのニーズの変化に応じて、クラスターのサイズ変更、一時停止、再開、または再作成を行うことができます。
一般的なユースケースには、ピークワークロードのコンピューティングキャパシティのスケーリング、非アクティブ期間中にクラスターを一時停止してコストを削減する、ディザスタリカバリのために異なる設定または異なるアベイラビリティーゾーンでクラスターを再作成するなどがあります。以下のセクションでは、Amazon Redshift 環境を効果的に管理するために、さまざまなクラスターオペレーションを実行する方法の詳細について説明します。
# クラスターの作成
Amazon Redshift を使用すると、プロビジョニングされたクラスターを作成して新しいデータウェアハウスを起動できます。プロビジョニングされたクラスターは、ノードと呼ばれるコンピューティングリソースのコレクションであり、単一の超並列処理 (MPP) システムに編成されています。
クラスターを作成する前に、「[Amazon Redshift でプロビジョニングされたクラスター](working-with-clusters.md)」および「[Amazon Redshift のクラスターとノード](working-with-clusters.md#rs-about-clusters-and-nodes)」を参照してください。
**クラスターを作成するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。現在のAWSリージョンにあるアカウントのクラスターがリストされています。各クラスターのプロパティのサブセットが、リストの列に表示されます。
1. **[クラスターを作成]** を選択して、クラスターを作成します。
1. コンソールページの指示に従って **[クラスター設定]** のプロパティを入力します。
以下のステップでは、RA3 ノードタイプをサポートする AWS リージョン で実行されている、Amazon Redshift コンソールについて説明します。RA3 ノードタイプをサポートする AWS リージョン のリストについては、*Amazon Redshift 管理ガイド*の「[RA3 ノードタイプの概要](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-ra3-node-types)」を参照してください。
クラスターのサイズがわからない場合は、**[選択のヘルプ]** を選んでください。これにより、データウェアハウスに保存する予定のデータのサイズとクエリの特性について質問するサイジング計算ツールが起動されます。クラスターの必須サイズ (ノードタイプとノード数) がわかっている場合は、[**I'll choose (選択する)**] を選んでください。次に、**ノードの種類**と**ノード**の数量を選択して、概念実証のためにクラスターのサイズを設定します。
**注記**
組織が適格であり、Amazon Redshift Serverless が利用できない AWS リージョン でクラスターが作成されている場合、Amazon Redshift 無料トライアルプログラムでクラスターを作成できる場合があります。**[このクラスターを何に使用する予定ですか?]** という質問に対して、**[本番稼働用]** または **[無料トライアル]** のいずれかを選択します。**[無料トライアル]** を選択したときには、dc2.large ノードタイプの設定を作成します。無料トライアルの選択に関する詳細については、「[Amazon Redshift 無料トライアル](https://aws.amazon.com/redshift/free-trial/)」を参照してください。Amazon Redshift Serverless が利用可能な AWS リージョン の一覧については、*Amazon Web Services 全般のリファレンス*の「[Redshift Serverless API](https://docs.aws.amazon.com/general/latest/gr/redshift-service.html)」に記載されているエンドポイントを参照してください。
1. **[データベース設定]** セクションで、**[管理者ユーザー名]** の値を指定します。**[管理者パスワード]** では、以下のオプションの中から選択します。
+ **[パスワードの生成]** – Amazon Redshift によって生成されたパスワードを使用します。
+ **[管理者パスワードを手動で追加する]** – 独自のパスワードを使用します。
+ **[AWS Secrets Manager での管理者認証情報の管理]** – Amazon Redshift は管理者パスワードの生成と管理に AWS Secrets Manager を使用します。AWS Secrets Manager を使用してパスワードのシークレットの生成と管理を行うには料金がかかります。AWS Secrets Manager の料金の詳細については、「[AWS Secrets Manager の料金](https://aws.amazon.com/secrets-manager/pricing/)」を参照してください。
1. (オプション) コンソールページの指示に従って [**Cluster permission (クラスタのアクセス許可)**] のプロパティを入力します。Amazon S3 からデータをロードするなど、クラスターが他の AWS のサービスにアクセスする必要がある場合は、クラスターのアクセス許可を付与します。
1. **[クラスターを作成]** を選択して、クラスターを作成します。クラスターの使用準備ができるまで、数分かかることがあります。
## 追加の設定
クラスターを作成する際、追加のプロパティを指定してカスタマイズを行うことができます。これらのプロパティに関する詳細は、次のリストを参照してください。
**IP アドレスタイプ**
クラスターの IP アドレスタイプを選択します。リソースを IPv4 アドレスプロトコルでのみ通信させるか、IPv4 と IPv6 の両方でリソースを通信させるデュアルスタックモードを選択できます。この機能は、AWS GovCloud (米国東部) および AWS GovCloud (米国西部) の各リージョンでのみ利用可能です。AWS リージョンの詳細については、「[リージョンとアベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)」を参照してください。
**仮想プライベートクラウド (VPC)**
クラスターサブネットグループを持つ VPC を選択します。クラスターの作成後は、クラスターサブネットグループを変更することはできません。
**パラメータグループ**
クラスターに関連付けるパラメータグループを選択します。選択しない場合、デフォルトのパラメータグループが使用されます。
**暗号化**
クラスターとスナップショット内のデータをすべて暗号化するかどうかを選択します。デフォルト設定の [**なし**] のままにしておくと、暗号化は有効になりません。暗号化を有効にする場合は、AWS Key Management Service (AWS KMS) またはハードウェアセキュリティモジュール (HSM) のどちらを使用するか選択して、関連する設定を指定します。Amazon Redshift の暗号化の詳細については、[Amazon Redshift データベース暗号化](working-with-db-encryption.md) を参照してください。
+ **KMS**
暗号化を有効にして、AWS KMS を使用して暗号化キーを管理する場合は **[AWS Key Management Service (AWS KMS) の使用]** を選択します。また、使用するキーを選択します。デフォルトキー、現在のアカウントのキー、別のアカウントのキーを選択できます。
**注記**
別の AWS アカウントのキーを使用する場合、使用するキーの Amazon リソースネーム (ARN) を入力します。キーを使用するアクセス権限が必要です。AWS KMS でのキーアクセスの詳細については、*AWS Key Management Service デベロッパーガイド*の「[Controlling access to your keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html)」を参照してください。
Amazon Redshift での AWS KMS 暗号化キーの使用についての詳細は、「[AWS KMS を使用した暗号化](working-with-db-encryption.md#working-with-aws-kms)」を参照してください。
+ **HSM**
暗号化を有効にし、ハードウェアセキュリティモジュール (HSM) を使用して暗号化キーを管理する場合は、[**HSM**] を選択します。
[**HSM**] を選択した場合は、[**HSM 接続**] と [**HSM クライアント証明書**] から値を選択します。これらの値は、Amazon Redshift と HSM がクラスターキーを渡すことができる信頼された接続を確立するために必要です。HSM 接続とクライアント証明書は、クラスターを起動する前に Amazon Redshift でセットアップする必要があります。HSM 接続とクライアント証明書のセットアップの詳細については、「[ハードウェアセキュリティモジュールを使用した暗号化](working-with-db-encryption.md#working-with-HSM)」を参照してください。
**メンテナンストラック**
使用するクラスターバージョンが、**現行**、**末尾**、または場合によっては**プレビュー**トラックのいずれかを選択できます。
**モニタリング**
CloudWatch アラームを作成するかどうかを選択できます。
**クロスリージョンスナップショットを設定する**
クロスリージョンスナップショットを有効化するかどうかを選択できます。
**自動スナップショットの保持期間**
これらのスナップショットを保持する日数 (35 日以内) を選択できます。ノードタイプが DC2 の場合、自動スナップショットを作成しないようにするため、ゼロ (0) 日を選択できます。
**手動スナップショット保持期間**
これらのスナップショットを保持する日数または `Indefinitely` を選択できます。
**自動最適化のための追加のコンピューティングリソース**
使用量が多い期間でも、自動最適化を実行するための追加のコンピューティングリソースを割り当てるかどうかを選択できます。詳細については、「*Amazon Redshift データベースデベロッパーガイド*」の「[データベースの自動最適化のための追加のコンピューティングリソースの割り当て](https://docs.aws.amazon.com/redshift/latest/dg/t_extra-compute-autonomics.html)」を参照してください。
# ディスク容量アラームの作成
ディスク容量の使用状況をモニタリングし、ディスク容量がクラスターの指定されたしきい値を超えたときに通知されるアラームを設定できます。ディスク容量使用状況アラームを作成すると、ストレージ容量をプロアクティブに管理し、クエリの失敗やデータインジェストエラーなど、ディスク容量不足による問題を防ぐことができます。次の手順では、ディスク容量使用量アラームを作成するプロセスについて説明します。
**クラスターのディスク容量使用アラームを作成するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[Alarms]** (アラーム) を選択します。
1. [**アクション**] で [**アラームの作成**] を選択します。[**アラームの作成**] ページが表示されます。
1. ページに表示された手順に従います。
1. [**アラームの作成**] を選択します。
# クラスターの表示
クラスターを表示すると、クラスターの設定、ステータス、パフォーマンスメトリクスをモニタリングおよび管理できます。クラスターの詳細を表示することで、リソース使用率、クエリ実行時間、システムの状態に関するインサイトを得ることができます。次の手順では、クラスターの情報にアクセスする方法を示します。
**クラスターを表示するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。現在のAWSリージョンにあるアカウントのクラスターがリストされています。各クラスターのプロパティのサブセットが、リストの列に表示されます。クラスターがない場合、[**クラスターを作成**] を選択して作成します。
1. リストでクラスター名を選択して、クラスターの詳細を表示します。
# クラスターの変更
クラスターを変更すると、以下のオプションに対する変更が直ちに適用されます。
+ **VPC セキュリティグループ**
+ **パブリックアクセス可能**
+ **管理者ユーザーパスワード**
+ **HSM 接続**
+ **HSM Client Certificate**
+ **メンテナンスの詳細**
+ **スナップショット設定**
以下のオプションに対する変更は、クラスターを再起動した後に限り、有効になります。
+ **クラスター識別子**
**クラスター識別子**を変更すると、Amazon Redshift はクラスターを自動的に再起動します。
+ **拡張された VPC のルーティング**
**拡張 VPC ルーティング**を変更すると、Amazon Redshift はクラスターを自動的に再起動します。
+ **クラスターパラメータグループ**
+ **IP アドレスタイプ**
この機能は、AWS GovCloud (米国東部) および AWS GovCloud (米国西部) の各リージョンでのみ利用可能です。AWS リージョンの詳細については、「[リージョンとアベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)」を参照してください。
自動作成されたスナップショットの保持期間を短縮すると、新しい保持期間に含まれなくなった、既存の自動作成されたスナップショットは削除されます。詳細については、「[Amazon Redshift スナップショットとバックアップ](working-with-snapshots.md)」を参照してください。
クラスタープロパティの詳細については、「[追加の設定](create-cluster.md#cluster-create-console-configuration)」を参照してください。
**クラスターを変更するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. 変更するクラスターを選択します。
1. [**Edit**] を選択します。**[Edit cluster]** (クラスターの編集) ページが表示されます。
1. クラスターのプロパティを更新します。変更できるプロパティには、次のものがあります。
+ クラスター識別子
+ スナップショット保持期限
+ クラスターの再配置
**ネットワークとセキュリティ**、**メンテナンス**、および**データベース構成**の設定を編集するために、コンソールには適切なクラスターの詳細タブへのリンクが付いています。
1. **[変更を保存]** をクリックします。
# クラスターのサイズ変更
データウェアハウスの容量とパフォーマンスのニーズが変わるため、クラスターサイズを変更して、Amazon Redshift のコンピューティングとストレージオプションを最大限に活用することができます。
クラスターのサイズを変更する場合、クラスターの現在の設定と異なっているノード数またはノードタイプを指定します。クラスターのサイズ変更処理が実行中の間は、クラスターに対する書き込みクエリまたは読み取り/書き込みクエリは実行できません。読み込みクエリのみ実行できます。
さまざまな方法を使用してクラスターのサイズを変更するチュートリアルも含めて、クラスターのサイズ変更方法の詳細については、「[クラスターのサイズ変更](#resizing-cluster)」を参照してください。
**クラスターのサイズを変更するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. サイズを変更するクラスターを選択します。
1. [**アクション**] で、[**サイズ変更**] を選択します。[**クラスターのサイズ変更**] ページが表示されます。
1. ページに表示された手順に従います。クラスターのサイズ変更は、特定の時刻に 1 回行うことも、スケジュールに従ってクラスターのサイズを増減することもできます。
1. 選択に応じて、[**Resize now (今すぐサイズ変更)**] または [**Schedule resize (サイズ変更のスケジュール)**] を選択します。
リザーブドノードがある場合は、RA3 リザーブドノードにアップグレードできます。このアップグレードは、コンソールを使用してスナップショットからの復元を実行する場合や、伸縮自在なリサイズを実行する際に利用できます。コンソールを使用している場合は、このプロセスに関するガイドが提供されます。RA3 ノードへのアップグレードの詳細については、「[RA3 ノードタイプへのアップグレード](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3)」を参照してください。
サイズ変更オペレーションを実行して DC2.large ノードタイプから RA3.large ノードタイプにアップグレードすると、Amazon Redshift は自動的にインターリーブソートキーを複合ソートキーに変換します。この変換により、同時実行スケーリング機能にアクセスできます。この機能は、インターリーブソートキーを持つテーブルに対するクエリをサポートしていません。この自動変換により RA3 機能との互換性は保証されますが、既存のクエリパフォーマンスパターンに影響する可能性があります。
RA3 ノードにアップグレード後にインターリーブソートキーを維持する場合は、サイズ変更オペレーションの完了後に、必要なソートキー設定でテーブルを再作成できます。ただし、このオプションを選択すると、これらのテーブルで同時実行スケーリングを使用することはできません。
サイズ変更操作には次の 2 つのタイプがあります。
+ **伸縮自在なサイズ変更** - クラスターにノードを追加または削除できます。DS2 ノードから RA3 ノードへの変更など、ノードタイプを変更することもできます。伸縮自在なサイズ変更は、通常は短時間で完了し、平均で 10 分かかります。このため、最初のオプションとしてお勧めします。伸縮自在なサイズ変更を実行すると、データスライスを再分配します。データスライスは、各ノードにメモリとディスク領域に割り当てられるパーティションです。伸縮自在なサイズ変更は、次のような場合に適しています。
+ *既存のクラスターにノードを追加または削減するが、ノードタイプは変更しない場合* - これは一般的に*インプレース*サイズ変更と呼ばれます。このタイプのサイズ変更を実行すると、実行中のクエリの一部は正常に完了しますが、他のクエリは操作の一部として破棄される場合があります。
+ *クラスターのノードタイプの変更* - ノードタイプを変更すると、スナップショットが作成されて、ソースクラスターから新しいノードタイプで構成されるクラスターにデータが再分配されます。完了すると、実行中のクエリは破棄されます。*インプレース*のサイズ変更のように、すぐに完了します。
+ **従来のサイズ変更** - ノードタイプ、ノード数、またはその両方を、伸縮自在なサイズ変更と同様に変更できます。従来のサイズ変更は完了するまでに時間がかかりますが、ノード数の変更または移行先のノードタイプが、伸縮自在なサイズ変更の範囲内に収まらない場合は便利です。例えば、ノード数の変更が非常に大規模な場合に当てはまります。
**Topics**
+ [伸縮自在なサイズ変更](#elastic-resize)
+ [従来のサイズ変更](#classic-resize-faster)
## 伸縮自在なサイズ変更
同じタイプのノードを追加または削除する場合、伸縮自在なサイズ変更操作には、次の段階があります。
1. 伸縮自在なサイズ変更は、クラスターのスナップショットを作成します。バックアップ用ではないテーブルは DC2 ノードでのみサポートされます。他のすべてのタイプのクラスターでは、バックアップ用ではないテーブルはスナップショットに含まれます。詳細については、「[スナップショットのテーブルを除く](working-with-snapshots.md#snapshots-no-backup-tables)」を参照してください。自動スナップショットを無効にしているため、クラスターに最近のスナップショットがない場合、バックアップオペレーションに時間がかかることがあります。(サイズ変更操作を開始する前の時間を最小限に抑えるため、自動スナップショットを有効にするか、サイズ変更を開始する前に手動スナップショットを作成することをお勧めします。) 伸縮自在なサイズ変更を開始し、スナップショット操作が現在進行中の場合、スナップショット操作が数分以内に完了しないと、伸縮自在なサイズ変更が失敗することがあります。詳細については、「[Amazon Redshift スナップショットとバックアップ](working-with-snapshots.md)」を参照してください。
1. このオペレーションはクラスターのメタデータを移行します。クラスターは数分間使用できません。クエリの大部分は一時的に停止され、接続は開いた状態になります。ただし、一部のクエリは削除される可能性があります。この段階は短い。
1. セッション接続が回復し、クエリが再開します。
1. 伸縮自在なサイズ変更は、バックグラウンドでノードスライスにデータを再分配します。クラスターは読み取りと書き込み操作に利用できますが、一部のクエリは実行に時間がかかる可能性があります。
1. 操作が完了すると、Amazon Redshift はイベント通知を送信します。
伸縮自在なサイズ変更を使用してノードタイプを変更する操作は、同じタイプのノードを追加または削除する操作と似ています。まず、スナップショットが作成されます。新しいターゲットクラスターはスナップショットの最新データでプロビジョニングされ、データはバックグラウンドの新しいクラスターに転送されます。この期間中、データは読み取りのみ可能です。サイズ変更が完了間近になると、Amazon Redshift はエンドポイントを更新して新しいクラスターを指し、ソースクラスターへのすべての接続が破棄されます。
伸縮自在なサイズ変更が失敗することはまずありません。ただし、障害が発生した場合、ほとんどのケースでロールバックが自動的に行われ、手動による介入は必要ありません。
リザーブドノード (DS2 リザーブドノードなど) がある場合、サイズ変更を実行する際に RA3 リザーブドノードにアップグレードできます。このアップグレードは、伸縮自在なリサイズを実行するか、コンソールを使用してスナップショットからの復元を実行するときに使用できます。このコンソールは、このプロセスについて説明します。RA3 ノードへのアップグレードの詳細については、「[RA3 ノードタイプへのアップグレード](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3)」を参照してください。
伸縮自在なサイズ変更は、テーブルをソートしたり、ディスク容量を解放したりしないため、バキュームオペレーションに代わるものではありません。詳細については、「[テーブルのバキューム処理](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html)」を参照してください。
伸縮自在なサイズ変更には以下の制約があります。
+ *伸縮自在なサイズ変更とデータ共有クラスター* - データ共有のプロデューサーであるクラスターでノードを追加または削除すると、Amazon Redshift がクラスターメタデータを移行している間、コンシューマーから接続できません。同様に、伸縮自在なサイズ変更を実行して新しいノードタイプを選択した場合、接続がドロップされ、新しいターゲットクラスターに転送される間、データ共有は利用できません。どちらのタイプの伸縮自在なサイズ変更でも、プロデューサーは数分間利用できません。
+ *共有スナップショットからのデータ転送* - 共有スナップショットからデータを転送しているクラスターで伸縮自在なサイズ変更を実行するには、クラスターで少なくとも 1 つのバックアップを使用できる必要があります。バックアップは、Amazon Redshift コンソールのスナップショットのリスト、`describe-cluster-snapshots` CLI コマンド、または `DescribeClusterSnapshots` API オペレーションで表示できます。
+ *プラットフォーム制限* - 伸縮自在なサイズ変更は、EC2-VPC プラットフォームを使用するクラスターでのみ利用できます。詳細については、「[EC2 を使用してクラスターを作成する](working-with-clusters.md#cluster-platforms)」を参照してください。
+ *ストレージの考慮事項* - 新しいノード設定では、既存データに十分なストレージを確保する必要があります。ノードの追加または設定の変更が必要な場合があります。
+ *ソース vs ターゲットクラスターサイズ* - 伸縮自在なサイズ変更によってサイズ変更可能なノード数と種類は、ソースクラスターのノード数と、サイズ変更したクラスター用に選択されたノードタイプによって決まります。使用可能な設定を確認するには、コンソールを使用します。また、`action-type resize-cluster` オプションで `describe-node-configuration-options` AWS CLI コマンドを使用することもできます。Amazon Redshift コンソールを使用したメタデータの編集の詳細については、[クラスターのサイズ変更](#resizing-cluster) を参照してください。
次の 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 ノードに、または最小値を超えた値に減らすことができます。
次の表は、伸縮自在なサイズ変更がサポートされている各ノードタイプの増加の制限値と削減の制限値を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/resizing-cluster.html)
**注記**
**RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択** — RA3 ノードを含むクラスターから別のノードタイプ (DC2 など) にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。
## 従来のサイズ変更
伸縮自在なサイズ変更でサポートされないクラスターサイズやノードタイプの変更が伴うユースケースは、従来のサイズ変更で処理します。従来のサイズ変更を実行すると、Amazon Redshift はターゲットクラスターを作成し、データとメタデータをソースクラスターからそのクラスターに移行します。
### RA3 への従来のサイズ変更では、可用性が向上します
ターゲットノードタイプが RA3 の場合、従来のサイズ変更が強化されています。これを行うために、ソースとターゲットのクラスター間でバックアップと復元オペレーションを利用します。サイズ変更が始まると、ソースクラスターが再起動し、数分間使用できなくなります。その後、クラスターは読み取りおよび書き込みオペレーションで使用可能になり、サイズ変更はバックグラウンドで続行します。
#### クラスターの確認
RA3 クラスターへの従来のサイズ変更を実行したときに最高のパフォーマンスと結果を得るには、次のチェックリストを完了します。チェックリストに従わないと、読み取りまたは書き込みオペレーションの実行など、RA3 ノードでの従来のサイズ変更のメリットの一部が得られない場合があります。
1. データのサイズは 2 ペタバイト未満でなければなりません。(1 ペタバイトは 1,000 テラバイトに相当します)。データのサイズを検証するには、スナップショットを作成してそのサイズを確認します。次のクエリを実行してサイズを確認することもできます。
```
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` テーブルはスーパーユーザーにのみ表示されます。
1. 従来のサイズ変更を開始する前に、10 時間以内の手動スナップショットがあることを確認してください。存在しない場合は、スナップショットを作成します。
1. 従来のサイズ変更の実行に使用したスナップショットは、テーブルの復元やその他の目的には使用できません。
1. クラスターは VPC 内にある必要があります。
#### RA3 への従来のサイズ変更によるソートおよび分散オペレーション
RA3 への従来のサイズ変更中に、EVEN 分散として移行された分キー分散のあるテーブルは、元の分散スタイルに戻されます。この期間は、データのサイズとクラスターの負荷状況によって異なります。クエリワークロードは、データ移行よりも実行が優先されます。詳細については、「[分配スタイル](https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html)」を参照してください。この移行プロセス中は、データベースの読み取りと書き込みの両方が機能しますが、クエリが完了するまでに時間がかかることがあります。ただし、同時実行スケーリングでは、クエリワークロード用のリソースを追加することでこの間にパフォーマンスを向上させることができます。[SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) ビューと [SYS\$1RESTORE\$1LOG](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_LOG.html) ビューの結果を表示することで、データ移行の進行状況を確認できます。モニタリングの詳細については、以下を参照してください。
クラスターのサイズが完全に変更されると、次のソート動作が発生します。
+ サイズ変更によってクラスターのスライス数が増えると、KEY 分散テーブルは部分的にソートされなくなりますが、EVEN テーブルはソートされたままになります。また、ソートされたデータの量に関する情報は、サイズ変更の直後は最新でない可能性があります。キーの回復後、自動バキュームによってテーブルが時間の経過とともにソートされます。
+ サイズ変更によってクラスターのスライス数が少なくなると、KEY 分散テーブルと EVEN 分散テーブルの両方が部分的にソートされなくなります。自動バキュームにより、テーブルが時間の経過とともにソートされます。
テーブルの自動バキュームの詳細については、「[テーブルのバキューム処理](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html)」を参照してください。コンピューティングノードのスライスの詳細については、「[データウェアハウスシステムアーキテクチャ](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html)」を参照してください。
#### ターゲットクラスターが RA3 である場合の従来のサイズ変更手順
従来のサイズ変更は、ターゲットクラスタータイプが RA3 で、前のセクションで説明した前提条件を満たしている場合、次の手順で構成されます。
1. ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。
1. 再起動後、データベースは読み取りと書き込みが可能になります。さらに、データ共有が再開されます。これにはさらに数分かかります。
1. データがターゲットクラスターに移行されます。ターゲットノードタイプが RA3 の場合、データ移行中に読み取りと書き込みが可能です。
1. サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。
1. サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。
サイズ変更の進行状況は、Amazon Redshift コンソールで確認できます。クラスターのサイズ変更にかかる時間は、データ量に左右されます。
**注記**
**RA3 クラスターのサイズを変更するときのレガシーノードタイプの選択** — RA3 ノードを含むクラスターから別のノードタイプ (DC2 など) にサイズを変更しようとすると、検証警告メッセージがコンソールに表示され、サイズ変更オペレーションは完了しません。これは、レガシーノードタイプへのサイズ変更がサポートされていないためです。これにより、お客様が非推奨または間もなく非推奨になるノードタイプへのサイズ変更をできないようにしています。これは、伸縮自在なサイズ変更と従来のサイズ変更の両方に当てはまります。
#### ターゲットクラスターが RA3 である場合の従来のサイズ変更のモニタリング
進行中のプロビジョニングされたクラスターの従来のサイズ変更 (キー分散を含む) をモニタリングするには、[SYS\$1RESTORE\$1STATE](https://docs.aws.amazon.com/redshift/latest/dg/SYS_RESTORE_STATE.html) を使用します。変換中のテーブルの完了率が表示されます。データにアクセスするには、スーパーユーザーである必要があります。
従来のサイズ変更を実行するときに不要なテーブルを削除します。これを行うと、既存のテーブルをより迅速に分散できます。
### ターゲットクラスターが RA3 でない場合の従来のサイズ変更手順
ターゲットノードタイプが RA3 以外 (DC2 など) である場合、従来のサイズ変更の手順は次のとおりです。
1. ソースクラスターからターゲットクラスターへの移行が開始されます。新しいターゲットクラスターがプロビジョニングされると、Amazon Redshift はサイズ変更が開始された旨のイベント通知を送信します。これにより、既存のクラスターが再起動され、すべての接続が閉じられます。既存のクラスターがデータ共有プロデューサークラスターの場合、コンシューマークラスターとの接続も閉じられます。再起動には数分かかります。
`BACKUP NO` で作成したテーブルやマテリアライズドビューなどのデータベースリレーションは、従来のサイズ変更では保持されないことに注意してください。詳細については、「[CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html)」を参照してください。
1. 再起動後、データベースは読み取り専用になります。データ共有が再開されます。これにはさらに数分かかります。
1. データがターゲットクラスターに移行されます。データベースは読み取り専用のままです。
1. サイズ変更プロセスが完了間近になると、Amazon Redshift はターゲットクラスターのエンドポイントを更新し、ソースクラスターへのすべての接続は終了します。ターゲットクラスターは、データ共有のプロデューサーになります。
1. サイズ変更の完了です。Amazon Redshift がイベント通知を送信します。
サイズ変更の進行状況は、Amazon Redshift コンソールで確認できます。クラスターのサイズ変更にかかる時間は、データ量に左右されます。
**注記**
ターゲットクラスターが RA3 でない場合、または前のセクションで説明した RA3 ターゲットクラスターの前提条件を満たしていない場合、大量のデータを含むクラスターのサイズを変更するには、数日または場合によっては数週間かかることがあります。
また、クラスターの使用済みストレージ容量は、従来のサイズ変更後に増加する可能性があることにも注意してください。これは、従来のサイズ変更の結果としてクラスターにデータスライスが追加された場合、通常のシステム動作です。クラスター内のノード数が同じままでも、こうした追加容量の使用が発生する場合があります。
### 伸縮自在なサイズ変更 vs 従来のサイズ変更
次の表は、2 つのサイズ変更タイプの動作を比較しています。
| 行動 | 伸縮自在なサイズ変更 | 従来のサイズ変更 | コメント |
| --- | --- | --- | --- |
| システムデータ保持 | 伸縮自在なサイズ変更は、システムログデータを保持します。 | 従来のサイズ変更は、システムテーブルとデータを保持しません。 | ソースクラスターで監査ログ記録を有効にしている場合、サイズ変更をしたあと、Amazon S3 または CloudWatch でログへのアクセスを継続できます。これらのログは、指定したデータポリシーに応じて保持または削除することができます。 |
| ノードタイプの変更 | ノードタイプが変わらない場合、伸縮自在なサイズ変更: インプレースのサイズ変更すると、ほとんどのクエリが保持されます。 新しいノードタイプを選択した状態で伸縮自在なサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセスが完了すると、クエリは破棄されます。 | クラシックサイズ変更: 新しいクラスターが作成されます。サイズ変更プロセス中にクエリは破棄されます。 | |
| セッションとクエリの保持 | 伸縮自在なサイズ変更では、ソースクラスターとターゲットでノードタイプが同じである場合、セッションとクエリが保持します。新しいノードタイプを選択する場合、クエリは破棄されます。 | クラシックサイズ変更では、セッションとクエリは保持されません。クエリが破棄されます。 | クエリを削除すると、パフォーマンスが低下することが予想されます。サイズ変更操作は、使用負荷が低い時間に行うのが最適です。 |
| サイズ変更操作のキャンセル | 伸縮自在なサイズ変更をキャンセルすることはできません。 | Amazon Redshift コンソールのクラスター詳細から [**Cancel resize (サイズ変更のキャンセル)**] を選択すると、従来のサイズ変更オペレーションが完了する前にキャンセルできます。 | サイズ変更のキャンセルに要する時間は、キャンセルするとき、サイズ変更オペレーションのどのステージにあるかによって異なります。この操作を実行すると、キャンセル操作が完了するまでクラスターを利用できません。サイズ変更操作が最終ステージに達している場合、キャンセルできません。 RA3 クラスターへの従来のサイズ変更では、キャンセルできません。 |
### サイズ変更のスケジューリング
クラスターのサイズ変更オペレーションをスケジュールして、使用率の増加を予想してスケールアップしたり、コスト削減のためにスケールダウンしたりすることができます。スケジューリングは、伸縮自在なサイズ変更と従来のサイズ変更の両方に使えます。Amazon Redshift コンソールでスケジュールのセットアップできます。詳細については、**[Managing clusters using the console]** (コンソールを使ってクラスター管理) の「[クラスターのサイズ変更](#resizing-cluster)」を参照してください。AWS CLI または Amazon Redshift API 操作を使用して、サイズ変更をスケジュールすることもできます。詳細については、*AWS CLI コマンドリファレンス*の「[create-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/redshift/create-scheduled-action.html)」または *Amazon Redshift API リファレンス*の「[CreateScheduledAction](https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateScheduledAction.html)」を参照してください。
### スナップショット、リストア、およびサイズ変更
[伸縮自在なサイズ変更](#elastic-resize)は、Amazon Redshift クラスターのサイズを変更する最速の方法です。伸縮自在なサイズ変更オプションを選択できず、クラスターにほぼ恒常的な書き込みアクセスが必要な場合は、次のセクションで説明している、スナップショットと復元オペレーションを使用します。この方法では、スナップショットが作成された後でソースクラスターに書き込まれたデータは、ターゲットクラスターに切り替えた後、手動でコピーする必要があります。コピーにかかる時間によっては、両方のクラスター内のデータが同じになるまで、この操作を数回繰り返す必要がある場合もあります。その後で、ターゲットクラスターに切り替えられます。このプロセスは、ターゲットクラスターのすべてのデータが使用可能になるまでに、既存のクエリに悪影響を及ぼす可能性があります。ただし、データベースへの書き込みができない時間は最短になります。
スナップショット、復元、従来のサイズ変更アプローチでは、次のプロセスを使用します。
1. 既存のクラスターのスナップショットを作成します。既存のクラスターがソースクラスターです。
1. スナップショットを作成した時刻を記録します。そうすることで、スナップショット後のデータをターゲットデータベースにロードするための抽出、処理、ロード (ETL) プロセスを再実行する必要がある時点を識別できるようにします。
1. 新しいクラスターにスナップショットを復元します。この新しいクラスターがターゲットクラスターです。サンプルデータがターゲットクラスターにあることを確認します。
1. ターゲットクラスターのサイズを変更します。ターゲットクラスターに関して、新しいノードタイプ、ノード数、その他の設定を選択します。
1. ソースクラスターのスナップショット作成後に発生した ETL プロセスでロードされたデータを確認します。ターゲットクラスターには、同じデータを同じ順序で再ロードしてください。進行中のデータロードがある場合、ソースクラスターとターゲットクラスターのデータが同じになるまで、このプロセスを数回繰り返します。
1. ソースクラスターで実行中のすべてのクエリを停止します。これを行うには、クラスターを再起動するか、スーパーユーザーとしてログオンし、[PG\$1CANCEL\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_CANCEL_BACKEND.html) コマンドおよび [PG\$1TERMINATE\$1BACKEND](https://docs.aws.amazon.com/redshift/latest/dg/PG_TERMINATE_BACKEND.html) コマンドを使用できます。クラスターを再起動すると、クラスターが使用できないことを最も簡単に確認できます。
1. ソースクラスター名を変更します。たとえば、`examplecluster` から `examplecluster-source` に変更します。
1. 変更前のソースクラスター名を使用して、ターゲットクラスターの名前を変更します。たとえば、ターゲットクラスターの名前を `examplecluster` に変更します。これ以降、`examplecluster` を含むエンドポイントを使用するアプリケーションは、ターゲットクラスターに接続します。
1. ターゲットクラスターに切り替えた後、ソースクラスターを削除し、すべてのプロセスが期待どおりに動作することを確認します。
または、データをターゲットクラスターに再ロードする前にソースとターゲットクラスターの名前を変更することもできます。このアプローチは、依存するシステムやレポートをすぐに最新状態にしてターゲットクラスターに反映する必要がない場合に有効です。この場合、ステップ 6 は前述のプロセスの最後に移動されます。
名前変更プロセスは、アプリケーションが引き続き同じエンドポイントを使用してクラスターに接続する必要がある場合にのみ必要になります。これが必要ない場合は、クラスターの名前を変更せずにそのクラスターに接続するアプリケーションを、ターゲットクラスターのエンドポイントを使用するように更新することもできます。
クラスター名を再利用するのには、いくつかの利点があります。最初に、エンドポイントが変わらないため、基盤となるクラスターを変更しても、アプリケーションの接続文字列を更新する必要がありません。次に、Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) の通知などの関連項目が、クラスター名に固定されます。これは、クラスターにセットアップした同じアラームと通知を継続して使用することができるということです。この継続的な使用は、アラームや通知などの関連項目を再設定することなく、柔軟にクラスターのサイズを変更する必要がある本番稼働用環境では特に重要です。
# クラスターの名前変更
クラスターに別の名前を使用する必要がある場合は、クラスターの名前を変更できます。クラスターのエンドポイントには、クラスター名 (*クラスター識別子*とも呼ばれる) が含まれているため、名前の変更が完了した後、新しい名前を使用するようにエンドポイントを変更します。たとえば、`examplecluster` という名前のクラスターを、`newcluster` という名前に変更した場合は、`newcluster` 識別子を使用するようにエンドポイントを変更します。このクラスターに接続するアプリケーションは、新しいエンドポイントで更新する必要があります。
アプリケーションのエンドポイントを変更せずにアプリケーションの接続先のクラスターを変更する場合は、クラスターの名前を変更できます。この場合は、最初に元のクラスターの名前を変更してから、新しい接続先のクラスターを元のクラスターの名前に変更する必要があります。クラスター識別子はアカウントとリージョン内で一意にする必要があり、元のクラスターと変更後のクラスターを同じ名前にできないため、この操作が必要になります。スナップショットからクラスターを復元するときに、依存アプリケーションの接続プロパティを変更したくない場合も、この操作を行います。
**注記**
元のクラスターを削除する場合は、不要なクラスターのスナップショットを削除してください。
クラスターの名前を変更すると、クラスターの状態は、このプロセスが終了するまで `renaming` に変わります。クラスターに使用していた古い DNS 名は直ちに削除されますが、キャッシュには数分間残っています。名前を変更したクラスターの新しい DNS 名は、10 分以内で有効になります。名前を変更したクラスターは、新しい名前が有効になるまで使用できません。クラスターが再起動され、クラスターへの既存の接続は削除されます。これが完了すると、新しい名前を使用するようにエンドポイントが変更されます。そのため、名前の変更を開始する前にクエリの実行を停止し、名前の変更後に再起動する必要があります。
クラスターのスナップショットは保持され、クラスターに関連付けられたすべてのスナップショットは、クラスターの名前を変更した後も関連付けを維持します。たとえば、本番稼働用データベースにサービスを提供するクラスターがあり、そのクラスターに複数のスナップショットがあるとします。クラスターの名前を変更し、スナップショットのある本番稼働用環境に置き換えると、名前を変更したクラスターに既存のスナップショットが関連付けられます。
Amazon CloudWatch アラームおよび Amazon Simple Notification Service (Amazon SNS) イベント通知は、クラスター名に関連付けられます。クラスターの名前を変更した場合は、これらも更新する必要があります。CloudWatch アラームは CloudWatch コンソールで更新できます。また、[**Events (イベント)**] ペインの Amazon Redshift コンソールで Amazon SNS イベント通知を更新できます。クラスターのロードおよびクエリデータには、名前変更前と名前変更後のデータが引き続き表示されます。ただし、パフォーマンスデータは、名前変更プロセスの完了後にリセットされます。
詳細については、「[クラスターの変更](modify-cluster.md)」を参照してください。
# クラスターのリリースバージョンのアップグレード
[**リリースステータス**] 値が [**新しいリリースが利用可能**] になっているクラスターのリリースメンテナンスバージョンをアップグレードできます。メンテナンスバージョンをアップグレードすると、すぐにアップグレードするか、次のメンテナンス期間にアップグレードするかを選択できます。
**重要**
すぐにアップグレードする場合、アップグレードが完了するまでクラスターがオフラインになります。
**クラスターを新しいリリースバージョンにアップグレードするには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. アップグレードするクラスターを選択します。
1. **アクション**で、**Upgrade cluster version (クラスターバージョンのアップグレード)**] を選択します。[**Upgrade cluster version (クラスターバージョンのアップグレード)**] ページが表示されます。
1. ページに表示された手順に従います。
1. [**Upgrade cluster version (クラスターバージョンのアップグレード)**] を選択します。
# クラスターの一時停止と再開
特定の時間帯にのみ使用可能にする必要があるクラスターがある場合は、そのクラスターを一時停止して後で再開することができます。クラスターが一時停止している間は、オンデマンド課金は一時停止されます。課金されるのは、クラスターのストレージのみです。料金の詳細については、[Amazon Redshift 料金表](https://aws.amazon.com/redshift/pricing/)を参照してください。
クラスターを一時停止すると、Amazon Redshift はスナップショットを作成し、クエリの終了を開始して、クラスターを一時停止状態にします。一時停止したクラスターを最終スナップショットをリクエストせずに削除した場合、そのクラスターを復元することはできません。一時停止または再開オペレーションは、開始後にキャンセルまたはロールバックすることはできません。
クラスターの一時停止と再起動は、Amazon Redshift コンソール、AWS CLI、または Amazon Redshift API オペレーションで行うことができます。
クラスターの一時停止と再開は、アクションをスケジュールして行うことができます。新しい Amazon Redshift コンソールを使用して一時停止と再開を行う定期的なスケジュールを作成すると、選択した日付範囲に対して 2 つのスケジュールされたアクションが作成されます。スケジュールされたアクションの名前には、末尾に `-pause` と `-resume` が付けられます。名前の合計の長さは、スケジュールされたアクション名の最大サイズに収まる必要があります。
次のタイプのクラスターは一時停止できません。
+ EC2-Classic クラスター。
+ アクティブではないクラスター (現在変更中のクラスターなど)。
+ ハードウェアセキュリティモジュール (HSM) クラスター。
+ 自動スナップショットがオフになっているクラスター。
クラスターを一時停止する場合は、次の点を考慮してください。
+ クラスターへの接続またはクエリは行えません。
+ 一時停止したクラスターのクエリのモニタリング情報を Amazon Redshift コンソールに表示することはできません。
+ 一時停止したクラスターを変更することはできません。クラスターでスケジュールされたアクションは実行されません。これには、スナップショットの作成、クラスターのサイズ変更、クラスターのメンテナンスなどのオペレーションが含まれます。
+ ハードウェアのメトリクスは作成されません。作成されないメトリクスに CloudWatch のアラームを設定している場合は、アラームを更新してください。
+ 一時停止したクラスターの最新の自動スナップショットを手動スナップショットにコピーすることはできません。
+ クラスターが一時停止している間は、一時停止オペレーションが完了するまで再開することはできません。
+ クラスターを一時停止すると、課金は一時停止されます。ただし、一時停止オペレーションは、クラスターのサイズに応じて通常 15 分以内に完了します。
+ 監査ログはアーカイブされ、再開時には復元されません。
+ クラスターを一時停止すると、一時停止前に発生した問題のトラブルシューティングにトレースとログが使用できなくなる場合があります。
+ AWS Secrets Manager を使用して管理者認証情報を管理していて、クラスターを一時停止しても、クラスターのシークレットは削除されず、シークレットの料金は引き続き請求されます。AWS Secrets Manager で Redshift 管理者パスワードを管理する方法の詳細については、「[AWS Secrets Manager を使用した Amazon Redshift 管理者パスワードの管理](redshift-secrets-manager-integration.md)」を参照してください。
+ クラスター上のバックアップしないテーブルは、RA3 インスタンスタイプの再開時に復元されません。DC2 インスタンスタイプの再開時には復元されません。バックアップ用ではないテーブルの詳細については、「[スナップショットのテーブルを除く](working-with-snapshots.md#snapshots-no-backup-tables)」を参照してください。
クラスターを再開する場合は、次の点を考慮してください。
+ 再開されたクラスターのクラスターバージョンは、クラスターのメンテナンスウィンドウに基づいてメンテナンスバージョンに更新されます。
+ 一時停止したクラスターに関連付けられているサブネットを削除すると、互換性のないネットワークが存在することになる場合があります。その場合は、最新のスナップショットからクラスターを復元してください。
+ クラスターの一時停止中に Elastic IP アドレスを削除すると、新しい Elastic IP アドレスを求められます。
+ Amazon Redshift が前の Elastic Network Interface でクラスターを再開できない場合、Amazon Redshift は新しい Elastic Network Interface を割り当てようとします。
+ クラスターを再開すると、ノードの IP アドレスが変更される場合があります。それらの新しい IP アドレスを Secure Shell (SSH) の COPY や Amazon EMR の COPY などの機能でサポートするように、VPC の設定を更新する必要がある場合があります。
+ 一時停止していないクラスターを再開しようとすると、再開オペレーションはエラーを返します。再開オペレーションがスケジュールされたアクションの一部である場合は、今後のエラーを防ぐためにスケジュールされたアクションを変更または削除してください。
+ クラスターのサイズによっては、クラスターを再開してクエリを処理できるようになるまでに数分かかる場合があります。また、再開の完了後にクラスターが元の状態に戻るまでは、クエリのパフォーマンスにある程度の時間影響がある場合があります。
# クラスターの再起動
クラスターの再起動は、再起動前と同じ設定でクラスターを再起動するクラスターオペレーションです。クラスターを再起動して、保留中のメンテナンス更新の適用、設定変更のリセット、特定の問題からの復旧、クラスター問題のトラブルシューティングを行うことができます。クラスターを再起動すると、Amazon Redshift 環境の最適なパフォーマンス、セキュリティ、安定性を確保できます。次の手順では、Amazon Redshift クラスターを再起動するための詳細な手順を示します。
クラスターを再起動すると、クラスターの状態が `rebooting` に設定されます。再起動が終了すると、クラスターイベントが作成されます。保留されていたクラスターへの変更はすべて、この再起動時に適用されます。
**クラスターを再起動するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. 再起動するクラスターを選択します。
1. [**アクション**] で、[**クラスターの再起動**] を選択します。[**クラスターの再起動**] ページが表示されます。
1. [**クラスターの再起動**] を選択します。
# クラスターの再配置
Amazon Redshift で*再配置*を使用することにより、Amazon Redshift が、データの損失やアプリケーションへの変更なしに、クラスターを別のアベイラビリティーゾーン (AZ) に移動させることができます。再配置により、クラスター上でサービスが中断された場合でも、影響を最小限に抑えて操作を続行できます。
クラスターの再配置をオンにすると、Amazon Redshift は状況によってはクラスターの再配置を選択することがあります。特に、現在のアベイラビリティーゾーンの問題がクラスターの最適な動作を妨げている場合や、サービスの可用性を向上させる場合に再配置が発生します。特定のアベイラビリティーゾーンのリソース制約によってクラスター操作が中断される場合は、再配置関数を呼び出すこともできます。例として、クラスターを再開またはサイズ変更する機能があります。Amazon Redshift では、追加料金はかかりません。
Amazon Redshift クラスターが新しいアベイラビリティーゾーンに再配置されると、新しいクラスターは元のクラスターと同じエンドポイントを持ちます。アプリケーションはエンドポイントに再接続し、変更やデータの損失なしに操作を続行できます。ただし、特定のアベイラビリティーゾーンで潜在的なリソース制約が原因で、再配置が必ずしも可能とは限りません。
Amazon Redshift クラスターの再配置は、RA3 インスタンスタイプでのみサポートされています。RA3 インスタンスタイプでは、Redshift マネージドストレージ (RMS) を耐久性のあるストレージレイヤーとして使用します。クラスターデータの最新のコピーは、常に AWS リージョンの他のアベイラビリティーゾーンで使用できます。つまり、データを失うことなく、Amazon Redshift クラスターを別のアベイラビリティーゾーンに再配置できます。
クラスターの再配置をオンにすると、Amazon Redshift はクラスターをプロキシの背後に移行します。これにより、クラスタのコンピュートリソースへのロケーションに依存しないアクセスを実装できます。移行により、クラスターが再起動されます。クラスターが別のアベイラビリティーゾーンに再配置されると、新しいクラスターが新しいアベイラビリティーゾーンでオンラインに戻される間、停止が発生します。ただし、クラスターが新しいアベイラビリティーゾーンに再配置された後もクラスターエンドポイントは変更されないため、アプリケーションを変更する必要はありません。
クラスターの再配置は、サブネットグループに複数のアベイラビリティーゾーンが含まれている、新しく作成または復元された RA3 クラスターでデフォルトで有効になっています。Amazon Redshift は、プロビジョニングされたクラスターを作成するときに、5439 をデフォルトポートとして割り当てます。5431-5455 または 8191-8215 のポート範囲から別のポートに変更できます。(範囲外のポートには変更しないでください。エラーが発生します。) プロビジョニングされたクラスターのデフォルトポートを変更するには、Amazon Redshift コンソール、AWS CLI、または Amazon Redshift API を使用します。サーバーレスワークグループのデフォルトのポートを変更するには、AWS CLI または Amazon Redshift Serverless API を使用します。
再配置をオンにしていて、現在リーダーノードの IP アドレスを使用してクラスターまたは拡張された VPC ルーティングにアクセスしている場合は、そのアクセスを必ず変更してください。代わりに、クラスターの仮想プライベートクラウド (VPC) エンドポイントに関連付けられている IP アドレスを使用します。このクラスター IP アドレスを見つけるには、クラスターの詳細ページの **[Network and security]** (ネットワークとセキュリティ) セクションで VPC エンドポイントを見つけて使用します。VPC エンドポイントの詳細を表示するには、Amazon VPC コンソールにサインインします。
AWS Command Line Interface (AWS CLI) コマンド `describe-vpc-endpoints` を使用して、エンドポイントに関連付けられた Elastic Network Interface を取得することもできます。`describe-network-interfaces` コマンドを使用して、関連付けられた IP アドレスを取得できます。Amazon Redshift の AWS CLI コマンドの詳細については、*AWS CLI コマンドリファレンス*の「[Available commands](https://docs.aws.amazon.com/cli/latest/reference/redshift/index.html)」を参照してください。
## 制限事項
Amazon Redshift 再配置を使用する際は、次の制限事項に注意してください。
+ クラスターの再配置は、特定のアベイラビリティーゾーンで潜在的なリソース制限が原因で、すべてのシナリオで可能ではない場合があります。この場合、Amazon Redshift は元のクラスターを変更しません。
+ 再配置は、製品の DC2 インスタンスファミリーではサポートされません。
+ AWS リージョンをまたぐ再配置は実行できません。
+ Amazon Redshift 再配置のデフォルトはポート番号 5439 です。5431～5455 または 8191～8215 のポート範囲から別のポートに変更できます。
## コンソールを使用した再配置の管理
クラスターの再配置の設定は、Amazon Redshift コンソールを使用して管理できます。
### 新しいクラスターの作成時に再配置をオフにする
新しいクラスターを作成しているときに再配置をオフにするには、次の手順を使用します。
**新しいクラスターの再配置をオフにするには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. ここでクラスターを作成するには、[**クラスターの作成**] を選択します。クラスターの作成方法の詳細については、「*Amazon Redshift 入門ガイド*」の「[Amazon Redshift でプロビジョニングされたデータウェアハウス](https://docs.aws.amazon.com/redshift/latest/gsg/new-user.html)」を参照してください。
1. **[バックアップ]**、**[クラスターの再配置]** で、**[無効]** を選択します。デフォルトでは、再配置は有効化されています。
1. [**クラスターの作成**] を選択します。
### 既存のクラスターの再配置の変更
既存のクラスターの再配置設定を変更するには、次の手順を使用します。
**既存のクラスターの再配置設定を変更するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。現在のAWSリージョンにあるアカウントのクラスターがリストされています。各クラスターのプロパティのサブセットが、リストの列に表示されます。
1. クラスターのリストで、変更するクラスターの名前を選択します。クラスターの詳細ページが表示されます。
1. **[Maintenance]** (メンテナンス) タブを選択し、**[Backup details]** (バックアップの詳細) セクションで **[Edit]** (編集) を選択します。
1. **[バックアップ]** で、**[有効]** を選択します。デフォルトでは、再配置は有効化されています。
1. [**Modify cluster**] (クラスターの変更) を選択します。
### クラスターの再配置
クラスターを別のアベイラビリティーゾーンに手動で再配置するには、次の手順を使用します。これは、セカンダリアベイラビリティーゾーンでネットワーク設定をテストする場合や、現在のアベイラビリティーゾーンでリソース制約が発生している場合に特に便利です。
**クラスターを別のアベイラビリティーゾーンに再配置するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。現在のAWSリージョンにあるアカウントのクラスターがリストされています。各クラスターのプロパティのサブセットが、リストの列に表示されます。
1. リストから移動するクラスターの名前を指定します。クラスターの詳細ページが表示されます。
1. **[Actions]** (アクション) で、**[Relocate]**(再配置) を選択します。**[Relocate cluster]** (クラスターの削除) ページが表示されます。
1. (オプション) **[Availability Zone]** (アベイラビリティーゾーン) を選択します。アベイラビリティーゾーンを選択しない場合、Amazon Redshift によってアベイラビリティーゾーンが選択されます。
Amazon Redshift によって再配置が開始され、クラスターが再配置として表示されます。再配置が完了すると、クラスタのステータスが [available] に変わります。
## Amazon Redshift CLI を使用した再配置の管理
AWS Command Line Interface (CLI) を使用して、クラスターの再配置の設定を管理できます。
次のコマンド例では、AWS CLI を使用して、再配置がオンになっている **mycluster** という名前の Amazon Redshift クラスターを作成します。
```
aws redshift create-cluster --cluster-identifier mycluster --number-of-nodes 2 --master-username enter a username --master-user-password enter a password --node-type ra3.4xlarge --port 5439 --no-availability-zone-relocation
```
現在のクラスターが別のポートを使用している場合は、再配置をオンにするよう変更する前に、5431～5455 または 8191～8215 のポート範囲から使用するように変更する必要があります。デフォルトは 5439 です。以下のコマンド例では、クラスターが指定範囲内のポートを使用していない場合に備えて、ポートを変更します。
```
aws redshift modify-cluster --cluster-identifier mycluster --port 5439
```
以下のコマンド例には、Amazon Redshift クラスター上のアベイラビリティーゾーン再配置パラメータが含まれています。
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone-relocation
```
以下のコマンド例では、Amazon Redshift クラスターでアベイラビリティーゾーン再配置パラメータを無効化します。
```
aws redshift modify-cluster --cluster-identifier mycluster --no-availability-zone-relocation
```
以下のコマンド例では、Amazon Redshift クラスターでの再配置を呼び出します。
```
aws redshift modify-cluster --cluster-identifier mycluster --availability-zone us-east-1b
```
# クラスターの使用制限の設定
最大 4 つの使用制限を追加して、次のそれぞれの使用量を制御できます。
+ 同時実行スケーリング
+ 追加のコンピューティングリソースを使用した自動最適化の実行
+ Redshift Spectrum の使用
+ リージョン間でのデータ共有
## プロビジョニングされたクラスターの使用制限の設定
プロビジョニングされたクラスターの使用制限を設定する手順は、次のとおりです。
**クラスターの使用制限を設定するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. 制限を設定するプロビジョニングされたクラスターに移動します。
1. クラスターの詳細ページで、**[アクション]** ドロップダウンメニューから **[使用制限を管理]** を選択します。クラスターの **[メンテナンス]** タブを選択し、下にスクロールして **[使用制限を作成]** を選択することもできます。
1. 設定する使用制限で **[制限を追加]** を選択します。特定の機能に対して最大 4 つの制限を追加できます。
1. 使用制限の **[期間]** に、**[毎日]**、**[毎週]**、または **[毎月]** のいずれかを設定します。
1. **[使用制限]** を設定します。
+ 追加のコンピューティングリソース制限を使用して同時実行スケーリングと自動最適化を実行する場合、使用制限は Amazon Redshift が特定の期間に機能を使用して費やす時間になります。この場合、使用制限は時間および分単位で設定されます。
+ Redshift Spectrum の場合、使用制限は Amazon S3 からスキャンされたデータの量です。この場合、使用制限はテラバイト (TB) で設定されます。
+ クロスリージョンデータ共有の場合、使用制限は、プロデューサーリージョンからコンシューマーがクエリできるコンシューマーリージョンに転送されるデータの量を制限になります。この場合、使用制限はテラバイト (TB) で設定されます。
1. クラスターが制限に達したときに実行する Amazon Redshift の **[アクション]** を設定します。これには次のものが含まれます。
+ **システムテーブルへのログ記録** - システムビュー [SYS\$1QUERY\$1HISTORY](https://docs.aws.amazon.com/redshift/latest/dg/SYS_QUERY_HISTORY.html) にレコードを追加します。このビューの usage\$1limit 列をクエリして、クエリが制限を超えたかどうかを判断できます。
+ **[アラート]** - Amazon SNS を使用して通知サブスクリプションを設定し、制限に違反した場合に通知を送信します。既存の Amazon SNS トピックを選択するか、新しいトピックを作成するか、または選択せずに続行することもできます。
+ **機能の無効化** - 機能を無効にします。Amazon SNS を使用して通知を送信することもできます。ユーザーは引き続きクラスターを他のタスクに使用できます。
最初の 2 つのアクションは情報提供を目的としていますが、最後のアクションは機能の使用をオフにします。
1. ページの下部にある **[変更の保存]** をクリックして制限を保存します。一度に複数の制限を設定すると、**[変更を保存]** によってすべての制限が一度に保存されます。
# クラスターのシャットダウンと削除
クラスターの実行を停止して料金の発生を防ぐ場合は、クラスターをシャットダウンできます。シャットダウンするときに、オプションで最終スナップショットを作成できます。最終スナップショットを作成する場合、Amazon Redshift はクラスターの手動スナップショットを作成した後、クラスターをシャットダウンします。削除したクラスターと同じデータと構成を使って新しいクラスターをプロビジョニングする場合、この手動スナップショットが必要になります。手動スナップショットを使用すると、後でスナップショットを復元して、クラスターの使用を再開できます。
クラスターとそのデータが不要になった場合は、最終スナップショットを作成しないでシャットダウンすることができます。この場合、クラスターとデータは完全に削除されます。
クラスターのシャットダウン時に最終的な手動スナップショットを作成するかどうかにかかわらず、クラスターのシャットダウン後、クラスターに関連付けられた自動スナップショットはすべて削除されます。クラスターに関連付けられた手動スナップショットは保持されます。オプションの最終スナップショットも含めて、保持された手動スナップショットは、クラスターをシャットダウンするときに実行中のクラスターが他にない場合、または、実行中の Amazon Redshift クラスターで利用できる無料ストレージ枠を超えている場合、Amazon Simple Storage Service ストレージ料金が課金されます。スナップショットのストレージ料金の詳細については、[Amazon Redshift の料金表ページ](https://aws.amazon.com/redshift/pricing/)を参照してください。
クラスターを削除すると、関連する AWS Secrets Manager シークレットもすべて削除されます。
**クラスターを削除するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。
1. 削除するクラスターを選択します。
1. **[アクション]** で、**[削除]** を選択します。[**クラスターの削除**] ページが表示されます。
1. **[クラスターを削除]** を選択します。
**注記**
クラスターを削除して最終スナップショットを作成することを選択すると、クラスターで復元オペレーションが進行中の場合、Amazon Redshift は削除リクエストを停止します。この場合、最終スナップショットなしでクラスターを削除することも、復元の完了後に最終スナップショットを作成してクラスターを削除することもできます。
# Amazon Redshift スナップショットとバックアップ
スナップショットはクラスターのポイントインタイムバックアップです。スナップショットには、*自動*と*手動*の 2 つのタイプがあります。Amazon Redshift は、暗号化された Secure Sockets Layer (SSL) 接続を使用して、これらのスナップショットを Amazon S3 の内部に保存できます。
Amazon Redshift は、前回のスナップショット以降にクラスターに加えられた増分変更を追跡する、増分スナップショットを自動的に作成します。自動スナップショットは、スナップショットからクラスターを復元するために必要なすべてのデータを保持します。自動スナップショットをいつ作成するかを制御するためにスナップショットスケジュールを作成できます。また、いつでも手動スナップショットを作成することもできます。
スナップショットから復元すると、Amazon Redshift は新しいクラスターを作成し、すべてのデータをロードする前に新しいクラスターを使用できるようにするので、すぐに新しいクラスターのクエリを開始できます。クラスターは、アクティブなクエリに応じてスナップショットからデータをオンデマンドでストリーミングし、次に残りのデータをバックグラウンドでロードします。
クラスターを起動するとき、自動スナップショットと手動スナップショットの保持期間を設定できます。クラスターを変更して、自動スナップショットと手動スナップショットの保持期間を変更できます。スナップショットを作成するか、スナップショットを変更して、手動スナップショット保持期間を変更できます。
AWS マネジメントコンソール でスナップショットの詳細を表示するか、CLI または [DescribeClusterSnapshots](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusterSnapshots.html) API アクションで [describe-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-cluster-snapshots.html) を呼び出して、スナップショットの進行状況をモニタリングできます。これにより、進行中のスナップショットについて、差分スナップショットのサイズ、転送速度、経過時間、および推定残り時間などの情報が表示されます。
バックアップを常にクラスターで使用できるようにするために、Amazon Redshift は、Amazon Redshift の管理対象の内部管理 Amazon S3 バケットにスナップショットを保存します。ストレージの料金を管理するには、自動スナップショットを保持する必要がある日数を評価し、それに応じて保持期間を設定します。不要になった手動スナップショットを削除します。バックアップストレージのコストに関する詳細については、[Amazon Redshift の料金表](https://aws.amazon.com/redshift/pricing/)ページを参照してください。
AWS Backup を使用してスナップショットを作成および復元することもできます。Backup は、AWS のサービス、クラウド、オンプレミスにわたってデータ保護の一元化と自動化に役立つフルマネージドサービスです。詳細については、「[AWS Backup と Amazon Redshift の統合](managing-aws-backup.md)」を参照してください。AWS Backup の詳細については、「*AWS Backup Developer Guide*」の「[What is AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)」を参照してください。
## Amazon Redshift Serverless でのスナップショットとバックアップの操作
プロビジョニングされたクラスターと同様に、Amazon Redshift Serverless では、名前空間内のポイントインタイムのオブジェクトとデータとしてバックアップを行うことができます。Amazon Redshift Serverless のバックアップには、手動で作成するスナップショットと、Amazon Redshift Serverless が自動的に作成する復旧ポイントの 2 種類があります。Amazon Redshift Serverless のスナップショットの操作の詳細については、「[スナップショットと復旧ポイント](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html)」を参照してください。
プロビジョニングされたクラスターからサーバーレス名前空間にスナップショットを復元することもできます。詳細については、「[スナップショットからサーバーレス名前空間の復元](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshot-restore.html)」を参照してください。
## 自動スナップショット
自動スナップショットがクラスターに対して有効になると、Amazon Redshift は定期的にそのクラスターのスナップショットが作成されます。デフォルトでは、Amazon Redshift は約 8 時間ごと、または 1 ノードのデータが変更されるごとに 5 GB ごと (あるいはそのいずれか早い方) にスナップショットを作成します。データがノード数の 5 GB \$1 を超える場合、自動スナップショット作成間の最短時間は 15 分です。または、自動スナップショットを作成するタイミングを制御するためにスナップショットスケジュールを作成することができます。カスタムスケジュールを使用している場合は、自動スナップショット間の最小時間は 1 時間です。自動スナップショットは、クラスターを作成するときデフォルトで有効になります。
自動スナップショットは、保持期間の終了時に削除されます。デフォルトの保持期間は 1 日ですが、Amazon Redshift コンソールを使用するか、Amazon Redshift API または CLI を使用してプログラムにより変更できます。
自動スナップショットを無効にするには、保持期間を 0 に設定します。自動スナップショットを無効にした場合、Amazon Redshift はスナップショットの取得を停止し、クラスターの既存の自動スナップショットを削除します。RA3 ノードタイプでは、自動スナップショットを無効にすることはできません。RA3 ノードタイプの自動保存期間を 1～35 日に設定できます。
自動スナップショットを削除できるのは Amazon Redshift のみです。手動で削除することはできません。Amazon Redshift では、スナップショットの保存期間終了時、クラスターの自動スナップショットを無効にした場合、またはクラスターを削除した場合に、自動スナップショットが削除されます。*Amazon Redshift は、自動スナップショットを無効にするか、クラスターを削除するまで、最新の自動スナップショットを保持します。*
自動スナップショットをもっと長い期間保持する場合は、そのコピーを手動スナップショットとして作成します。自動スナップショットは、保持期間が終わるまで保持されますが、対応する手動スナップショットは手動で削除するまで、または保持期間が終わるまで保持されます。
## 自動スナップショットのスケジュール
スナップショットを作成するタイミングを正確に制御するために、スナップショットスケジュールを作成し、それを 1 つ以上のクラスターにアタッチすることができます。スナップショットスケジュールを変更すると、関連付けられているすべてのクラスターのスケジュールが変更されます。クラスターにスナップショットスケジュールがアタッチされていない場合、クラスターはデフォルトの自動スナップショットスケジュールを使用します。
*スナップショットスケジュール* は、一連のスケジュールルールです。指定した間隔 (8 時間ごと、12 時間ごとなど) に基づいてシンプルなスケジュールルールを定義できます。特定の曜日、特定の時間、特定の期間にスナップショットを作成するためのルールを追加することもできます。ルールは Unix 互換の cron 式を使って定義することもできます。
## スナップショットスケジュール形式
Amazon Redshift コンソールで、スナップショットスケジュールを作成できます。その後、スケジュールをクラスターにアタッチしてシステムスナップショットの作成をトリガーできます。スケジュールは複数のクラスターにアタッチでき、スナップショットをトリガーするためにスケジュール内に複数の cron 定義を作成できます。
cron 構文を使用してスナップショットのスケジュールを定義できます。これらのスケジュールの定義は、変更された Unix 互換の [cron](http://en.wikipedia.org/wiki/Cron) 構文を使用します。[協定世界時 (UTC)](http://en.wikipedia.org/wiki/Coordinated_Universal_Time) で時間を指定します。最大頻度 1 時間、最小精度 1 分のスケジュールを作成できます。
Amazon Redshift の変更された cron 式には 3 つの必須フィールドがあり、それらは空白で区切られます。
**構文**
```
cron(Minutes Hours Day-of-month Month Day-of-week Year)
```
| **フィールド** | **値** | **ワイルドカード** |
| --- | --- | --- |
| 分 | 0～59 | , - \$1 / |
| 時間 | 0～23 | , - \$1 / |
| 日 | 1～31 | , - \$1 ? / L W |
| 月 | 1～12 または JAN～DEC | , - \$1 / |
| 曜日 | 1～7 または SUN～SAT | , - \$1 ? L \$1 |
| 年 | 1970～2199 | , - \$1 / |
**ワイルドカード**
+ ワイルドカード [**,**] (カンマ) には追加の値が含まれます。`Day-of-week` フィールドの、`MON,WED,FRI` は、月曜日、水曜日、金曜日を含みます。合計値はフィールドあたり 24 に制限されています。
+ ワイルドカード [**-**] (ダッシュ) は範囲を指定します。`Hour` フィールドの、「1～15」は、指定した日の 1 時間から 15 時間を含みます。
+ ワイルドカード [**\$1**] (アスタリスク) にはフィールドのすべての値が含まれます。`Hours` フィールドの、**\$1** にはすべての時間が含まれています。
+ ワイルドカード [**/**] (スラッシュ) で増分を指定します。`Hours` フィールドで、**1/10** と入力して、その日の最初の時間から始めて、10 時間毎を指定できます (01:00、11:00、21:00 など)。
+ **[?]** (疑問符) のワイルドカードは、任意を意味します。`Day-of-month` フィールドで **7** と入力し、7 日が何曜日であってもかまわない場合、Day-of-week フィールドに **?** を入力できます。
+ `Day-of-month` フィールドまたは `Day-of-week` フィールドにある **[L]** のワイルドカードは、月または週の最終日を指定します。
+ `Day-of-month` フィールドの、ワイルドカード **W** は、平日を指定します。`Day-of-month` フィールドで、`3W` は月の 3 番目の平日に最も近い日を指定します。
+ Day-of-week フィールドの **\$1** ワイルドカードは、月の指定された曜日の特定のインスタンスを指定します。例えば、3\$12 は、月の第 2 火曜日を示します。3 は週の 3 番目の日 (火曜日) を示し、2 は月のそのタイプの 2 番目の日を示します。
**注記**
「\$1」文字を使用する場合、曜日フィールドには 1 つの式しか定義できません。例えば、「3\$11,6\$13」は 2 つの式として解釈されるため、無効です。
**制限**
+ Cron 式の `Day-of-month` フィールドと `Day-of-week` フィールドを同時に指定することはできません。一方のフィールドに値を指定する場合、もう一方のフィールドで **[?]** (疑問符) を使用する必要があります。
+ スナップショットスケジュールは以下の頻度をサポートしていません。
+ 1 時間に 1 回を超える頻度でスケジュールされるスナップショット。
+ 1 日 (24 時間) に 1 回未満の頻度でスケジュールされるスナップショット。
1 時間以内にスナップショットをスケジュールする結果になる重複したスケジュールがある場合、検証エラーが発生します。
スケジュールを作成するときは、以下のサンプルの cron 文字列を使用できます。
| 分 | 時間 | 曜日 | 意味 |
| --- | --- | --- | --- |
| 0 | 14-20/1 | 火 | 毎週火曜日の午後 2 時から午後 8 時の間。 |
| 0 | 21 | MON-FRI | 毎晩、月曜日～金曜日の午後9時。 |
| 30 | 0/6 | 土 - 日 | 土曜日と日曜日は、その日の深夜 30 分過ぎ (00:30) から、6 時間ごとに増分されます。これにより、各日とも [00:30、06:30、12:30、および 18:30] にスナップショットが作成されます。 |
| 30 | 12/4 | \$1 | 毎日 12:30 から 4 時間ごとに増分します。これにより [12:30、16:30、20:30] となります。 |
たとえば、毎日 15:15 から 2 時間ごとの増分のスケジュールに従って実行するとします。これにより [15:15、17:15、19:15、21:15、23:15] となりますが、次のように指定します。
```
cron(15 15/2 *)
```
スケジュールとして複数の cron スケジュール定義を作成できます。たとえば、次の AWS CLI コマンドでは、1 つのスケジュールに 2 つの cron スケジュールが含まれています。
```
create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)"
```
## 手動スナップショット
手動スナップショットはいつでも取得できます。デフォルトでは、手動スナップショットは、クラスターを削除した後も、無限に保持されます。手動スナップショットを作成するときに保持期間を指定できます。スナップショットを変更して保持期間を変更することもできます。ログ保持期間の変更の詳細については、「[手動スナップショットの保持期間を変更する](snapshot-manual-retention-period.md)」を参照してください。
スナップショットを削除した場合、そのスナップショットを参照する新しいオペレーションを開始することはできません。ただし、復元操作が進行中である場合、その復元操作は完了するまで実行されます。
Amazon Redshift には、作成できる手動スナップショットの合計数を制限するクォータがあります。このクォータは AWS アカウントごと、AWS リージョンごとにあります。デフォルトのクォータは [Amazon Redshift でのクォータと制限](amazon-redshift-limits.md) に一覧表示されています。
## スナップショットストレージ
手動スナップショットにはストレージ料金が発生するので、スナップショットが不要になった場合は削除することが重要です。Amazon Redshift は、それぞれのスナップショット保持期間の終了時に自動スナップショットおよび手動スナップショットを削除します。また、AWS マネジメントコンソール または [batch-delete-cluster-snapshots](https://docs.aws.amazon.com/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html) CLI コマンドを使用して、手動スナップショットを削除できます。
手動スナップショット設定を変更して、手動スナップショット保持期間を変更できます。
Amazon Redshift コンソールまたは CLI コマンド [describe-storage](https://docs.aws.amazon.com/cli/latest/reference/redshift/describe-storage.html) を使用すると、スナップショットが使用しているストレージ容量に関する情報を取得できます。
## スナップショットのテーブルを除く
デフォルトでは、スナップショットにすべてのユーザー定義の永続テーブルが含まれます。ステージングテーブルなど、テーブルをバックアップする必要のない場合は、スナップショットの作成やスナップショットからの復元にかかる時間を大幅に短縮できます。さらに、バックアップしないテーブルを使用して、Amazon S3 のストレージ領域を節約することができます。バックアップしないテーブルを作成するには、テーブルの作成時に BACKUP NO のパラメータを含めてください。詳細については、*Amazon Redshift データベースデベロッパーガイド*の [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) および [CREATE TABLE AS](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_AS.html) を参照してください。
**注記**
RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。バックアップ用ではないテーブルのスナップショットコストを回避するには、スナップショットを作成する前にそれらを切り捨てます。
# 手動スナップショットの作成
クラスターの手動スナップショットは、以下に示すスナップショットリストから作成できます。あるいは、クラスター設定ペインでクラスターのスナップショットを取得することもできます。詳細については、「[Amazon Redshift スナップショットとバックアップ](working-with-snapshots.md)」を参照してください。
**注記**
RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。バックアップ用ではないテーブルのスナップショットコストを回避するには、スナップショットを作成する前にそれらを切り捨てます。
**スナップショットを手動で作成するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次に **[Create snapshot]** (スナップショットの作成) を選択します。手動でスナップショットを作成するスナップショットページが表示されます。
1. スケジュール定義のプロパティを入力してから、[**スナップショットの作成**] を選択します。スナップショットが使用できるようになるまではしばらくかかります。
# スナップショットスケジュールの作成
Amazon Redshift は、データの自動的な増分スナップショットを定期的に取得し、Amazon S3 に保存します。さらに、いつでも好きなときにデータの手動スナップショットを取得することもできます。
Amazon Redshift コンソールでのスナップショットタスクはすべてスナップショットリストから開始します。時間範囲、スナップショットのタイプ、およびスナップショットに関連付けられたクラスターを使用して、リストをフィルタリングすることができます。さらに、日付、サイズ、スナップショットのタイプでリストを並べ替えることができます。スナップショットを操作する場合に使用できるオプションは、選択するスナップショットのタイプに応じて異なる場合があります。
スナップショットを作成するタイミングを正確に制御するために、スナップショットスケジュールを作成し、それを 1 つ以上のクラスターにアタッチすることができます。クラスターを作成するとき、またはクラスターを変更することによってスケジュールをアタッチできます。詳細については、「[自動スナップショットのスケジュール](working-with-snapshots.md#automated-snapshot-schedules)」を参照してください。
**スナップショットスケジュールを作成するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット、次に **[Snapshot schedules]** (スナップショットスケジュール) タブを選択します。スナップショットスケジュールが表示されます。
1. [**Add schedule (スケジュールの追加)**] を選択して、スケジュールを追加します。
1. スケジュール定義のプロパティを入力してから、[**Add schedule (スケジュールの追加)**] を選択します。
1. 表示されたページでは、新しいスナップショットスケジュールにクラスターをアタッチし、[**OK**] を選択できます。
# スナップショットの共有
1 つの既存の手動スナップショットについては、そのスナップショットへのアクセスを許可することにより、他の AWS 顧客アカウントのユーザーと共有することができます。各スナップショットは最大 20 個、各 AWS Key Management Service (AWS KMS) キーは最大 100 個まで許可できます。つまり、1 つの KMS キーで暗号化された 10 個のスナップショットがある場合、10 個の AWS アカウントに各スナップショットを復元することを許可できます。または、最大 100 個のアカウントのその他の組み合わせや、スナップショットごとに 20 個のアカウントを超えないその他の組み合わせを許可できます。アクセス権限が付与されたいずれかのアカウントのユーザーとしてログインされた担当者は、スナップショットを表示することも、当該アカウントでスナップショットを復元して新しい Amazon Redshift クラスターを作成することもできます。例えば、実稼働用およびテスト用に個別の AWS 顧客アカウントを使用する場合、ユーザーは本番用アカウントを使用してログオンし、テスト用アカウントのユーザーとスナップショットを共有することができます。テスト用アカウントのユーザーとしてログオンされた担当者は、テストまたは診断作業のためのテスト用アカウントによって所有される新しいクラスターを作成するためにスナップショットを復元することができます。
手動スナップショットは、それが作成された AWS 顧客アカウントによって永続的に所有されます。スナップショットを所有するアカウントのユーザーのみが、スナップショットへのアクセスを他のアカウントに許可したり、アクセス許可を取り消したりすることができます。アクセス権限が付与されたアカウントのユーザーは、そのアカウントと共有されているスナップショットの表示または復元が行えるだけで、共有されているスナップショットのコピーや削除を行うことはできません。アクセス許可はスナップショットの所有者がそれを取り消すまで有効です。アクセス許可が取り消されると、前にアクセス権限を付与されたユーザーはスナップショットの可視性を失い、スナップショットを参照する新しいアクションを起動できなくなります。アクセス権限が取り消される際、アカウントがスナップショットを復元するプロセスの途中にあった場合、復元は完了するまで実行されます。スナップショットにアクティブ認可がある限り、そのスナップショットを削除することはできません。まず、すべてのアクセス許可を取り消す必要があります。
AWS 顧客アカウントには、該当するアカウントによって所有されるスナップショットへのアクセスが常に許可されます。所有者アカウントへのアクセスを許可する試みまたは取り消す試みを行うと、エラーが発生します。非アクティブ AWS 顧客アカウントによって所有されているスナップショットを復元または表示することはできません。
AWS カスタマーアカウントへのアクセスを許可した場合、そのアカウントのユーザーがスナップショットに対してアクションを実行するには、それを許可するポリシーを持つロールを引き受ける必要があります。
+ スナップショット所有者アカウントのユーザーがスナップショットへのアクセスを許可および取り消しできるのは、当該スナップショットを含むリソース仕様でそのようなアクションの実行を許可する IAM ポリシーを持つロールを引き受けた場合に限られます。例えば、次のポリシーでは、AWS アカウント `012345678912` のユーザーまたはロールは、`my-snapshot20130829` という名前のスナップショットへのアクセスを他のアカウントに許可できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:AuthorizeSnapshotAccess",
"redshift:RevokeSnapshotAccess"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829"
]
}
]
}
```
------
+ スナップショットを共有している AWS アカウントのユーザーがそのスナップショットに対してアクションを実行するには、そのようなアクションを実行するためのアクセス許可が必要です。そのためには、ポリシーをロールに割り当て、そのロールを引き受けます。
+ スナップショットを一覧表示するか、または表示するためには、前述ユーザーは `DescribeClusterSnapshots` アクションを許可する IAM ポリシーを持っている必要があります。コードの例を以下に示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:DescribeClusterSnapshots"
],
"Resource":[
"*"
]
}
]
}
```
------
+ ユーザーがスナップショットを復元するには、`RestoreFromClusterSnapshot` アクションを許可する IAM ポリシーを持つロールを引き受ける必要があり、その IAM ポリシーにはユーザーが作成するクラスターとスナップショットの両方に対応するリソース要素が含まれている必要があります。例えば、アカウント `012345678912` のユーザーがスナップショット `my-snapshot20130829` をアカウント `219876543210` と共有している場合、スナップショットを復元してクラスターを作成するには、アカウント `219876543210` のユーザーが次のようなポリシーを持つロールを引き受ける必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"redshift:RestoreFromClusterSnapshot"
],
"Resource":[
"arn:aws:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829",
"arn:aws:redshift:us-east-1:219876543210:cluster:from-another-account"
]
}
]
}
```
------
+ スナップショットへのアクセスが AWS アカウントから取り消された後、そのアカウントのユーザーはスナップショットにアクセスできなくなります。これは、これらのアカウント内に、以前に共有したスナップショットリソースへのアクションを許可する IAM ポリシーがある場合でも同様です。
## コンソールを使用したクラスタースナップショットの共有
コンソールでは、自分が所有する手動スナップショットへのアクセスを他のユーザーに許可することができます。そのアクセス許可については後で不要になった場合に取り消すことができます。
**別のアカウントとスナップショットを共有するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次に共有する手動スナップショットを選択します。
1. [**アクション**] に [**Manual snapshot settings (手動スナップショット設定)**] を選択して、手動スナップショットのプロパティを表示します。
1. [**アクセスの管理**] セクションで共有するアカウント (複数可) を入力してから、[**保存**] を選択します。
## 暗号化されたスナップショットの共有に関するセキュリティ上の考慮事項
Redshift は、暗号化されたスナップショットに対するアクセス権を提供するときに、スナップショットの作成に使用された AWS KMS カスタマーマネージドキーがアカウントまたは復元を実行するアカウントと共有されることを必要とします。キーが共有されていない場合にスナップショットの復元を試みると、アクセス拒否エラーが発生します。受信側のアカウントには、共有スナップショットを復元するための追加のアクセス許可は必要ありません。スナップショットアクセスを認可し、キーを共有する場合、ID 認可アクセスにはスナップショットの暗号化に使用されたキーに対する `kms:DescribeKey` のアクセス許可が必要です。この権限については、「[AWS KMS アクセス権限](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html)」で詳しく説明します。詳細については、Amazon Redshift API リファレンスドキュメントの「[DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)」を参照してください。
カスタマーマネージドキーポリシーは、プログラム的に、または AWS Key Management Service コンソールで更新できます。
**注記**
デフォルトの KMS キーを使用している場合は、スナップショットを共有するために AWS KMS でアクションを実行したり、何かを変更したりする必要はありません。
### 暗号化されたスナップショットの AWS KMS キーへのアクセスの許可
暗号化されたスナップショットの AWS KMS カスタマーマネージドキーを共有するには、以下の手順を実行してキーポリシーを更新します。
1. キーを共有する AWS アカウントの Amazon リソースネーム (ARN) を KMS キーポリシーの `Principal` として使用して KMS キーポリシーを更新します。
1. `kms:Decrypt` アクションを許可します。
以下のキーポリシー例では、ユーザー `111122223333` が KMS キーの所有者であり、ユーザー `444455556666` がキーを共有するアカウントです。このキーポリシーは、ユーザー `444455556666` のルート AWS アカウント ID の ARN をポリシーの `Principal` として含め、`kms:Decrypt` アクションを許可することによって、サンプル KMS キーへのアクセス権を AWS アカウントに付与します。
------
#### [ JSON ]
****
```
{
"Id": "key-policy-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/KeyUser",
"arn:aws:iam::444455556666:root"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
カスタマーマネージド KMS キーに対するアクセス権を付与した後は、暗号化されたスナップショットを復元するアカウントが AWS Identity and Access Management (IAM) ロールまたはユーザーを作成する必要があります (まだ作成していない場合)。さらに、その AWS アカウントは、KMS キーを使用して暗号化されたデータベーススナップショットを復元することを許可する IAM ポリシーをその IAM ロールまたはユーザーにアタッチする必要もあります。
AWS KMS キーに対するアクセス権の付与に関する詳細については、「AWS Key Management Service デベロッパーガイド」の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console)」を参照してください。
キーポリシーの概要については、「[Amazon Redshift が AWS KMS を使用する方法](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html)」を参照してください。
# 自動スナップショットのコピー
自動スナップショットを無効にした場合、またはクラスターを削除した場合、自動スナップショットはその保持期間が過ぎると自動的に削除されます。自動スナップショットをもっと長い期間保持したい場合は、それを手動スナップショットにコピーします。
**自動スナップショットをコピーする方法**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次にコピーするスナップショットを選択します。
1. [**アクション**] で [**自動スナップショットのコピー**] を選択してスナップショットをコピーします。
1. 新しいスナップショットのプロパティを更新し、次に [**コピー**] を選択します。
# スナップショットを別の AWS リージョンにコピーする
クラスターのスナップショット (自動または手動) を自動的に別の AWS リージョンにコピーするように Amazon Redshift を設定できます。スナップショットがクラスターのプライマリ AWS リージョンで作成されると、そのスナップショットはセカンダリ AWS リージョンにコピーされます。この 2 つの AWS リージョンは、それぞれ*ソース AWS リージョン*と*コピー先 AWS リージョン*として知られています。スナップショットのコピーを別の AWS リージョンに保存しておくと、プライマリ AWS リージョンに何かあった場合、最新のデータからクラスターを復元できます。一度に 1 つのコピー先 AWS リージョンにのみスナップショットをコピーするようにクラスターを設定できます。Amazon Redshift リージョンのリストについては、*Amazon Web Services 全般のリファレンス* の「[リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
Amazon Redshift でスナップショットを別の AWS リージョンに自動的にコピーできるようにする場合、スナップショットのコピー先 AWS リージョンを指定します。自動スナップショットの場合、コピー先 AWS リージョンにスナップショットを保持する保持期間も設定できます。自動スナップショットがコピー先 AWS リージョンにコピーされ、保持期間に達すると、そのスナップショットはコピー先 AWS リージョンから削除されます。これにより、スナップショットの使用率が低く保たれます。自動スナップショットがコピー先 AWS リージョンで保持される時間を短くまたは長くするには、この保持期間を変更します。
コピー先 AWS リージョンにコピーされる自動スナップショットに対して設定する期間は、ソース AWS リージョンの自動スナップショットの保持期間とは異なります。コピーされたスナップショットのデフォルトの保持期間は 7 日です。その 7 日間は、自動スナップショットにのみ適用されます。ソースおよびコピー先の AWS リージョン両方で、手動スナップショットは、スナップショット保持期間の終了時に削除されます。または手動でも削除できます。
クラスターの自動スナップショットコピーはいつでも無効にできます。この機能を無効にすると、スナップショットはソース AWS リージョンからコピー先 AWS リージョンにコピーされなくなります。コピー先 AWS リージョンにコピーされた自動スナップショットは、手動スナップショットコピーを作成しない限り、保持期間の制限に達すると削除されます。これらの手動スナップショットおよびコピー先 AWS リージョンからコピーされた手動スナップショットは、手動で削除するまでコピー先 AWS リージョンに保持されます。
スナップショットのコピー先 AWS リージョンを変更するには、まず自動コピー機能を無効にします。次に、新しいコピー先 AWS リージョンを指定して、再度有効にします。
スナップショットがコピー先 AWS リージョンにコピーされると、そのリージョンがアクティブになり、復元目的で利用できるようになります。
AWS KMS で暗号化されたクラスターのスナップショットを別の AWS リージョンにコピーするには、コピー先の AWS リージョンでカスタマー管理のキーを使用する、Amazon Redshift のための許可を作成します。次に、ソース AWS リージョンでスナップショットのコピーを有効にするときにその許可を選択します。スナップショットコピー許可の設定に関する詳細については、「[別の AWS リージョンに AWS KMS 暗号化スナップショットをコピーする](working-with-db-encryption.md#configure-snapshot-copy-grant)」を参照してください。
# スナップショットからのクラスターの復元
スナップショットには、クラスターで実行されているデータベースのデータが含まれます。また、ノード数、ノードタイプ、管理者ユーザー名など、クラスターに関する情報も含まれています。スナップショットからクラスターを復元する場合、Amazon Redshift がクラスター情報を使用して新しいクラスターを作成します。次に、スナップショットデータからすべてのデータベースを復元します。
**注記**
RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。
元のスナップショットから作成された新しいクラスターの場合、ノードタイプやノード数などの構成を選択できます。クラスターは同じ AWS リージョンに復元されます。アベイラビリティーゾーンに関しては、リクエスト時にアベイラビリティーゾーンを指定しない限り、システムによりランダムに選択されます。クラスターをスナップショットから復元する場合、新しいクラスターの互換性のあるメンテナンストラックをオプションで選択できます。
**注記**
異なる構成のクラスターにスナップショットを復元する場合、スナップショットはクラスターバージョン 1.0.10013 以降のクラスターで作成されている必要があります。
リストアの進行中は、通常、イベントは次の順序で生成されます。
1. RESTORE\$1STARTED – REDSHIFT-EVENT-2008 は、復元プロセスの開始時に送信されます。
1. RESTORE\$1SUCCEEDED – 新しいクラスターが作成されたときに、REDSHIFT-EVENT-3003 が送信されます。
クラスターはクエリに使用できます。
1. DATA\$1TRANSFER\$1COMPLETED – データ転送が完了すると、REDSHIFT-EVENT-3537 が送信されます。
**注記**
RA3 クラスターは、RESTORE\$1STARTED イベントと RESTORE\$1SUCCEEDED イベントのみを発行します。RA3 ノードタイプは Amazon Redshift マネージドストレージにデータを格納するため、RESTORE が成功した後に明示的にデータ転送を行う必要はありません。RA3 ノードでは、通常のクエリ処理の一環として、RA3 ノードと Amazon Redshift マネージドストレージ間でデータが継続的に転送されます。RA3 ノードは、ホットデータをローカルにキャッシュし、クエリ頻度の低いブロックを Amazon Redshift 管理ストレージに自動的に保持します。
[DescribeClusters](https://docs.aws.amazon.com/redshift/latest/APIReference/API_DescribeClusters.html) API アクションを呼び出すか、AWS マネジメントコンソールでクラスターの詳細を表示することにより、復元の進行状況をモニタリングできます。これにより、進行中の復元について、スナップショットデータのサイズ、転送速度、経過時間、および推定残り時間などの情報が表示されます。これらのメトリクスの説明については、「[RestoreStatus](https://docs.aws.amazon.com/redshift/latest/APIReference/API_RestoreStatus.html)」を参照してください。
スナップショットを使用して、アクティブなクラスターを前の状態に切り替えることはできません。
**注記**
新しいクラスターにスナップショットを復元する場合、別の値を指定しない限り、デフォルトのセキュリティグループおよびパラメータグループが使用されます。
異なる構成のクラスターにスナップショットを復元する理由には、次のようなものがあります。
+ クラスターがより小さなノードタイプで構成されており、それをより少ないノードでより大きなノードタイプに統合する場合。
+ ワークロードを監視し、より多くの CPU とストレージを備えたノードタイプに移行する必要があると判断した場合。
+ 異なるノードタイプでテストワークロードのパフォーマンスを測定する場合。
復元には次の制約があります。
+ 新しいノード設定では、既存のデータに対して十分なストレージが必要です。ノードを追加するときでも、データが再分配される方法のために、新しい設定に十分なストレージがない場合があります。
+ 復元操作は、新しいクラスターのクラスターバージョンと互換性のあるクラスターバージョンでスナップショットが作成されたかどうかをチェックします。新しいクラスターのバージョンレベルが早すぎる場合、復元操作は失敗し、エラーメッセージに詳細情報が報告されます。
+ 復元可能な設定 (ノードの数とノードの種類) は、元のクラスター内のノード数と、新しいクラスターのターゲットノードタイプによって決まります。利用可能な設定を確認するには、`action-type restore-cluster` で `describe-node-configuration-options` AWS CLI コマンド、または Amazon Redshift コンソールを使用できます。Amazon Redshift コンソールを使用した復元の詳細については、[スナップショットからのクラスターの復元](#working-with-snapshot-restore-cluster-from-snapshot) を参照してください。
次の手順で、多数のノードを持つクラスターを取得し、AWS CLI を使用して少数のノードを持つより大きなノードタイプに統合します。この例では、24 ノードのソースクラスターから始めます。この場合、このクラスターのスナップショットを既に作成しており、それをより大きなノードタイプに復元するとします。
1. 次のコマンドを実行して、24 ノードの クラスターの詳細を取得します。
```
aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012
```
1. 次のコマンドを実行して、スナップショットの詳細を取得します。
```
aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot
```
1. 次のコマンドを実行して、このスナップショットで使用可能なオプションの詳細を表示します。
```
aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster
```
このコマンドは、各オプションの推奨ノードタイプ、ノード数、およびディスク使用率を含むオプションリストを返します。この例では、前述のコマンドは次の可能なノード構成をリストします。3 ノードの クラスターに復元することを選択します。
```
{
"NodeConfigurationOptionList": [
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.large",
"NumberOfNodes": 24
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.large",
"NumberOfNodes": 48
},
{
"EstimatedDiskUtilizationPercent": 65.26134808858235,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 3
},
{
"EstimatedDiskUtilizationPercent": 48.94601106643677,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 4
},
{
"EstimatedDiskUtilizationPercent": 39.156808853149414,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 5
},
{
"EstimatedDiskUtilizationPercent": 32.630674044291176,
"NodeType": "dc2.8xlarge",
"NumberOfNodes": 6
}
]
}
```
1. 次のコマンドを実行して、選択したクラスター構成にスナップショットを復元します。このクラスターが復元された後、ソースクラスターと同じコンテンツがありますが、データは 3 つの `dc2.8xlarge` ノードに統合されています。
```
aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3
```
リザーブドノード (DC2 リザーブドノードなど) がある場合は、RA3 リザーブドノードにアップグレードできます。このアップグレードは、スナップショットからの復元を実行する場合、あるいは伸縮自在なリサイズを実行する場合に利用できます。コンソールを使用している場合は、このプロセスに関するガイドが提供されます。RA3 ノードへのアップグレードの詳細については、「[RA3 ノードタイプへのアップグレード](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3)」を参照してください。
**コンソールでスナップショットからクラスターを復元する方法**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次に復元するスナップショットを選択します。
1. [**スナップショットからの復元**] を選択して、スナップショット情報を使って作成される新しいクラスターの [**クラスターの設定**] と [**クラスター詳細**] 値を表示します。
1. 新しいクラスターのプロパティを更新してから、[**スナップショットからのクラスターの復元**] を選択します。
クラスタースナップショットを復元すると、復元されたデータウェアハウスはスナップショット作成時に使用されていたのと同じカスタム AWS KMS キーで暗号化されます。スナップショットにカスタム KMS キーがない場合、Amazon Redshift のバックアップ暗号化ロジックは次の要因によって決まります。
+ スナップショットを復元する Amazon Redshift データウェアハウスのタイプ。
+ スナップショット作成時のクラスターの暗号化タイプ。
クラスタースナップショットから復元した後のデータウェアハウスの暗号化方法については、次の表を参照してください。
| 送信先タイプ | スナップショットの暗号化タイプ | 復元先の暗号化タイプ |
| --- | --- | --- |
| プロビジョニングされたクラスター | AWS マネージドキー で暗号化 | AWS マネージドキー で暗号化 |
| プロビジョニングされたクラスター | AWS 所有のキー で暗号化 | AWS 所有のキー で暗号化 |
| サーバーレス名前空間 | AWS マネージドキー で暗号化 | AWS 所有のキー で暗号化 |
| サーバーレス名前空間 | AWS 所有のキー で暗号化 | AWS 所有のキー で暗号化 |
スナップショットの撮影時に AWS Secrets Manager が管理するクラスターの管理者パスワードを取得した場合は、引き続き AWS Secrets Manager を使用して管理者パスワードを管理する必要があります。クラスター詳細ページでクラスターの管理者認証情報を更新することで、クラスターの復元後にシークレットの使用をオプトアウトできます。
リザーブドノードがある場合は、RA3 リザーブドノードにアップグレードできます。このアップグレードは、スナップショットからの復元を実行する場合、あるいは伸縮自在なリサイズを実行する場合に利用できます。コンソールを使用している場合は、このプロセスに関するガイドが提供されます。RA3 ノードへのアップグレードの詳細については、「[RA3 ノードタイプへのアップグレード](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3)」を参照してください。
# スナップショットからのテーブルの復元
クラスター全体を復元する代わりに、スナップショットから単一のテーブルを復元できます。スナップショットから単一のテーブルを復元する場合、ソースのスナップショット、データベース、スキーマ、テーブル名、ターゲットのデータベース、スキーマ、および復元されるテーブル用の新しいテーブル名を指定します。
**注記**
RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。ただし、バックアップ用ではないテーブルの選択的な復元はサポートされていません。
新しいテーブル名を、既存のテーブルの名前にすることはできません。既存のテーブルを、スナップショットから復元されるテーブルに置き換えるには、スナップショットからテーブルを復元する前に、既存のテーブルの名前を変更するか、削除します。
ターゲットテーブルは、ソーステーブルの列の定義、テーブル属性、および外部キーを除く列の属性を使って作成されます。依存関係による競合を回避するため、ターゲットテーブルはソーステーブルから外部キーを継承しません。ソーステーブルで付与されたビューや許可などの依存関係は、ターゲットテーブルに適用されません。
ソーステーブルの所有者が存在する場合、そのデータベースユーザーが復元したテーブルの所有者となるのは、指定したデータベースやスキーマの関係の所有者となる十分なアクセス許可を持っている場合のみです。それ以外の場合には、クラスターの起動時に作成した管理者ユーザーが、復元されたテーブルを所有します。
復元されたテーブルは、バックアップが作成された時の状態に戻されます。これには、Amazon Redshift の[直列化分離](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html)への準拠により定義されるトランザクションの可視性のルールが含まれます。つまり、バックアップ後に開始した実行中のトランザクションにデータがすぐに見えるようになるということです。
スナップショットからのテーブルの復元には、以下の制限があります。
+ テーブルは、実行中のアクティブなクラスターのみに復元でき、そのクラスターから作成されたスナップショットのみから復元できます。
+ 一度に復元できるのは 1 つのテーブルのみです。
+ クラスターのサイズを変更する前に作成されたクラスターのスナップショットからテーブルを復元することはできません。例外として、ノードタイプが変更されていない場合は、伸縮自在にサイズを変更した後にテーブルを復元できます。
+ ソーステーブルで付与されたビューや許可などの依存関係は、ターゲットテーブルに適用されません。
+ 復元中のテーブルに対して行レベルのセキュリティが有効になっている場合、Amazon Redshift は、行レベルのセキュリティがオンになっているテーブルを復元します。
**スナップショットからテーブルを復元するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター) を選択して、テーブルを復元するクラスターを選択します。
1. [**アクション**] で、[**テーブルの復元**] を選択して [**テーブルの復元**] ページを表示します。
1. どのスナップショット、ソーステーブル、およびターゲットテーブルを使うかに関する情報を入力し、次に [**テーブルの復元**] を選択します。
**Example 例: AWS CLI を使用してスナップショットからテーブルを復元する**
次の例では、`restore-table-from-cluster-snapshot` AWS CLI コマンドを使用して、`my-source-table` の `sample-database` スキーマから `my-snapshot-id` テーブルを復元します。AWS CLI コマンド `describe-table-restore-status` を使用して、復元操作のステータスを確認できます。例では、新しいテーブルの名前 `mycluster-example` を使用して、`my-new-table` クラスターにスナップショットを復元します。
```
aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example
--new-table-name my-new-table
--snapshot-identifier my-snapshot-id
--source-database-name sample-database
--source-table-name my-source-table
```
# スナップショットからサーバーレス名前空間の復元
スナップショットからサーバーレス名前空間を復元すると、名前空間のすべてのデータベースをスナップショット内のデータベースに置き換えます。サーバーレススナップショットの詳細については、「[スナップショットと復元ポイント](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-snapshots-recovery-points.html)」を参照してください。Amazon Redshift は、プロビジョニングされたクラスタースナップショットを Amazon Redshift Serverless 名前空間に復元するときに、インターリーブキーを含むテーブルを自動的に複合キーに変換します。ソートキーの詳細については、「[ソートキーの使用](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html)」を参照してください。
プロビジョニングされたクラスターからサーバーレス名前空間にスナップショットを復元する方法。
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[Clusters]** (クラスター) と **[Snapshots]** (スナップショット) を選択したら、使用するスナップショットを選択します。
1. **[Restore from snapshot]** (スナップショットから復元) と **[Restore to serverless namespace]** (サーバーレス名前空間に復元) の順に選択します。
1. 復元先の名前空間を選択します。
1. スナップショットから復元することを確認します。**[restore]** (復元) を選択します。この操作により、サーバーレス名前空間内のすべてのデータベースが、プロビジョニングされたクラスターのデータで置き換えられます。
# 暗号化されていないクラスターのクロスリージョンスナップショットのコピーを設定する
クラスターのスナップショットを別の AWS リージョンにコピーするように Amazon Redshift を設定できます。クロスリージョンスナップショットのコピーを設定するには、各クラスターでこのコピー機能を有効にし、スナップショットをコピーする場所と、コピーされた自動または手動のスナップショットをコピー先 AWS リージョンに保持する期間を設定する必要があります。クロスリージョンコピーがクラスターで有効になると、すべての新しい手動および自動スナップショットが、指定された AWS リージョンにコピーされます。コピーされたスナップショットには **copy:** というプレフィックスが付きます。
**クロスリージョンスナップショットのコピーを設定するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター) を選択して、スナップショットを移動するクラスターを選択します。
1. **[Actions]** (アクション) で、**[Configure cross-region snapshot]** (クロスリージョンスナップショットの設定) を選択します。
[クロスリージョンの設定] ダイアログボックスが表示されます。
1. を使用する場合[**スナップショットのコピー**] で、**はい**。
1. [**コピー先 AWS リージョン**] で、スナップショットをコピーする AWS リージョンを選択します。
1. [**自動スナップショットの保持期間 (日数)**] で、自動スナップショットが削除される前にコピー先 AWS リージョンに保持される日数を選択します。
1. [**手動スナップショットの保持期間**] で、手動スナップショットが削除される前にコピー先 AWS リージョンに保持される日数を選択します。を選択すると、**カスタム値**の場合、保持期間は 1～3653 日間でなければなりません。
1. **[保存]** を選択します。
# AWS KMS 暗号化クラスターのクロスリージョンスナップショットのコピーを設定する
Amazon Redshift クラスターを起動する際に、コピー先の AWS リージョンのアカウントでルートキーのスナップショットコピー権限を設定できます。権限を設定しない場合、コピー先リージョンのスナップショットはデフォルトの AWS が所有するキーを使用して暗号化されます。こうすることにより、Amazon Redshift がコピー先 AWS リージョンで暗号化オペレーションを実行できるようになります。
次の手順は、AWS KMS 暗号化クラスターのクロスリージョンスナップショットコピーを有効化するプロセスを示しています。Amazon Redshift およびスナップショットコピー権限での暗号化の詳細については、[別の AWS リージョンに AWS KMS 暗号化スナップショットをコピーする](working-with-db-encryption.md#configure-snapshot-copy-grant) を参照してください。
**AWS KMS で暗号化されたクラスターのクロスリージョンスナップショットを設定するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター) を選択して、スナップショットを移動するクラスターを選択します。
1. **[Actions]** (アクション) で、**[Configure cross-region snapshot]** (クロスリージョンスナップショットの設定) を選択します。
[クロスリージョンの設定] ダイアログボックスが表示されます。
1. を使用する場合[**スナップショットのコピー**] で、**はい**。
1. [**コピー先 AWS リージョン**] で、スナップショットをコピーする AWS リージョンを選択します。
1. [**自動スナップショットの保持期間 (日数)**] で、自動スナップショットが削除される前にコピー先 AWS リージョンに保持される日数を選択します。
1. [**手動スナップショットの保持期間**] で、手動スナップショットが削除される前にコピー先 AWS リージョンに保持される日数を選択します。を選択すると、**カスタム値**の場合、保持期間は 1～3653 日間でなければなりません。
1. **[保存]** を選択します。
# 手動スナップショットの保持期間を変更する
スナップショット設定を変更して、手動スナップショット保持期間を変更できます。
**手動スナップショット保持期間を変更するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次に変更する手動スナップショットを選択します。
1. [**アクション**] に [**Manual snapshot settings (手動スナップショット設定)**] を選択して、手動スナップショットのプロパティを表示します。
1. スケジュール定義の改訂済みプロパティを入力してから、[**保存**] を選択します。
# クロスリージョンスナップショットのコピーの保持期間を修正する
クロスリージョンスナップショットのコピーを設定した後で、設定を変更できます。新しい日数を選択し、変更を保存することにより、保持期間を簡単に変更できます。
**警告**
クロスリージョンスナップショットのコピーを設定した後、コピー先 AWS リージョンを変更することはできません。
異なる AWS リージョンにスナップショットをコピーする場合、最初にクロスリージョンスナップショットのコピーを無効にします。その後、新しいコピー先 AWS リージョンと保持期間で再有効にします。コピーされた自動スナップショットは、クロスリージョンスナップショットコピーを無効化した後削除されます。そのため、クロスリージョンスナップショットコピーを無効化する前に、保持して手動スナップショットにコピーしたいものがないかどうか決定する必要があります。
**クロスリージョンスナップショットを変更するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター) を選択して、スナップショットを変更するクラスターを選択します。
1. [**アクション**] に、[**Configure cross-region snapshot (クロスリージョンスナップショットの設定)**] を選択してスナップショットのプロパティを表示します。
1. スケジュール定義の改訂済みプロパティを入力してから、[**保存**] を選択します。
# 手動スナップショットの削除
スナップショットリストで 1 つ以上のスナップショットを選択して手動スナップショットを削除できます。
**手動スナップショットを削除する方法**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで、**[Clusters]** (クラスター)、**[Snapshots]** (スナップショット)、次に削除するスナップショットを選択します。
1. [**アクション**] で [**スナップショットの削除**] を選択してスナップショットを削除します。
1. リストされたスナップショットの削除を確認してから、[**削除**] を選択します。
# AWS Glue Data Catalog にクラスターを登録する
クラスター全体を AWS Glue Data Catalog に登録して、AWS Glue によって管理されるカタログを作成できます。これらのカタログには、Apache Iceberg REST API に対応した任意の SQL エンジンでアクセスできます。Amazon Redshift から Apache Iceberg 互換のカタログを作成する方法については、「Amazon Redshift データベースデベロッパーガイド」の「[Apache Iceberg の Amazon Redshift との互換性](https://docs.aws.amazon.com/redshift/latest/dg/iceberg-integration_overview.html)」を参照してください。
**クラスターを AWS Glue Data Catalog に登録するには**
1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。
1. ナビゲーションメニューで **[クラスター]** を選択します。現在の AWS リージョン にあるアカウントのクラスターがリストされています。各クラスターのプロパティのサブセットが、リストの列に表示されます。クラスターがない場合、[**クラスターを作成**] を選択して作成します。
1. 登録するクラスターの名前を選択します。
1. **[アクション]** から **[AWS Glue Data Catalog に登録]** を選択します。**[AWS Glue Data Catalog に登録]** ポップアップボックスが表示されます。
1. クラスターの登録先の AWS アカウント ID を **[登録先アカウント ID]** に入力します。このアカウント ID が、AWS Glue Data Catalog でカタログを保持します。
1. **[名前空間の登録名]** に名前を入力します。これが、Data Catalog でクラスターの名前になります。
1. [**登録**] を選択します。AWS Lake Formation コンソールに自動的に移動します。
1. AWS Lake Formation でカタログ作成のプロセスに従います。カタログ作成の詳細については、「AWS Lake Formation デベロッパーガイド」の「[Amazon Redshift データ AWS Glue Data Catalog への取り込み](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-namespaces-datacatalog.html)」を参照してください。