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

適用対象: 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) です。

max_connections サーバー パラメーターの既定値は、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスをプロビジョニングするときに、そのコンピューティング用に選んだ製品名に基づいて計算されます。 その後、フレキシブル サーバーをサポートするコンピューティングに対する製品選択が変更された場合、そのインスタンスの 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 の「Number of Database Connections (データベース接続数)」を参照してください。 詳細については、Azure Database for PostgreSQL フレキシブル サーバーの接続パフォーマンスの特定と解決に関する記事を参照してください。

機能制限

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

スケール操作

• 現時点では、サーバー ストレージをスケールアップするには、サーバーを再起動する必要があります。
• サーバー ストレージのスケーリングは 2 倍ごとにしか行えません。詳細については、「ストレージ」を参照してください。
• 現在、サーバー ストレージを減らすことはできません。 これを行う唯一の方法は、それをダンプして、新しい 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 などを使用してパブリック インターネットに接続できます。 このアクセスを制限することはできません。 仮想ネットワークのサーバーでは、ネットワーク セキュリティ グループを使用して、送信アクセスを制限することができます。

高可用性

• 「Azure Database for PostgreSQL - フレキシブル サーバーでの高可用性 (信頼性)」を参照してください。

可用性ゾーン

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

関連するコンテンツ

• コンピューティング オプションとして何が利用可能であるかを理解する
• ストレージ オプションとして何が利用可能であるかを理解する
• サポートされている PostgreSQL データベース バージョンについて確認します
• Azure portal を使用して Azure Database for PostgreSQL フレキシブル サーバーでサーバーをバックアップして復元する方法を確認します