次の方法で共有

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

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

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

最大接続数

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

製品名 仮想コア メモリ サイズ 最大接続数 最大ユーザー接続数
バースト可能
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 8 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 8 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 8 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) です。

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

max_connections 値の変更

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

ただし、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 の「Number of Database Connections (データベース接続数)」を参照してください。 詳細については、Azure Database for PostgreSQL フレキシブル サーバーの接続パフォーマンスの特定と解決に関する記事を参照してください。

機能制限

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

スケール操作

ストレージ

  • ストレージ サイズを構成した後は、サイズを小さくすることはできません。 必要なストレージ サイズで新しいサーバーを作成し、手動ダンプと復元操作を実行して、データベースを新しいサーバーに移行する必要があります。
  • ストレージの使用率が 95% に達した場合、または使用可能な容量が 5 GiB 未満のどちらかの場合は、ディスクがいっぱいという状況に関連するエラーを回避するために、サーバーが "読み取り専用モード" に自動で切り替わります。 まれに、データの増加率が読み取り専用モードに切り替えるための時間を上回った場合でも、サーバーの記憶域が不足する可能性があります。 ストレージの自動拡張を有効にすると、これらの問題を回避し、ワークロードの需要に基づいてストレージを自動的にスケーリングできます。
  • ストレージ サイズの増加などの処置を事前に行えるように、storage used または storage percent が特定のしきい値を超えた場合のアラート ルールを設定することをお勧めします。 たとえば、ストレージの使用率の割合が 80% を超えた場合のアラートを設定できます。
  • 論理レプリケーションを使っている場合は、対応するサブスクライバーが存在しなくなったら、プライマリ サーバーの論理レプリケーション スロットを削除する必要があります。 それ以外の場合、先行書き込みログ (WAL) ファイルはプライマリに蓄積され、ストレージがいっぱいになります。 ストレージが特定のしきい値を超え、論理レプリケーション スロットが使用されていない場合 (使用できないサブスクライバーが原因)、Azure Database for PostgreSQL フレキシブル サーバーはその未使用の論理レプリケーション スロットを自動的に削除します。 このアクションにより、蓄積された WAL ファイルが解放され、ストレージがいっぱいになったためにサーバーが使用できなくなる状況を回避できます。
  • テーブルスペースの作成はサポートされていません。 データベースを作成する場合は、テーブルスペース名を指定しないでください。 Azure Database for PostgreSQL フレキシブル サーバーは、テンプレート データベースから継承された既定のものを使います。 テーブルスペース (一時的なものなど) を指定することは安全ではありません。なぜなら、そのようなオブジェクトがサーバーの再起動や高可用性 (HA) フェールオーバーなどのイベントの後でも存在し続けること保証できないからです。

ネットワーク

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

高可用性

可用性ゾーン

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

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

  • Postgres 10 以前のバージョンは、オープンソース コミュニティによって廃止されているため、サポートされていません。 これらのバージョンのいずれかを使用する必要がある場合は、古いメジャー バージョン 9.5、9.6、10 をサポートする [Azure Database for 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) 機能の使用時には、その基になるサーバーと同じコンピューティング構成とストレージ構成で、新しいサーバーが作成されます。
  • 仮想ネットワークのデータベース サーバーは、バックアップから復元すると、同じ仮想ネットワークに復元されます。
  • 復元中に作成される新しいサーバーには、元のサーバーに存在していたファイアウォール規則がありません。 新しいサーバー用にファイアウォール規則を別に作成する必要があります。
  • 別のサブスクリプションへの復元は、サポートされていません。 対処法として、同じサブスクリプション内のサーバーを復元してから、復元されたサーバーを別のサブスクリプションに移行できます。

セキュリティ

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

関連するコンテンツ