はじめに

私が保守を担当しているプロジェクトでは、Azure DB for PostgreSQL Single Serverを利用していますが、公式アナウンスの通り、Azure DB for PostgreSQL Single Serverは2025年3月にサービス終了となり、後継のAzure DB for PostgreSQL Flexible Serverへの移行が必要となります。

移行においては、Azure側での自動移行機能等は提供されず、以下の対応が必要となります。

Azureリソース(Azure DB for PostgreSQL Flexible Server)の新規構築
旧サーバ(Single Server)内部に構築したユーザやテーブル、ビューなどのオブジェクトやデータの移行

現在、プロジェクト内では移行対応中であり、その中で知見が溜まってきましたので、共有します。今後移行を予定している方の助けになれば幸いです。

対象読者

Azure DB for PostgreSQL Single Serverを使用中であり、Flexible Serverへの移行を検討している方

主な検討ポイント

移行対応時、主に検討が必要になったポイントは以下です。

インフラ構成
移行方法
移行ツールの仕様
アプリケーション側への影響

以下、順に見ていきます。

インフラ構成

サーバ(高可用性)構成

Single ServerとFlexible Serverでは高可用性に関する考え方が変更されています。

Single Serverにおける高可用性は、「計画外のダウンタイムを検出すると新たなデータベースサーバが自動でプロビジョニングされる」というものでした。

(画像の出典：https://learn.microsoft.com/ja-jp/azure/postgresql/single-server/concepts-high-availability#unplanned-downtime-mitigation)

Flexible Serverにおいては、Primary/Secondaryの2系統をあらかじめプロビジョニングしておき、計画外のダウンタイムが検出された際に自動で系統を切り替える構成が可能になりました。本構成をとると、Secondaryがホットスタンバイのため、障害時のフェイルオーバーにかかる時間を短縮することができます。

(画像の出典：https://learn.microsoft.com/ja-jp/azure/reliability/reliability-postgresql-flexible-server#availability-zone-support)

一方で、Primary系のみのプロビジョニングとする構成も可能で、この場合、Single Server同様に計画外のダウンタイム時は新たなデータベースサーバが自動でプロビジョニングされます。公式ドキュメントではこの構成について「高可用性が無効の構成」のような記載となっており少々混乱しましたが、Single Serverにおける高可用性と同じ動きになります。

移行に伴ってFlexible Serverの「高可用性構成」を採用することも考えられましたが、以下の理由から今回は現行に合わせ、高可用性を「無効」としました。

高可用性「無効」の構成が現行の構成と同等の挙動であり、現行の構成でサービス提供上の支障はない
採用するとランニングコストが約2倍となる(Secondaryのコストが増える)

ネットワーク構成

Flexible ServerではVNetとの接続に関する構成が変更されており、VNetとの接続がある場合は検討ポイントとなります。

Single ServerでVNetと接続するためには、サービスエンドポイントかプライベートエンドポイントが必要でしたが、Flexible Serverでは、VNet内に直接Flexible Serverをプロビジョニングする構成になりました。

VNetへのプロビジョニング時、Flexible Server専用のサブネットが必要となるため、新たにサブネット領域を確保し、その中にプロビジョニングを行いました。

また、VNet内のFlexible ServerへDNSネームによるアクセスをする場合、プライベートDNSゾーンが必要なので、新たに作成しました。

移行方法

移行ツールの選択

移行に使用するツールとして、公式ドキュメントでは「Single to Flex Migration ツール」というAzure公式の移行ツールとPostgreSQLの一般的ツールである「pg_dump/pg_restore」が紹介されています。

公式ドキュメントでも「Single to Flex Migration ツール」の使用が推奨されているため、基本的にはそちらを使用し、移行検証の中でどうしても「Single to Flex Migration ツール」が使用できないケースにあたってしまった場合のみpg_dump/pg_restoreを使用する方針としました。

移行検証の結果、問題がなかったため、「Single to Flex Migration ツール」を使用することとしました。

オンライン移行とオフライン移行

移行中にデータベースを停止しないオンライン移行と停止するオフライン移行が選択できます。一般的にオンライン移行は難易度が高くリスクも大きいのでオフライン移行を選択しました。

「Single to Flex Migration ツール」ではオンライン移行はプレビュー機能になっており、オフライン移行を推奨しています。

移行ツールの仕様

移行対象

「Single to Flex Migration ツール」の移行対象となるデータは以下です。

スキーマ/テーブル/インデックス/プロシージャ/ファンクション等のオブジェクト
テーブルのデータ
ユーザー/ロール、所有権、特権
拡張機能

拡張機能の移行には許可リストの設定が必要な場合があります。

昨年まで「ユーザー/ロール、所有権、特権」は移行の対象外だったのですが、2023年末のアップデートにより対象となりました。ただし、アップデート直後ごろは正常に移行がされない不具合等ありましたので、移行検証時によく確認することをおすすめします。

また、以下はツールの移行対象外のため、Azure Portal/Azure CLI/ARM Template等を使用して別途設定する必要があります。

Azureリソース
- サーバ/ネットワーク構成やアラート等
サーバパラメータ

サーバパラメータに関して、Single ServerとFlexible Serverで以下が異なりますので、確認が必要です。

設定可能なサーバパラメータ
サーバパラメータの初期値

今回は、ARM TemplateとAzure CLIを組み合わせでこれらの設定を自動化しました。

照合順序

Flexible Serverでは照合順序のデフォルトが変更されています

移行ツールを使用すると、Flexible Server側のデフォルトである「en_US.utf8」が適用されます。今回はほぼ影響なしと判断し、照合順序の変更を許容しましたが、変更したくない場合、「pg_dump/pg_restore」等での移行を検討する必要があります。

移行ツールの実行バージョン

こちらは少々困った仕様ではあるのですが、「Single to Flex Migration ツール」は随時アップデートが実施される、かつ移行ツールの実行バージョンを指定することができません。極端なことを言えば、検証を実施した翌日にはツールの挙動が変わってしまう可能性があります。

根本的な対策はありませんが、検証から移行実施までの期間をできるだけ短くすること、日頃から公式ドキュメントを注視しておくことが基本的な対策となります。

アプリケーション側への影響

アプリケーション側への影響は現在確認中ですが、現時点では以下の影響が判明しています。

接続文字列のユーザ名指定

Single Serverの接続文字列のユーザ名を@の形式にする必要がありましたが、Flexible Serverでは@以下の指定が不要になるためアプリケーション側の設定ファイル等の修正が必要になります。

Server	接続文字列のユーザ名	例
Single Server	[user_name]@[server_name]	pg_adm_user@pgServer
Flexible Server	[username]	pg_adm_user

終わりに

データベースの移行というと大変なイメージがありますが、公式ツールがかなりの部分を吸収してくれるため、うまく活用することで作業負荷を軽減できるとおもいます。

今回のプロジェクトでも、実際にツールを使用して開発環境では問題なく移行が完了しています。あとは本番環境の移行を残すのみなので、しっかりとやりきりたいと思います！

本記事が移行検討されている方の助けになれば幸いです！

We Are Hiring!