Azure Database for PostgreSQL の制限

以降のセクションでは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの容量と機能の制限について説明します。 リソース (コンピューティング、メモリ、ストレージ) レベルについて知りたい場合は、「コンピューティング」と「ストレージ」の記事を参照してください。

最大接続数

次の表に、各価格レベルと仮想コア構成の "既定の" 最大接続数を示します。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの物理レプリケーションと監視のために 15 個の接続を予約します。 そのため、このテーブルでは、最大接続数から最大ユーザー接続数の値が 15 減少します。

現在 15 の予約済み接続スロットは変更される可能性があります。 サーバー上の予約済み接続数の合計を定期的に確認することをお勧めします。 この数値は、reserved_connections と superuser_reserved_connections のサーバー パラメーターの値を合計することによって計算します。 使用できる最大ユーザー接続数は max_connections - (reserved_connections + superuser_reserved_connections) です。

システムは、コンピューティング用に選択した製品名に基づいて、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、 max_connections サーバー パラメーターの既定値を計算します。 インスタンスをサポートするコンピューティングに対する製品選択の後続の変更は、そのインスタンスの max_connections サーバー パラメーターの既定値には影響しません。 インスタンスに割り当てられている製品を変更するたびに、前の表の値に従って max_connections パラメーターの値も調整することをお勧めします。

max_connections 値の変更

Azure Database for Postgres フレキシブル サーバーのインスタンスを初めて設定するときに、同時に処理できる接続の最大数が自動的に決定されます。 サーバーの構成によってこの数が決まりますが、変更することはできません。

ただし、max_connections 設定を使用して、特定の時点で許可される接続の数を調整することはできます。 この設定を変更した後、新しい制限が機能するには、サーバーを再起動する必要があります。

接続数が制限を超えると、次のエラーが表示される場合があります。

FATAL: sorry, too many clients already.

多数の同時接続があるビジー状態のデータベースに対して Azure Database for PostgreSQL フレキシブル サーバー インスタンスを使用している場合、リソースに大きな負担がかかる可能性があります。 この負荷により、CPU 使用率が高くなる可能性があります。特に、多くの接続が同時に確立されている場合や、接続の期間が短い (60 秒未満) 場合です。 これらの要因は、接続と切断の処理に費やされる時間を長くすることで、データベースの全体的なパフォーマンスに悪影響を与える可能性があります。

Azure Database for PostgreSQL フレキシブル サーバー インスタンス内の各接続は、アイドル状態かアクティブかに関係なく、データベースから大量のリソースを消費します。 この消費は、CPU 使用率の上昇だけでなく、ディスクやロックの競合といったパフォーマンス上の問題を引き起こす可能性があります。 PostgreSQL Wiki のデータベース接続数 に関する記事では、この記事について詳しく説明しています。 詳細については、 Azure Postgres での接続パフォーマンスの特定と解決に関するページを参照してください。

機能制限

次のセクションでは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスでサポートされる内容とサポートされない内容に関する考慮事項を示します。

スケール操作

• 現時点では、サーバー ストレージをスケールアップするには、サーバーを再起動する必要があります。
• サーバー ストレージは、2 倍の増分でのみスケーリングできます。 詳細については、「 ストレージ」 を参照してください。
• 現在、サーバーストレージサイズの縮小はサポートされていません。 この操作を行う唯一の方法は、新しい Azure Database for PostgreSQL フレキシブル サーバー インスタンスに ダンプして復元 することです。

Storage

• ストレージ サイズを構成した後は、サイズを小さくすることはできません。 必要なストレージ サイズで新しいサーバーを作成し、手動ダンプと復元操作を実行して、データベースを新しいサーバーに移行する必要があります。
• 記憶域の使用量が 95% に達した場合、または使用可能な容量が 5 GiB (いずれか大きい方) 未満の場合、システムは自動的にサーバーを 読み取り専用モード に切り替えて、ディスク全体の状況に関連するエラーを回避します。 まれに、データの増加率が読み取り専用モードへの切り替えにかかる時間を上回ると、サーバーの記憶域が不足する可能性があります。 ストレージの自動拡張を有効にすると、これらの問題を回避し、ワークロードの需要に基づいてストレージを自動的にスケーリングできます。
• ストレージ サイズの増加などの処置を事前に行えるように、storage used または storage percent が特定のしきい値を超えた場合のアラート ルールを設定することをお勧めします。 たとえば、ストレージの使用率の割合が 80% を超えた場合のアラートを設定できます。
• 論理レプリケーションを使っている場合は、対応するサブスクライバーが存在しなくなったら、プライマリ サーバーの論理レプリケーション スロットを削除する必要があります。 それ以外の場合、先行書き込みログ (WAL) ファイルはプライマリに蓄積され、ストレージがいっぱいになります。 ストレージが特定のしきい値を超え、論理レプリケーション スロットが使用されていない場合 (サブスクライバーが使用できないため)、Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、その未使用の論理レプリケーション スロットを自動的に削除します。 このアクションにより、蓄積された WAL ファイルが解放され、ストレージがいっぱいになるため、サーバーが使用できなくなります。
• テーブルスペースの作成はサポートされていません。 データベースを作成する場合は、テーブルスペース名を指定しないでください。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、テンプレート データベースが継承する既定のテーブルスペースを使用します。 テーブルスペース (一時的なものなど) を指定することは安全ではありません。なぜなら、そのようなオブジェクトがサーバーの再起動や高可用性 (HA) フェールオーバーなどのイベントの後でも存在し続けること保証できないからです。
• 孤立したデータ ファイルとディスクの使用量の不一致: まれに、PostgreSQL はディスク上の孤立したデータ ファイル (データベースのシステム カタログ (すべてのテーブルとデータを追跡する) に対応するエントリを持たないファイル) を残す可能性があります。 これは、(サーバーのクラッシュや中断など) 正常に完了できなかったトランザクション内でテーブルが作成され、設定された場合に、データベースで報告されるサイズと実際のディスク使用量が一致しない場合に発生する可能性があります。 この動作は PostgreSQL コミュニティ コードベースからのものであり、Azure に固有のものではありません。 PostgreSQL コミュニティはこの問題を認識しており、今後のリリースで自動クリーンアップの機能強化を検討しています。 詳細については、「PostgreSQL: PostgreSQL の孤児ファイル」を参照してください。 これにより、ディスクまたはストレージの使用量が予期せず高くなる可能性があります。
  • 検出方法: データベースから報告されたサイズ ( SELECT pg_database_size('your_database') などのクエリを使用) と Azure portal のメトリック を実際のディスク使用量と比較します。 大きな不一致がある場合は、孤立したファイルが原因である可能性があります。 そうすれば：
    • 影響を受けるテーブルに 対して VACUUM FULL を実行して領域を再利用します (注: これはリソースを大量に消費し、テーブル ロックが必要であり、ダウンタイムが必要になる場合があります)。
    • または、ダウンタイムなしで再編成のために pg_repack 拡張機能や pg_squeeze 拡張機能などのツールを使用しますが、最初に非運用環境でテストします。
    • ディスク使用量のしきい値については 、Azure portal のメトリック を使用して監視します。 問題が解決しない場合、または不明な場合は、Azure サポートにお問い合わせください。
  • 防ぐ方法: 不完全な操作を最小限に抑えるために、アプリケーションでトランザクションが適切に管理されていることを確認します。 Azure portal メトリックを使用してディスクの使用状況を定期的に監視します。 サポートされている最新の PostgreSQL バージョンにアップグレードすると、関連する問題に関するコミュニティの修正プログラムが含まれる場合があります。

