すべてのプロダクト
Search

このプロダクト

    PolarDB:ApsaraDB RDS for PostgreSQLインスタンスのPolarDB for PostgreSQLクラスターへのアップグレードの概要, ApsaraDB RDS for PostgreSQLインスタンスのPolarDB for PostgreSQLクラスターへのアップグレードの概要

    ドキュメントセンター

    PolarDB:ApsaraDB RDS for PostgreSQLインスタンスのPolarDB for PostgreSQLクラスターへのアップグレードの概要, ApsaraDB RDS for PostgreSQLインスタンスのPolarDB for PostgreSQLクラスターへのアップグレードの概要

    最終更新日:Jul 04, 2024

    ApsaraDB RDS for PostgreSQLインスタンスをクラスターにアップグレードできます。 このトピックでは、アップグレードの概要を説明し、使用可能なアップグレード方法と利点、およびアップグレードの前提条件、制限、および課金ルールを紹介します。

    アップグレードについて

    PolarDBでは、ApsaraDB RDS for PostgreSQLインスタンスをクラスターにアップグレードできます。 移行先のPolarDBクラスターは、移行元ApsaraDB RDS for PostgreSQLインスタンスのアカウント、データベース、およびIPアドレスホワイトリストを使用します。

    ApsaraDB RDS for PostgreSQLインスタンスを、同じバージョンまたは異なるバージョンのPostgreSQLを実行するクラスターにアップグレードできます。 たとえば、ApsaraDB RDS For PostgreSQL 11インスタンスを 14クラスターにアップグレードできます。

    説明

    Data Transmission Service (DTS) を使用して論理的な移行を実行し、ApsaraDB RDS for PostgreSQLインスタンスをクラスターにアップグレードできます。

    論理的移行

    DTSコンソールでデータ同期タスクを作成し、ソースApsaraDB RDS for PostgreSQLインスタンスのスキーマとフルデータをターゲットクラスターに移行します。 次に、増分データがターゲットクラスターに同期されていることを確認します。

    メリット

    アップグレードには次の利点があります。

    • アップグレードは、エンドポイントとの切り替えをサポートします。 アプリケーションは、接続設定を変更することなく、移行先のPolarDBクラスターにシームレスに接続できます。

    • 移行は無料です。 ターゲットPolarDBクラスターに対してのみ課金されます。

    • 移行中にデータの損失は発生しません。

    • 増分データ移行をサポートしています。 サービスのダウンタイムは10分以下です。

    • ホット移行がサポートされています。 データ移行プロセス中に一時的な切断が1回だけ発生します。 一時的な切断は、ビジネスがApsaraDB RDS for PostgreSQLインスタンスからPolarDBクラスターに切り替えられたときに発生します。

    • 移行ロールバックがサポートされています。 移行が失敗した場合、移行は10分以内にロールバックできます。

    前提条件

    • ApsaraDB RDS for PostgreSQLインスタンスを 14クラスターにのみアップグレードできます。

    • ソースApsaraDB RDS for MySQLインスタンスでトリガーが作成された場合は、トリガーを削除して [続行] をクリックします。 または、[キャンセル] をクリックし、DTSコンソールでデータ同期タスクを手動で作成することもできます。 詳細については、「ApsaraDB RDS For PostgreSQLインスタンスからPolarDB for PostgreSQLクラスターへのデータの同期」をご参照ください。

    • ソースApsaraDB RDS for PostgreSQLインスタンスのエンドポイントでSecure Sockets Layer (SSL) または透過データ暗号化 (TDE) が有効になっている場合、インスタンスをPolarDBクラスターにアップグレードすることはできません。

    • ソースApsaraDB RDS for PostgreSQLインスタンスも、次のアップグレード条件を満たす必要があります。 条件が満たされない場合、条件はPolarDBアップグレードページに表示されます。

      • データベースは、ApsaraDB RDS for PostgreSQLインスタンスに作成する必要があります。

      • ApsaraDB RDS for PostgreSQLインスタンスのアカウント名は、クラスターでサポートされていない形式を使用できません。

      • AliyunServiceRoleForPolarDBサービスにリンクされたロールを作成する必要があります。

      • max_replication_slotsパラメーターの値は、関連するデータベースの数で示される、必要な双方向DTSリンクの総数よりも大きくする必要があります。

      • max_wal_sendersパラメーターの値は、関連するデータベースの数で示される、必要な双方向DTSリンクの総数よりも大きくなければなりません。

      • データベースの数は30以下である必要があります。 最大30の双方向DTSリンクを作成できます。

      • wal_levelカーネルパラメーターの値はlogicalである必要があります。

    制限事項

    • ApsaraDB RDS for PostgreSQLインスタンスを、同じバージョンまたはそれ以降のバージョンのにのみアップグレードできます。 ApsaraDB RDS for PostgreSQLインスタンスをダウングレードすることはできません。 たとえば、ApsaraDB RDS For PostgreSQL 14インスタンスをPolarDB for PostgreSQL 11クラスターにアップグレードすることはできません。

    • アップグレードには次の制限があります。

      • クロスリージョンデータ移行はサポートされていません。

      • データ移行中は、ソースApsaraDB RDS for PostgreSQLインスタンスのパラメーターを設定できません。

      • ソースApsaraDB RDS for PostgreSQLインスタンスには、次の表に記載されている制限が適用されます。

        項目

        説明

        ソースインスタンスの制限

        • 同期するテーブルには、PRIMARY KEYまたはUNIQUEの制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

        • 同期するオブジェクトとしてテーブルを選択し、ターゲットデータベースのテーブルまたは列の名前を変更するなど、テーブルを変更する場合は、1つのデータ同期タスクで最大5,000のテーブルを同期できます。 タスクを実行して5,000を超えるテーブルを同期すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルを同期するか、タスクを構成してデータベース全体を同期することをお勧めします。

        • 先行書き込みログ (WAL) ログの次の要件を満たす必要があります。

          • wal_levelパラメーターはlogicalに設定する必要があります。

          • 増分データ同期のみを実行する場合、ソースデータベースのWALログを24時間以上保存する必要があります。 完全データ同期と増分データ同期を実行する場合、ソースデータベースのWALログを少なくとも7日間保存する必要があります。 そうしないと、DTSはWALログの取得に失敗し、タスクが失敗する可能性があります。 特別な場合には、データの不整合または損失が発生する。 完全なデータ同期が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、WALログの保持期間を必ず指定してください。 そうしないと、DTSのサービスレベル契約 (SLA) のサービスの信頼性またはパフォーマンスが保証されない場合があります。

        • データ同期中は、ApsaraDB RDS for PostgreSQLインスタンスのエンドポイントまたはゾーンを変更しないでください。 それ以外の場合、データ同期タスクは失敗します。

        • ソースデータベースに長時間のトランザクションがあり、増分データがデータ同期タスクで同期されている場合、ソースデータベースの長時間のトランザクションがコミットされる前に生成されたWALログを蓄積することができます。 その結果、ソースデータベースのディスク容量が不足する可能性があります。

      • SQL文の制限:

        データ型

        SQL文

        DML

        INSERT、UPDATE、およびDELETE

        DDL

        • DDL操作は、2020年10月1日以降に作成されたデータ同期タスクによってのみ同期できます。

          重要

        • ApsaraDB RDS for PostgreSQLインスタンスの特権アカウントを使用し、そのインスタンスが20210228以降のマイナーエンジンバージョンを実行している場合、次のDDLステートメントを同期できます。 マイナーエンジンバージョンの更新方法については、「マイナーエンジンバージョンの更新」をご参照ください。

          • テーブルとドロップテーブルの作成

          • ALTER TABLE (RENAME TABLE、ADD COLUMN、ADD COLUMN DEFAULT、ALTER COLUMN TYPE、DROP COLUMN、ADD CONSTRAINT、ADD CONSTRAINT CHECK、およびALTER COLUMN DROP DEFAULTを含む)

          • TRUNCATE TABLE (ソースデータベースでPostgreSQL 11以降を実行)

          • テーブルのインデックスの作成

          重要

          • CASCADEやRESTRICTなど、DDLステートメントの追加情報を同期することはできません。

          • SET session_replication_role = replicaステートメントを実行するセッションからDDLステートメントを同期することはできません。

          • ソースデータベースによって同時にコミットされた複数のSQL文にDML文とDDL文の両方が含まれている場合、DTSはDDL文を同期しません。

          • ソースデータベースによって同時にコミットされた複数のSQL文に、同期されていないオブジェクトのDDL文が含まれている場合、DDL文は同期されません。

      • その他の制限:

        項目

        説明

        その他の制限

        • 各データ同期タスクは、1つのデータベースのみを同期できます。 複数のデータベースの場合、データベースごとに個別のデータ同期タスクが設定されます。

        • スキーマでテーブルを作成するか、スキーマレベルの同期中にRENAMEステートメントを実行してテーブルを再作成する場合は、データの一貫性を確保するために、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。 このステートメントを実行するときは、テーブルをロックしないことをお勧めします。 そうでなければ、デッドロックが発生する。

          説明

          • 操作を実行するときに、上記のステートメントのスキーマとテーブルを実際のスキーマ名とテーブル名に置き換えます。

          • オフピーク時に操作を実行することを推奨します。

        • DTSは、増分データのDDLステートメント、増分テーブルのスキーマ、およびハートビート情報を取得するために、ソースデータベースに次の一時テーブルを作成します。 データ同期中は、ソースデータベースの一時テーブルを削除しないでください。 そうでなければ、例外が生じる。 DTSインスタンスがリリースされると、一時テーブルは自動的に削除されます。

          public.dts_pg_class、public.dts_pg_attribute、public.dts_pg_type、public.dts_pg_enum、public.dts_postgres_heartbeat、public.dts_ddl_command、およびpublic.dts_args_session。

        • データ同期のレイテンシを正確にするために、DTSはdts_postgres_heartbeatという名前のハートビートテーブルをソースデータベースに追加します。

        • データ同期中、DTSはソースデータベースにレプリケーションスロットを作成してデータをレプリケートします。 レプリケーションスロットの先頭にdts_sync_ があります。 DTSは、ストレージ使用量を減らすために、120分ごとに履歴レプリケーションスロットを自動的にクリアします。

          説明

          • DTSは、インスタンスのリリース後にレプリケーションスロットを自動的に削除します。 同期中にデータベースのパスワードを変更したり、DTSのIPアドレスのホワイトリストを削除した場合、レプリケーションスロットは自動的に削除できません。 この場合、ソースデータベースからレプリケーションスロットを手動で削除する必要があります。 レプリケーションスロットを削除しない場合、レプリケーションスロットはストレージ使用量を累積し続けます。 これにより、ApsaraDB RDS for PostgreSQLインスタンスが利用できなくなる可能性があります。

          • データ同期タスクがリリースされるか失敗すると、DTSは自動的にレプリケーションスロットをクリアします。 ソースPostgreSQLデータベースでプライマリ /セカンダリの切り替えが実行される場合は、セカンダリデータベースにログインしてレプリケーションスロットをクリアする必要があります。

        • データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

        • 完全データ同期中に、INSERT操作を同時に実行すると、ターゲットデータベースのテーブルが断片化されます。 完全なデータ同期が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。

        • テーブルレベルのデータ同期では、DTSのみを使用してデータをターゲットデータベースに書き込む場合、データ管理 (DMS) を使用してオンラインDDL操作を実行できます。 詳細については、「ロックフリーDDL操作の実行」をご参照ください。

        • データ同期中は、DTSのみを使用してデータを宛先に書き込むことを推奨します。 これにより、ソースデータベースとターゲットデータベース間のデータの不一致が防止されます。 たとえば、DTS以外のツールを使用してターゲットデータベースにデータを書き込む場合、DMSを使用してオンラインDDL操作を実行すると、ターゲットデータベースでデータ損失が発生する可能性があります。

        • DTSは、シーケンスなどのメタデータの有効性をチェックしません。 メタデータの有効性を手動で確認する必要があります。

        • ワークロードをターゲットデータベースに切り替えた後、新しいシーケンスはソースデータベースのシーケンスの最大値から増加しません。 したがって、ワークロードをターゲットデータベースに切り替える前に、ソースデータベース内のシーケンスの最大値を照会する必要があります。 次に、クエリされた最大値をターゲットデータベースのシーケンスの初期値として指定する必要があります。 次のステートメントを実行して、ソースデータベース内のシーケンスの最大値を照会できます。

          do language plpgsql $$
