Azure Database for PostgreSQL フレキシブル サーバーの制限

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

最大接続数

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

製品名 vCores メモリ サイズ 最大接続数 最大ユーザー接続数
バースト可能
B1ms 1 2 GiB 50 35
B2s 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1,718 1,703
B8ms 八 32 GiB 3,437 3,422
B12ms 12 48 GiB 5,000 4,985
B16ms 16 64 GiB 5,000 4,985
B20ms 20 80 GiB 5,000 4,985
汎用
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3/D4ds_v4/D4ds_v5/D4ads_v5 4 16 GiB 1,718 1,703
D8s_v3/D8ds_V4/D8ds_v5/D8ads_v5 八 32 GiB 3,437 3,422
D16s_v3/D16ds_v4/D16ds_v5/D16ads_v5 16 64 GiB 5,000 4,985
D32s_v3/D32ds_v4/D32ds_v5/D32ads_v5 32 128 GiB 5,000 4,985
D48s_v3/D48ds_v4/D48ds_v5/D48ads_v5 48 192 GiB 5,000 4,985
D64s_v3/D64ds_v4/D64ds_v5/D64ads_v5 64 256 GiB 5,000 4,985
D96ds_v5/D96ads_v5 96 384 GiB 5,000 4,985
メモリ最適化
E2s_v3/E2ds_v4/E2ds_v5/E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3/E4ds_v4/E4ds_v5/E4ads_v5 4 32 GiB 3,437 3,422
E8s_v3/E8ds_v4/E8ds_v5/E8ads_v5 八 64 GiB 5,000 4,985
E16s_v3/E16ds_v4/E16ds_v5/E16ads_v5 16 128 GiB 5,000 4,985
E20ds_v4/E20ds_v5/E20ads_v5 20 160 GiB 5,000 4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5,000 4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5,000 4,985
E64s_v3/E64ds_v4/E64ds_v5/E64ads_v5 64 432 GiB 5,000 4,985
E96ds_v5/E96ads_v5 96 672 GiB 5,000 4,985

現在 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 PostgreSQLフレキシブル サーバーを設定すると、処理できる同時接続の最大数が自動的に決定されます。 サーバーの構成によってこの数が決まりますが、変更することはできません。

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

注意事項

max_connections の値を既定の設定を超えて増やすことは可能ですが、お勧めしません。

ワークロードが拡大し、より多くのメモリが必要になったときに、インスタンスで問題が発生する可能性があります。 接続の数が増えると、メモリ使用量も増加します。 メモリが限られているインスタンスで、クラッシュや長い待機時間などの問題が発生する可能性があります。 ほとんどの接続がアイドル状態の場合は、より高い max_connections の値が許容される場合がありますが、アクティブになるとパフォーマンスに大きな問題が発生することがあります。

さらに接続が必要になった場合は、代わりに、接続プール管理用の組み込みの Azure ソリューションである PgBouncer を使用することをお勧めします。 これは、トランザクション モードで使用してください。 最初は、2 から 5 の範囲内で仮想コアを乗算して控えめな値を使用することをお勧めします。 その後、リソース使用率とアプリケーションのパフォーマンスを慎重に監視して、円滑な運用を確保してください。 PgBouncer の詳細については、 Azure Database for PostgreSQL の PgBouncer に関するページを参照してください。

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

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

セキュリティ

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

関連コンテンツ

  • 最終更新: