Amazon Redshift
クラスター管理ガイド (API バージョン 2012年12月1日)

暗号化されていないクラスターを暗号化されたクラスターに移行する

クラスターを起動するときに暗号化を有効にします。暗号化されていないクラスターから暗号化されたクラスターに移行するには、まず既存のソースクラスターからデータをアンロードします。次に、選択した暗号化設定を使用して、新しいターゲットクラスター内のデータを再ロードします。暗号化されたクラスターを起動する方法の詳細については、「Amazon Redshift データベース暗号化」を参照してください。移行プロセスの間、ソースクラスターは最後の手順まで読み取り専用クエリで使用できます。最後のステップは、エンドポイントを切り替えるターゲットクラスターとソースクラスターの名前を変更して、すべてのトラフィックが新しいターゲットクラスターにルーティングされるようにすることです。名前を変更して再起動するまで、ターゲットクラスターは使用できません。データの転送中に、ソースクラスター上のすべてのデータロードおよびその他の書き込み操作を中断します。

移行の準備をするには

  1. ビジネスインテリジェンス (BI) ツールや抽出、変換、ロード (ETL) システムなど、Amazon Redshift と対話するすべての依存システムを特定します。

  2. 検証クエリを特定して移行をテストします。

    たとえば、次のクエリを使用してユーザー定義テーブルの数を検索できます。

    select count(*) from pg_table_def where schemaname != 'pg_catalog';

    次のクエリは、すべてのユーザー定義テーブルの一覧と各テーブルの行数を返します。

    select "table", tbl_rows from svv_table_info;
  3. 移行に適した時間を選択します。クラスター使用率が最も低い時間を見つけるには、CPU 使用率やデータベース接続数などのクラスターメトリクスを監視します。詳細については、「クラスターのパフォーマンスデータを表示する」を参照してください。

  4. 未使用のテーブルを削除します。

    テーブルのリストを作成し、各テーブルがクエリされた回数を知るには、次のクエリを実行します。

    select database, schema, table_id, "table", round(size::float/(1024*1024)::float,2) as size, sortkey1, nvl(s.num_qs,0) num_qs from svv_table_info t left join (select tbl, perm_table_name, count(distinct query) num_qs from stl_scan s where s.userid > 1 and s.perm_table_name not in ('internal worktable','s3') group by tbl, perm_table_name) s on s.tbl = t.table_id where t."schema" not in ('pg_internal');
  5. 暗号化された新しいクラスターを起動します。

    ソースクラスターと同じポート番号をターゲットクラスターに使用します。暗号化されたクラスターを起動する方法の詳細については、「Amazon Redshift データベース暗号化」を参照してください。

  6. アンロードとロードのプロセスを設定します。

    Amazon Redshift アンロード/コピーユーティリティを使用すると、クラスター間でデータを移行するのに役立ちます。このユーティリティは、ソースクラスターから Amazon S3 上の場所にデータをエクスポートします。データは AWS KMS で暗号化されます。ユーティリティーは、データをターゲットに自動的にインポートします。必要に応じて、移行が完了した後でこのユーティリティーを使用して Amazon S3 をクリーンアップすることができます。

  7. テストを実行してプロセスを検証し、書き込み操作を中断する必要のある期間を見積もります。

    アンロードおよびロード操作中に、データのロードおよびその他の書き込み操作を中断して、データの整合性を維持します。最も大きなテーブルの 1 つを使用して、アンロードとロードのプロセスを実行すると、タイミングを推定するのに役立ちます。

  8. スキーマ、ビュー、テーブルなどのデータベースオブジェクトを作成します。必要なデータ定義言語 (DDL) 文を生成するために、AWS GitHub リポジトリの AdminViews にあるスクリプトを使用できます。

クラスターを移行するには:

  1. ソースクラスターですべての ETL プロセスを停止します。

    処理中に書き込み操作がないことを確認するには、Amazon Redshift マネジメントコンソールを使用して書き込み IOPS を監視します。詳細については、「クラスターのパフォーマンスデータを表示する」を参照してください。

  2. 以前に特定した検証クエリを実行して、移行前に暗号化されていないソースクラスターに関する情報を収集します。

  3. (オプション) 1 つのワークロード管理 (WLM) キューを作成して、ソースクラスターとターゲットクラスターの両方で使用可能な最大限のリソースを使用します。たとえば、data_migrate という名前のキューを作成し、メモリーを 95 パーセント、同時実行レベル 4 でキューを構成します。詳細については、『Amazon Redshift Database Developer Guide』の「ユーザーグループとクエリグループに基づいてクエリをキューにルーティング」を参照してください。

  4. data_migrate キューを使用して UnloadCopyUtility を実行します。

    Amazon Redshift コンソールを使用して UNLOAD および COPY プロセスを監視します。

  5. 検証クエリを再度実行し、結果がソースクラスターの結果と一致することを確認します。

  6. ソースクラスターおよびターゲットクラスターの名前を変更して、エンドポイントをスワップします。詳細については、「ステップ 6: ソースとターゲットクラスターの名前を変更する」を参照してください。混乱を避けるために、この操作は営業時間外に実行してください。

  7. ETL やレポートツールなどのすべての SQL クライアントを使用して、ターゲットクラスターに接続できることを確認します。

  8. 暗号化されたソースクラスターをシャットダウンします。