Amazon Web Services ブログ

PostgreSQL のアップグレード中に AWS DMS タスクを処理するためのベストプラクティス

本投稿は、Veeramani A と Manoj Ponnurangam による記事 「Best practices to handle AWS DMS tasks during PostgreSQL upgrades」を翻訳したものです。

AWS Database Migration Service は、データのセキュリティとデータの整合性を提供しながら、データベースを Amazon Web Services (AWS) に移行およびレプリケーションするためのマネージドソリューションを提供します。AWS DMS は、ソースとターゲットのデータベースが同じエンジンを使用する 同種の移行と、異なるデータベース環境間の 異種の移行の両方に対応しています。

AWS DMS は、PostgreSQL データベースからサポートされているターゲットへのデータ移行を容易にし、またサポートされているソースから PostgreSQL データベースへの移行も可能にします。これにより、企業がデータインフラストラクチャをクラウドに移行するための堅牢な経路を提供します。

ソリューションの概要

オープンソースの PostgreSQL は、頻繁に発生するバグ、セキュリティ問題、データ破損の問題の修正を含む新しいマイナーバージョンとメジャーバージョンをリリースすることがあります。一般的に、Amazon RDS は、新しいエンジンバージョンが利用可能になってから 5 か月以内にサポートすることを目指しています。特定のバージョンがサポートされなくなった場合には PostgreSQL インスタンスをアップグレードする必要があります。問題の解決や新しい改善の導入、あるいはコンプライアンスの遵守やデータ保護のためにも PostgreSQL インスタンスをアップグレードする必要があります。

進行中の AWS DMS タスクのソースまたはターゲットとして設定されている PostgreSQL データベースをアップグレードする場合は、これをアップグレード計画に組み込むことが重要です。

この記事では、PostgreSQL のマイナーバージョンまたはメジャーバージョンへのアップグレード中に AWS DMS タスクを処理するためのベストプラクティスについて説明します。

前提条件

この記事のソリューションをテストするには、以下のリソースが必要です：

PostgreSQL のバージョンアップグレードの理解

PostgreSQL のアップグレードが AWS DMS タスクにどのように影響するかを詳しく見る前に、PostgreSQL におけるメジャーバージョンとマイナーバージョンのアップグレードについて明確に理解しておきましょう。

マイナーバージョンは、セキュリティの脆弱性を修正し、バグを修正し、一般的に新機能を追加しません。
マイナーリリースは内部ストレージ形式を変更せず、常に同じメジャーバージョン番号の前後のマイナーリリースと互換性があります。
例えば、バージョン 14.10 は、バージョン 14.9 およびバージョン 14.16 と互換性があります。

PostgreSQL のメジャーリリースでは、システムテーブル、データファイル、内部データストレージ形式も変更される可能性があります。RDS for PostgreSQL は、ネイティブの pg_upgrade ユーティリティを使用して、インスタンスを新しいメジャーバージョンにアップグレードします。アップグレードの詳細については、Amazon RDS の PostgreSQL DB エンジンのアップグレードをご参照ください。

マイナーリリースとメジャーリリース、またはバージョンアップグレードのいずれもダウンタイムが発生するため、適切なメンテナンスウィンドウ内で実施する必要があります。できればデータベースへのクエリが最も少ない時間帯にスケジュールされたメンテナンスウィンドウをこのアップグレード作業のために計画することをお勧めします。

AWS DMS と PostgreSQL の連携

AWS DMS を使用して PostgreSQL ソースから PostgreSQL ターゲットにデータを移行する場合を想定しましょう。

フルロード中、AWS DMS はソースの PostgreSQL データベースに接続し、テーブルマッピングで定義されたテーブルで select * を実行してデータをアンロードします。ソースから取得したデータは、PostgreSQL ターゲットに向けてレプリケーションインスタンスの CSV ファイルに書き込まれます。PostgreSQL ターゲットの場合、AWS DMS は COPY コマンドを使用して、CSV ファイルのデータをターゲットの PostgreSQL テーブルにロードします。

移行中の継続的な変更を取り込むために、AWS DMS はソースの PostgreSQL データベースに論理レプリケーションスロットを作成します。スロットは、変更のストリームを表し、ソースの PostgreSQL データベースで実行された順序でクライアントに再生することができます。DMS は、レプリケーションスロットからの変更のロジカルデコーディングに test_decoding または pglogical プラグイン のいずれかを使用します。ソースの PostgreSQL データベースで pglogical プラグインが利用可能な場合、DMS は pglogical を使用してレプリケーションスロットを作成します。そうでない場合は、test_decoding プラグインが使用されます。ソースから読み取られた変更は、レプリケーションインスタンス上のソーターコンポーネントに渡されます。ソーターコンポーネントはトランザクションをコミット順にソートし、その後、DMS タスクの設定に基づいて、順次またはバッチモードでこれらの変更をターゲットデータベースに適用します。