declare
  nsp name;
  rel name;
  val int8;
begin
  for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
  loop
    execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
    raise notice '%',
    format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
  end loop;
end;
$$;

    課金ルール

    次の課金ルールがアップグレードに適用されます。

    PolarDBクラスターとDTSのデータ同期タスクに対して課金されます。 ただし、アップグレード機能は無料トライアルフェーズにあります。 タスクが作成されてから30日以内に同期タスクの料金は発生しません。 次の表に、課金ルールを示します。

    同期タイプ

    課金ルール

    スキーマ同期と完全データ同期

    タスクが作成されてから30日以内に同期タスクの料金は発生しません。

    30日後、タスクはキャンセルされます。 料金は発生しません。

    説明

    PolarDBコンソールにログインし、[基本情報] ページの [RDS移行] セクションで同期タスクの残りの有効期間を確認できます。

    増分データ同期

    エンドポイントとの切り替え (接続の変更は不要)

    ApsaraDB RDS for PostgreSQLインスタンスをPolarDBクラスターにアップグレードする場合、[エンドポイントで切り替える (接続の変更は不要)] を選択できます。 次に、システムはApsaraDB RDS for PostgreSQLインスタンスとPolarDBクラスター間でエンドポイントを交換します。 この場合、PolarDBクラスターに接続するためにアプリケーションの設定を変更する必要はありません。 次の図は、RDSインスタンスとPolarDBクラスター間でエンドポイントを交換するためのルールを示しています。

    image

    エンドポイントで切り替えるには、次の点に注意してください。

    • ApsaraDB RDS for PostgreSQLインスタンスとPolarDBクラスターのエンドポイントのみが交換されます。 vSwitchや仮想IPアドレスなどのその他の設定は交換されません。

    • ソースApsaraDB RDS for PostgreSQLインスタンスとターゲットPolarDBクラスターにエンドポイントがある場合にのみ、エンドポイントを交換できます。 デフォルトでは、内部ネットワーク内のプライマリエンドポイントのみを交換できます。

    • ApsaraDB RDS for PostgreSQLインスタンスとPolarDBクラスターのプライマリエンドポイントは、エンドポイントとの切り替え中に交換されます。 ビジネス要件に基づいて、ApsaraDB RDS for PostgreSQLインスタンスの専用プロキシエンドポイントをPolarDBクラスターのデフォルトクラスターエンドポイントと交換するか、ApsaraDB RDS for PostgreSQLインスタンスの読み取り専用エンドポイントをPolarDBクラスターのカスタムエンドポイントと交換するかを選択できます。 PolarDBクラスターには、最大7つのクラスターエンドポイントを設定できます。 したがって、ApsaraDB RDS for PostgreSQLインスタンスの最大7つの専用プロキシエンドポイントまたは読み取り専用エンドポイントを、PolarDBクラスターのクラスターエンドポイントと交換できます。

    • 他のエンドポイントを使用する場合は、切り替え前にエンドポイントを作成します。 PolarDBクラスターのエンドポイントを作成する方法については、「エンドポイントの表示または申請」をご参照ください。 ApsaraDB RDS For PostgreSQLインスタンスのエンドポイントを作成する方法の詳細については、「RDSインスタンスのエンドポイントの設定」をご参照ください。

    • エンドポイントとの切り替え中、ApsaraDB RDS for PostgreSQLインスタンスとPolarDBクラスター間でポートが交換されることはありません。 ApsaraDB RDS for PostgreSQLインスタンスのポートが、カスタムエンドポイントポートを除いて、PolarDBクラスターのポートと同じであることを確認します。 ポートの変更方法については、「インスタンスエンドポイントとポートの表示と管理」をご参照ください。

    • エンドポイントが交換された後、ドメインネームシステム (DNS) キャッシュデータの有効期限が切れたために問題が発生する可能性があります。 PolarDBクラスター内のデータベースが接続に失敗したり、読み取り操作のみをサポートしたりする場合があります。 この問題を修正するには、サーバーのDNSキャッシュデータを更新することをお勧めします。

    • エンドポイントの交換後にDMSを使用してPolarDBデータベースにログインする場合は、最新バージョンのDMSとクラスターIDを使用してデータベースにログインします。