ネットワーク

• 現在、仮想ネットワークとの間の移動はサポートされていません。
• 現在、パブリック アクセスと仮想ネットワークでのデプロイの組み合わせはサポートされていません。
• 仮想ネットワークでは、ファイアウォール規則はサポートされていません。 代わりに、ネットワーク セキュリティ グループを使用できます。
• パブリック アクセス データベース サーバーは、postgres_fdw などを使用してパブリック インターネットに接続できます。 このアクセスを制限することはできません。 仮想ネットワークのサーバーでは、ネットワーク セキュリティ グループを使用して、送信アクセスを制限することができます。

高可用性

• 高可用性の制限事項を参照してください。

可用性ゾーン

• 現在、サーバーを別の可用性ゾーンに手動で移動することはサポートされていません。 ただし、優先可用性ゾーンをスタンバイ ゾーンとして使用すると、HA を有効にすることができます。 スタンバイ ゾーンを確立したら、それにフェールオーバーしてから HA をオフにすることができます。

Postgres エンジン、拡張機能、PgBouncer

• Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、パーティション分割、論理レプリケーション、外部データ ラッパーなど、PostgreSQL エンジンのすべての機能をサポートします。
• Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、すべての contrib 拡張機能をサポートしています。 詳細については、PostgreSQL の拡張機能に関するページをご覧ください。
• バースト可能なサーバーは、現在、組み込みの PgBouncer 接続プーラーにアクセスできません。

停止/開始操作

• Azure Database for PostgreSQL フレキシブル サーバー インスタンスを停止すると、7 日後に自動的に開始されます。

予定メンテナンス

• カスタム メンテナンス期間は、任意の曜日や時刻に変更できます。 ただし、メンテナンス通知を受け取った後に行った変更は、次回のメンテナンスには影響しません。 変更が有効になるのは、その後の予定された月次メンテナンス時になります。

サーバーのバックアップ

• バックアップは、システムによって管理されます。 現在、バックアップを手動で実行することはできません。 代わりに pg_dump を使用することをお勧めします。

• 最初のスナップショットは完全バックアップであり、連続するスナップショットは差分バックアップです。 差分バックアップでは、前回のスナップショット バックアップ以降に変更されたデータのみがバックアップされます。

  たとえば、データベースのサイズが 40 GB で、プロビジョニングされたストレージが 64 GB の場合、最初のスナップショット バックアップは 40 GB です。 4 GB のデータを変更した場合、次の差分スナップショット バックアップ サイズは 4 GB になります。 トランザクション ログ (先書きログ) は、完全/差分バックアップとは別個であり、継続的にアーカイブされます。

サーバーの復元

• ポイントインタイム リストア (PITR) 機能を使用している場合、システムは、基になっているサーバーと同じコンピューティング構成とストレージ構成で新しいサーバーを作成します。
• バックアップから復元すると、システムは仮想ネットワーク内のデータベース サーバーを同じ仮想ネットワークに復元します。
• 復元中に作成される新しいサーバーには、元のサーバーに存在していたファイアウォール規則がありません。 新しいサーバー用にファイアウォール規則を別に作成する必要があります。
• 別のサブスクリプションへの復元はサポートされていません。 対処法として、同じサブスクリプション内のサーバーを復元してから、復元されたサーバーを別のサブスクリプションに移行できます。

セキュリティ

• Postgres 14 以降のバージョンでは MD5 ハッシュが無効になり、システムは SCRAM-SHA-256 メソッドのみを使用してネイティブ Postgres パスワードをハッシュします。

関連コンテンツ

• Azure Database for PostgreSQL のコンピューティング オプション。
• Azure Database for PostgreSQL のストレージ オプション。
• Azure Database for PostgreSQL でサポートされている PostgreSQL のバージョン。