下列各節說明適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體的容量和功能限制。 如果您想要了解資源 (計算、記憶體、儲存體) 層，請參閱計算和儲存體文章。
最大連線數
下表顯示每個定價層和 V 核心設定預設連線數目上限。 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體會保留 15 個連線，以進行適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體的實體複寫和監視。 因此，表格會將使用者連線數上限的值從連線總數上限減少 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)。
當您佈建適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體時，系統會根據您為其計算選取的產品名稱，計算伺服器參數的 max_connections 預設值。 即使您更改產品選擇，使其符合支援該執行個體的計算資源，也不會影響該執行個體的伺服器參數 max_connections 的預設值。 我們建議您每當變更指派給執行個體的產品時，也會根據上表中的值來調整 max_connections 參數的值。
變更 max_connections 值
當您第一次設定適用於 Postgres 的 Azure 資料庫彈性伺服器執行個體時，它會自動決定可同時處理的連線數目上限。 您的伺服器配置決定了這個數字，您無法更改它。
不過，您可以使用 max_connections 設定來調整特定時間允許的連線數目。 變更此設定之後，您必須重新啟動伺服器，新的限制才能開始運作。
注意
雖然有可能將 max_connections 的值提高到預設設定之上，但我們建議不要。
當工作負載擴充並要求更多記憶體時，執行個體可能會遇到困難。 隨著連線數目增加，記憶體使用量也會增加。 記憶體有限的執行個體可能會遇到當機或高延遲等問題。 雖然當大部分連線處於閑置狀態時，max_connections 值可能可以接受，但在它們變成作用中之後，可能會導致顯著的效能問題。
如果您需要更多連線，建議您改用 PgBouncer，這是連線集區管理的內建 Azure 解決方案。 在交易模式中使用它。 若要開始，建議您使用保守的值，方法是在 2 到 5 的範圍內乘以虛擬核心。 之後，請仔細監視資源使用率和應用程式效能，以確保作業順暢。 如需 PgBouncer 的詳細資訊，請參閱 適用於 PostgreSQL 的 Azure 資料庫中的 PgBouncer。
當連線超過限制時，您可能會收到下列錯誤：
FATAL: sorry, too many clients already.
當您使用 Azure Database for PostgreSQL 的彈性伺服器執行個體來處理具有大量並行連線的繁忙資料庫時，資源可能會受到重大壓力。 這種壓力可能會導致高 CPU 使用率，特別是在同時建立許多連線，以及連線持續時間很短時 (少於 60 秒)。 這些因素可能會藉由增加處理連線和中斷連線所花費的時間，對整體資料庫效能造成負面影響。
適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體中的每個連線，無論其是閒置還是作用中，都會耗用資料庫中的大量資源。 此耗用量可能會導致效能問題超出高 CPU 使用率，例如磁碟和鎖定爭用。 PostgreSQL Wiki 上的 資料庫連線數 一文更詳細地討論了這篇文章。 若要深入瞭解，請參閱 識別和解決 Azure Postgres 中的連線效能。
功能限制
下列各節列出適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體不支援的考量項目。
調整作業
- 這時，調整伺服器儲存體需要重新啟動伺服器。
- 伺服器儲存體只能以 2 倍的增量進行擴展。 如需詳細資訊，請參閱儲存。
- 我們目前不支援減少伺服器儲存空間大小。 執行這項操作的唯一方法是將其匯出並還原到新的適用於 PostgreSQL 的 Azure Database 彈性伺服器實例。
儲存體
- 設定儲存大小之後，就無法加以縮減。 您必須建立具有所需儲存大小的新伺服器、手動執行傾印和還原作業，並將資料庫移轉至新的伺服器。
- 當儲存體使用量達到 95% 或可用容量小於 5 GiB （以較大者為準） 時，系統會自動將伺服器切換至 唯讀模式 ，以避免與磁碟已滿狀況相關聯的錯誤。 在極少數情況下，如果資料成長速度超過切換到唯讀模式所需的時間，您的伺服器可能仍會用盡儲存體。 您可以啟用儲存體自動成長，以避免這些問題，並根據工作負載需求自動調整儲存體。
- 建議您針對
storage used或storage percent設定超過特定閾值的警示規則，以便主動採取動作，例如增加儲存大小。 例如，您可以設定儲存體百分比超過 80% 使用量的警示。 - 如果您使用的是邏輯複寫，且對應的訂閱者已不存在，您必須卸載主要伺服器中的邏輯複寫位置。 否則，預先寫入記錄 (WAL) 檔案會累積在主要伺服器中，並填滿儲存體。 如果儲存體超過特定閾值，而且邏輯複寫位置不在使用中 (因為訂閱者無法使用)，則適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體會自動卸載未使用的邏輯複寫位置。 此操作會釋放累積的 WAL 檔案，並防止您的伺服器因儲存空間已滿而變得不可用。
- 我們不支援建立資料表空間。 如果您要建立資料庫，請勿提供資料表空間名稱。 Azure Database for PostgreSQL 的彈性伺服器執行個體使用範本資料庫所繼承的預設資料表空間。 提供資料表空間就像暫存的資料表空間不安全，因為我們無法確保這類物件會在伺服器重新啟動和高可用性 (HA) 容錯轉移等事件之後保持持續性。
- 孤兒資料檔案與磁碟使用差異：在極少數情況下，PostgreSQL 可能會在磁碟上留下孤兒資料檔案——這些檔案在資料庫的系統目錄中已不再有對應的條目（該目錄追蹤所有資料表與資料）。 這種情況可能發生在一個交易中建立並填充的表格，但交易未能成功完成（例如伺服器當機或中斷），導致資料庫報告的大小與實際磁碟使用量不符。 這種行為來自 PostgreSQL 社群的程式碼庫，並非 Azure 特有。 PostgreSQL 社群已注意到此問題，並正探索未來版本自動清理的強化方案。 更多細節請參見： PostgreSQL：PostgreSQL 中的孤兒檔案。 這可能導致硬碟或儲存空間的消耗意外增加。
- 如何偵測：將資料庫報告的大小（例如使用
SELECT pg_database_size('your_database')查詢）與 Azure 入口網站的磁碟使用指標進行比較。 如果有明顯的差異，可能是孤兒檔案造成的。 如果是這樣：- 在受影響的資料表上執行 VACUUM FULL 以回收空間（注意：這很耗資源，需要鎖定資料表，且可能需要停機時間）。
- 或者，可以使用像 pg_repack 或 pg_squeeze 擴充功能這類工具進行無停機的重組，但先在非生產環境測試。
- 透過 Azure Portal 的系統指標監控磁碟使用閾值。 如果問題持續存在或不確定，請聯絡 Azure 支援尋求協助。
- 如何預防：確保您的應用程式中交易妥善管理，以減少不完整的操作。 定期透過 Azure 入口網站的指標監控磁碟使用情況。 升級至最新支援的 PostgreSQL 版本時，可能會包含社群針對相關問題的修正。
- 如何偵測：將資料庫報告的大小（例如使用
網路
- 我們目前不支援移入和移出虛擬網路。
- 我們目前不支援將公用存取與虛擬網路中的部署結合。
- 虛擬網路不支援防火牆規則。 您可以改用網路安全性群組。
- 公用存取資料庫伺服器可以連線到公用網際網路，例如透過
postgres_fdw。 您無法限制此存取。 虛擬網路中的伺服器可以透過網路安全性群組限制輸出存取。
高可用性
- 請參閱 高可用性限制。
可用性區域
- 我們目前不支援手動將伺服器移至不同的可用性區域。 不過，藉由使用慣用的可用性區域作為待命區域，您可以開啟高可用性。 建立待命區域之後，您可以容錯轉移至該區域，然後關閉高可用性。
Postgres 引擎、延伸模組和 PgBouncer
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體支援 PostgreSQL 引擎的所有功能，包括資料分割、邏輯複寫和外部資料包裝函式。
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器支援所有
contrib延伸模組及其他擴展。 如需詳細資訊，請參閱 PostgreSQL 擴充功能。 - 可高載伺服器目前無法存取內建的 PgBouncer 連線共用工具。
停止/啟動作業
- 停止適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體之後，它會在 7 天後自動啟動。
排程維護
- 您可以將自訂維護視窗變更為一週的任何一天/時間。 不過，在收到維護通知之後所做的任何變更都不會影響下一個維護。 變更只會在下列每個月的排程維護中生效。
伺服器備份
系統會管理備份。 您目前無法手動執行備份。 我們建議您改用
pg_dump。第一個快照集是完整備份，而連續快照集是差異備份。 差異備份只會備份上次快照集備份之後的已變更資料。
例如，如果您的資料庫大小為 40 GB，而佈建的儲存體為 64 GB，則第一個快照備份為 40 GB。 現在，如果您變更 4 GB 的資料，則下一個差異快照集備份大小只會是 4 GB。 交易記錄 (預先寫入記錄) 會與完整/差異備份分開，並且會持續封存。
伺服器還原
- 當您使用時間點還原 （PITR） 功能時，系統會建立具有與其所基於的伺服器相同的計算和儲存體組態的新伺服器。
- 當您從備份還原時，系統會將虛擬網路中的資料庫伺服器還原至相同的虛擬網路。
- 在還原期間建立的新伺服器不會有原始伺服器中的防火牆規則。 您必須為新的伺服器個別建立防火牆規則。
- 我們不支援還原至其他訂用帳戶。 因應措施是，您可以將相同訂用帳戶內的伺服器還原，然後將還原的伺服器移轉至不同的訂用帳戶。
安全性
- Postgres 14及更高版本禁用MD5雜湊，系統僅使用SCRAM-SHA-256方法對本機Postgres密碼進行雜湊。