レプリケーションスロットは、フルロード + CDC および CDC のみのタスクにおいて重要な役割を果たします。
これは、ソースの PostgreSQL データベース上で必要なログ先行書き込み (WAL) ファイルを保持する役割を担っています。
ソースデータベース上でレプリケーションスロットが削除されると、DMS はソースデータベースからの継続的な変更を処理できなくなります。

PostgreSQL のアップグレードが AWS DMS タスクに与える影響

以下のセクションでは、ソースまたはターゲットの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード中に、DMS タスクをどのように扱うかについて説明します。

ソース PostgreSQL データベースのアップグレード時

フルロードのみの DMS タスクは、1 回限りのデータ移行用に設計されています。
これらのタスクは、ソースの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード後に安全に再開できます。

フルロード + CDC および CDC のみの DMS タスクは、進行中の変更をターゲットデータベースに継続的に複製します。PostgreSQL のアップグレード中に、フルロード + CDC および CDC のみの DMS タスクを処理する場合、次のセクションのベストプラクティスに従ってください。

マイナーリリースまたはバージョンアップグレード

マイナーバージョンのアップグレードを行う前に、実行中の AWS DMS レプリケーションタスクを停止してください。マイナーバージョンのアップグレードが完了したら、DMS タスクを再開できます。

メジャーバージョンアップグレード

執筆時点で、DMS は PostgreSQL バージョン 9.4 以降 (9.x バージョン)、10.x、11.x、12.x、13.x、14.x、15.x、および 16.x をサポートしています。
メジャーバージョンアップグレードを実行する際は、レプリケーションインスタンスが新しい PostgreSQL バージョンをサポートしていることを確認してください。

pg_upgrade を使用してメジャーバージョンアップグレードを進めるには、ソースの PostgreSQL データベース上のレプリケーションスロットを削除する必要があります。これらのスロットを削除しないと、アップグレードプロセスに影響を与える可能性があります。レプリケーションスロットを削除せずにアップグレードを試みると、pg_upgrade_precheck.log に 1 つ以上の論理レプリケーションスロットによってブロックされたためインスタンスをアップグレードできなかったというメッセージが表示され、アップグレードは失敗します。ただし、レプリケーションスロットを削除すると AWS DMS タスクが無効になり、進行中のレプリケーションタスクを再開できなくなります。

この問題に対処し、メジャーバージョンアップグレード中に進行中のレプリケーションタスクを管理するには、以下の手順を使用します：

  1. PostgreSQL データベースへのすべてのアプリケーション接続を停止します。以下を使用してアクティブな接続を監視します：
select * from pg_stat_activity where datname = 'database_name';

必要に応じて、残りの接続を以下のコマンドで終了します：

select pg_terminate_backend(pid) from pg_stat_activity where datname = 'database_name'and pid <> pg_backend_pid();
  1. AWS DMS タスクのメトリクスを監視して、CDCLatencySourceとCDCLatencyTargetの両方がゼロに近いことを確認します。これにより、DMS タスクが変更を遅延なく複製していることを確認できます。ターゲットでawsdms_txn_stateを使用してタスクステータスを取得することもできます（タスク設定「TaskRecoveryTableEnabled = True」で有効にできます）。次の画像は、CDCLatencySourceとCDCLatencyTargetの Cloudwatch メトリクスを示しています。

  1. レイテンシーがゼロに近づいたら、実行中のアクティブなレプリケーション DMS タスクをすべて停止してください。
  1. ソースの PostgreSQL データベースから既存のレプリケーションスロットを削除します。 
    postgres=> select * from pg_replication_slots ;
 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size 
-----------------+-------------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+---------------
 bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde | test_decoding | logical | 14405 | postgres | f | f | | | 898 | 0/5936F798 | 0/5F1A3440 | reserved |

(1 row)
 postgres=> SELECT pg_drop_replication_slot('bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde'); 
 pg_drop_replication_slot 
--------------------------
 
(1 row)
  1. レプリケーションスロットがないことを確認してください。 
    postgres=> select * from pg_replication_slots ;
 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size 
