在適用於 PostgreSQL 的 Azure 資料庫彈性伺服器中調整資源

適用範圍：適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器同時支援垂直和水平調整選項。

垂直調整：您可以將更多資源新增至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器實例，例如增加實例指派的 CPU 和記憶體數目，以垂直調整。實例的網路輸送量取決於您為CPU和記憶體選擇的值。

建立適用於 PostgreSQL 的 Azure 資料庫彈性伺服器實例之後，您可以獨立變更：

虛擬核心數目可以相應增加或減少，但記憶體大小只能增加。您也可以將備份保留期間從 7 到 35 天相應增加或減少。例如，可以使用多個工具調整資源，例如 Azure 入口網站或 Azure CLI。

注意

增加記憶體大小之後，就無法回到較小的記憶體大小。

水平調整：您可以藉由建立讀取複本來水平調整。讀取複本可讓您將讀取工作負載調整為個別適用於 PostgreSQL 的 Azure 資料庫彈性伺服器實例。它們不會影響主要實例的效能和可用性。

當您變更虛擬核心或計算層的數目時，實例會重新啟動，讓新的伺服器類型生效。在此期間，系統會切換至新的伺服器類型。無法建立任何新的連線，而且會回復所有未認可的交易。

重新啟動伺服器的整體時間取決於重新啟動時的當機復原程式和資料庫活動。重新啟動通常需要一分鐘或更少時間，但可能需要幾分鐘的時間。時間取決於起始重新啟動時的交易活動。

如果您的應用程式對計算調整期間可能發生的即時交易遺失很敏感，建議您實作交易重試模式。

在大部分情況下，調整記憶體不需要重新啟動伺服器。同樣地，備份保留期間變更是在線作業。若要改善重新啟動時間，建議您在離峰時段執行調整作業。這種方法可縮短重新啟動資料庫伺服器所需的時間。

近乎零的停機時間調整

近乎零的停機時間調整是一項功能，其設計目的是在修改記憶體和計算層時將停機時間降到最低。如果您修改虛擬核心數目或變更計算層，伺服器就會重新啟動以套用新的組態。在此轉換至新伺服器期間，無法建立任何新的連線。

一般而言，此程式可能需要 2 到 10 分鐘的定期調整。有了新的近零停機時間調整功能，此持續時間會縮減為少於 30 秒。在調整資源期間減少停機時間，可改善資料庫實例的整體可用性。

當您在調整案例中更新適用於 PostgreSQL 的 Azure 資料庫彈性伺服器實例時，我們會使用更新的組態來建立伺服器（VM）的新複本。我們會將其與您的目前復本同步處理，並切換至新的複本，並中斷 30 秒。然後，我們會淘汰舊的伺服器。此程式完全不需額外費用。

此程式允許順暢的更新，同時將停機時間降到最低，並確保成本效益。當對記憶體和計算層進行變更時，就會觸發此調整程式。高可用性和非HA伺服器的體驗仍保持一致。此功能已在所有 Azure 區域中啟用。 使用這項功能不需要 客戶採取任何動作。

針對已設定讀取複本的伺服器，調整作業必須遵循特定順序，以確保數據一致性並將停機時間降到最低。如需該順序的詳細資訊，請參閱使用讀取複本進行調整。

注意

接近零的停機時間調整程式是預設作業。遇到下列限制時，系統會切換為一般調整，相較於接近零的停機時間調整，這牽涉到更多的停機時間。

停機時間持續時間：在大部分情況下，停機時間範圍從 10 到 30 秒。
其他考慮：調整事件之後，會有大約 30 秒的固有 DNS Time-To-Live （TTL）期間。此期間不會由調整程式直接控制。這是 DNS 行為的標準部分。從應用程式的觀點來看，調整期間發生的總停機時間可能介於 40 到 60 秒之間。

若要讓接近零的停機時間調整運作，請在使用虛擬網路整合式網路時，啟用委派子網中IP之間的所有輸入/輸出連線。如果未啟用這些連線，接近零的停機時間調整程式將無法運作，而且會透過標準調整工作流程進行調整。
如果客戶訂用帳戶有區域容量限制或配額限制，則近乎零的停機時間調整無法運作。
幾乎零的停機時間調整不適用於複本伺服器，因為它只在主伺服器上受到支援。對於複本伺服器，它會自動經過一般調整程式。
如果具有委派子網的虛擬網路插入伺服器沒有足夠的可用IP位址，則近乎零的停機時間調整無法運作。如果您有獨立伺服器，則需要一個額外的IP位址。若為已啟用HA的伺服器，則需要兩個額外的IP位址。
邏輯複寫位置不會在接近零的停機時間故障轉移事件期間保留。若要維護邏輯復寫位置，並確保調整作業之後的數據一致性，請使用 pg_failover_slot 擴充功能。如需詳細資訊，請參閱在彈性伺服器中啟用擴充功能。
針對已啟用HA的伺服器，目前已針對一組有限的區域啟用接近零的停機時間調整。系統會根據區域容量，分階段啟用更多區域。