-----------+--------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+---------------
(0 rows)
  1. PostgreSQLデータベースのインプレイスアップグレードを完了してください。
  1. アップグレードプロセスが正常に完了したことを確認します。データベースレベルの検証チェックを実行して、アップグレード後にデータベースが期待通りに動作していることを確認します。アプリケーションを開始する前に、DMS タスクを処理するために step 8 または step 9 のいずれかに従ってください。
  1. CDC のみのタスクを新しく作成してください。タスク設定で、ソーストランザクションの CDC 開始モードのカスタム CDC 開始モードを無効にするを選択します。古いタスクと同様に、他のタスク設定とテーブルマッピングを定義します。

タスクが作成されたら、CDC のみのタスクを開始します。これにより、ソースの PostgreSQL データベースに新しいレプリケーションスロットが作成され、レプリケーションスロットが作成された時点からの変更の移行が開始されます。

  1. または、指定されたログシーケンス番号 (LSN) から開始する DMS CDC のみのタスクを使用して、ソース PostgreSQL データベースにレプリケーションスロットを手動で作成することもできます。ソースにレプリケーションスロットを作成し、confirmed_flush_lsn を記録してください。

confirmed_flush_lsn は、論理スロットのコンシューマーが PostgreSQL エンジンにデータを受信したことを確認した最後の LSN を表します。
この LSN より前にコミットされたトランザクションに対応するデータは、もはや利用できません。

a. ソースエンドポイントの設定を変更し、ソース PostgreSQL データベースで作成した目的のスロットを SlotName として追加します。

b. タスク設定を変更してください。カスタム CDC 開始モードを有効にするを選択し、ログシーケンス番号を指定する (訳者注 : DMS マネジメントコンソールの新しいナビゲーションの場合 「ネイティブな CDC 開始点」) を選択して、confirmed_flush_lsnから LSN を入力します。

  1. DMS タスクを開始し、変更が問題なくターゲットデータベースに移行されていることを確認します。
  1. アプリケーションを起動し、DMS CDC レプリケーションを監視します。

ターゲットの PostgreSQL データベースをアップグレードする時

AWS DMS CDC は、ターゲットの PostgreSQL データベースのマイナーバージョンアップグレードの影響を受けません。
DMS のターゲットとして設定された PostgreSQL データベースをアップグレードする前に、DMS タスクを停止し、マイナーバージョンアップグレードが成功した後に再開してください。

DMS のターゲットとして設定された PostgreSQL データベースでメジャーバージョンアップグレードを実行する場合：

  • 現在のレプリケーションインスタンスエンジンのバージョンが新しい PostgreSQL バージョンをサポートしていることを確認してください。
  • 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされている場合は、AWS DMS タスクを停止し、メジャーバージョンのアップグレードを完了してから DMS タスクを再開できます。
  • 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされていない場合は、DMS タスクを停止して、ターゲットの PostgreSQL データベースでメジャーバージョンのアップグレードを完了する必要があります。また、レプリケーションインスタンスを、ターゲットの PostgreSQL データベースの現在のバージョンをサポートするバージョンにアップグレードする必要があります。ターゲットデータベースとソースデータベースの両方が互換性のあるメジャーバージョンに更新されたら、DMSタスクを再開できます。

クリーンアップ

この投稿で作成したリソースを削除することで、変更を元に戻し、継続的な料金の発生を避けることができます：

  1. このソリューションのテストのために作成され、不要となった RDS for PostgreSQL インスタンスとEC2 インスタンスを削除します。
  2. このソリューションのテストのために作成された AWS DMS タスクを削除します。
  3. AWS DMS のソースエンドポイントとターゲットエンドポイントを削除します。
  4. AWS DMS レプリケーションインスタンスを削除します。

まとめ

この投稿では、PostgreSQL データベースを AWS DMS のソースまたはターゲットとして構成している場合に、アップグレード時に DMS タスクをどのように扱うかについて説明しました。

このソリューションを試してみて、フィードバックや質問をコメントで共有してください。

About the Authors

Veeramani A は Amazon Web Services のクラウドデータベースエンジニアで、AWS Database Migration Service とAmazon RDS for PostgreSQL で SME(Subject Matter Expert)を務めています。15 年以上にわたる多様なデータベーステクノロジーの経験を持つ彼は、AWS へのデータベース移行を進めるお客様に戦略的ガイダンスと技術的専門知識を提供しています。

Manoj Ponnurangam は、Amazon Web Services のクラウドデータベースエンジニアとして働いています。彼はAmazon RDS for Oracle、Amazon RDS for PostgreSQL、AWS DMS の SME(Subject Matter Expert) です。Manoj はリレーショナルデータベースを15 年扱ってきた経験があります。彼はお客様と協力して、さまざまなデータベースや移行プロジェクトに関する指導や技術支援を提供しています。