適用於 PostgreSQL 的 Azure 資料庫彈性伺服器中的主要版本升級

您的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器支援 PostgreSQL 版本 18、17、16、15、14、13、12、11。 Postgres 社群大約一年會發行一次新的主要版本，其中包含新功能。此外，每個主要版本都會以次要版本的形式收到定期的 BUG 修正。次要版本升級包括與現有應用程式回溯相容的變更。適用於 PostgreSQL 的 Azure 資料庫彈性伺服器會在客戶維護期間定期更新次要版本。

主要版本升級比次要版本升級更複雜。它們可能包含與現有應用程式不向下相容的內部變更和新功能。

您的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器具備可就地對伺服器執行主要版本升級的功能。這項功能簡化升級流程，將使用者和存取伺服器的應用程式中斷降至最低。

就地升級會在升級主要版本之後，保留伺服器名稱和目前伺服器的其他設定。它們不需要資料移轉或變更應用程式連接字串。就地升級的速度比資料移轉更快，而且停機時間更短。

備註

適用於 PostgreSQL 的 Azure 資料庫僅支援原地主要版本升級至目前支援的 PostgreSQL 版本。目標版本必須在升級時由 Azure 官方支援。 Azure 入口網站會阻止選擇不支援的版本，但針對已棄用版本的 API 或 CLI 呼叫會失敗。在啟動主要版本升級前，務必參考 Azure PostgreSQL 版本管理政策以及 upgrade 操作指南。

升級驗證檢查（預覽版）

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器提供升級驗證檢查，協助您在開始重大版本升級之前評估升級準備情況。

升級驗證檢查會針對伺服器執行一系列相容性與設定驗證，以識別可能導致升級失敗或異常行為的條件。常見檢查包括不支援的擴充功能、邏輯複製槽、已準備好的交易、事件觸發器、不支援的物件相依性，以及待處理的重啟設定變更。

驗證流程旨在評估升級準備度，但不啟動實際升級操作。相同的驗證檢查也會在主要版本升級的工作流程中自動執行。這些檢查不會改變伺服器版本、觸發停機或重啟伺服器。在安排生產環境升級時段前，先執行驗證。

驗證完成後，會回傳以下其中一種結果：

未偵測到阻塞問題：升級驗證檢查成功完成，且未發現任何阻礙升級的問題。
偵測到阻塞問題：升級驗證檢查發現一個或多個必須先解決的問題，才能繼續升級。

根據結果，你可以選擇升級，或是修復報告的問題並重新執行驗證。

Limitations

使用升級驗證檢查時，請考慮以下限制：

伺服器狀態必須是 準備就緒。
讀取副本不支援驗證檢查。
當其他伺服器操作已經進行中時，驗證無法執行。
驗證檢查需要連接伺服器上的所有資料庫。無法回應或無法存取的資料庫可能導致驗證失敗。
雖然驗證檢查不會造成停機，但建議在資料庫活動較少時執行。

有關逐步說明，請參見「執行升級驗證檢查（預覽版）」。

升級過程

以下是就地主要版本升級的一些重要考量事項：

在開始升級前，請確保你的伺服器至少有 10-20 個% 空檔儲存空間可用。在升級過程中，暫存日誌檔案和元資料操作可能會增加磁碟使用量。可用空間不足可能會導致升級失敗或回復問題。
在原地進行主要版本升級的過程中，您的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器會執行預檢程序，以識別可能導致升級失敗的潛在問題。
- 如果前置檢查找到任何不相容狀況，則會建立記錄事件，顯示升級前置檢查失敗，並顯示錯誤訊息。
- 如果預檢查成功，適用於 PostgreSQL 的 Azure 資料庫彈性伺服器會在升級開始前停止服務並進行隱式備份。服務可利用此隱含備份，在升級錯誤時將資料庫實例恢復至先前版本。
適用於 PostgreSQL 的 Azure 資料庫彈性伺服器會使用 pg_upgrade 工具就地執行主要版本升級。此服務可彈性略過版本，直接升級至更新版本。
對已啟用高可用性（HA）的伺服器進行就地主要版本升級時，服務會停用 HA、對主要伺服器執行升級，並在升級完成後重新啟用 HA。重新啟用 HA 需要足夠的容量來配置新的備用實例。
大部分擴充功能會在就地主要版本升級期間自動升級至更新版本，但有某些例外狀況。
針對適用於 PostgreSQL 的 Azure 資料庫彈性伺服器進行原地主要版本升級的過程，會自動部署最新支援的次要版本。
升級時間取決於資料庫的大小與複雜度，包括物件數量（資料表、索引、結構）、大型物件及擴充功能。較大或較複雜的工作負載可能會面臨較長的升級時間。
升級前，長時間執行的交易或高工作負載可能增加關閉資料庫所需的時間，並增加升級時間。
就地主要版本升級成功之後，沒有方法可自動還原為舊版。你可以執行時間點復原（PITR），回復到升級前的時間，並將先前的版本還原到新的伺服器。
保護你的適用於 PostgreSQL 的 Azure 資料庫伺服器。在適用於 PostgreSQL 的 Azure 資料庫彈性伺服器進行重大版本升級後，伺服器上第一個被授予管理員選項的使用者，現在擁有其他角色的管理權限，負責必要的維護作業。

升級考量與限制

若在原地主要版本升級過程中預檢查操作失敗，升級過程會停止並顯示詳細錯誤訊息。以下已知限制可能導致升級失敗或出現意外行為：

Important

升級相容性需求會因來源及目標 PostgreSQL 版本而異，且隨時間改變。本節的清單僅供參考，可能無法完全反映你升級路徑的精確檢查。在安排升級之前，請先對您的伺服器執行升級驗證檢查（預覽），以取得目前最新且權威的問題清單，這些問題可能會阻止您的此次升級，包括任何邏輯複寫插槽需求。

不支援的伺服器配置

適用於 PostgreSQL 的 Azure 資料庫中的異地複寫在就地升級期間不受支援。您必須先刪除唯讀複本（包括任何連鎖唯讀複本），才能升級主伺服器。升級之後，您可以重新建立複本。
網路流量規則可能會阻擋升級操作。
- 確保你的彈性伺服器能透過虛擬網路中的 5432 和 6432 埠口，以及 Azure 儲存體（用於日誌歸檔）發送和接收流量。
- 若網路安全群組（NSG）限制此流量，升級後高可用性（HA）不會自動重新啟用。你可能需要手動更新 NSG 規則並重新啟用 HA。
依賴 pg_stat_activity 的視圖在主版本升級期間不受支援。
如果你要從 PostgreSQL 11 升級到更高版本，必須先設定你的彈性伺服器啟用 SCRAM 並重設所有認證角色密碼來使用 SCRAM 認證。

擴充限制

就地主要版本升級不支援所有 PostgreSQL 擴充功能。如果受影響的升級路徑上存在被阻擋的擴展，升級會在預檢查期間失敗。大多數區塊適用於特定的目標（有時也包括來源）版本，而非每次升級；如以下列表所示。

下列擴充功能會封鎖所有升級路徑上的就地主要版本升級。在升級前移除它們，若目標版本支援，升級後再重新啟用： session_variable， anon， age，。
下列擴充功能屬於 非持續性公用程式擴充功能，依既定設計，必須在升級前先移除，並在升級後重新建立（適用於所有升級路徑）：pg_repack、hypopg、pg_partman。

以下擴充功能僅在 特定版本路徑上被封鎖。如果你的升級符合上述條件，請在升級前移除它們，若目標版本支援，則在升級後重新啟用：

Extension	遭封鎖時
`pg_hint_plan`	目標版本是 PostgreSQL 14
`semver`	目標版本為 PostgreSQL 16 或 17
`azure_local_ai`	目標版本為 PostgreSQL 17 或 18
`pg_failover_slots`	目標版本為 PostgreSQL 17 或 18（共用預載函式庫）
`azure_ai`	目標版本為 PostgreSQL 18
`azure_storage`	目標版本為 PostgreSQL 18
`pg_diskann`	目標版本為 PostgreSQL 18
`pgrouting`	目標版本為 PostgreSQL 15;或原始碼早於 PostgreSQL 16，且目標為 PostgreSQL 16 或更新版本;或目標版本為 PostgreSQL 18
`orafce`	原始碼版本為 PostgreSQL 11、12 或 13

當其他資料庫物件 依賴其物件時，以下擴充功能會被阻擋，否則升級會失敗。升級前先解決相依性：
- pg_stat_statements：當其他物件依賴其檢視或函式時，會遭到封鎖，進而導致 ALTER EXTENSION pg_stat_statements UPDATE 失敗。先移除相關物件。
- pgcrypto安裝於 pg_catalog 結構中並從 PostgreSQL 11 或 12 升級至 PostgreSQL 13 或更新版本時，當客戶物件依賴該功能時會被阻擋（與內建 gen_random_uuid() 函式衝突）。先將擴充功能移至另一個結構或移除相關物件。

PostGIS 特定考量事項

如果您使用 PostGIS 或任何相依的擴充功能，請將 search_path 參數設為包含：

與 PostGIS 相關的架構
相依延伸模組，包括：postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch
如果你沒有正確設定 search_path，升級可能會失敗，或在升級後造成物件損毀。

TimescaleDB 專屬考量

如果你使用 TimescaleDB，原生主要版本升級僅支援特定的 PostgreSQL 原始碼與目標版本組合：

來源 PostgreSQL 版本	支援的目標版本
PostgreSQL 11	PostgreSQL 12
PostgreSQL 12	PostgreSQL 13， 14， 15
PostgreSQL 13	PostgreSQL 14， 15， 16
PostgreSQL 14	PostgreSQL 15， 16
PostgreSQL 15	PostgreSQL 16， 17， 18
PostgreSQL 16	PostgreSQL 17， 18
PostgreSQL 17	PostgreSQL 18

如果你的 TimescaleDB 升級路徑沒有在支援矩陣中列出，那麼原有的主版本升級就會被封鎖。若要繼續，若可行，升級前可先放棄 TimescaleDB 擴充功能，或採用邏輯複製的並排遷移等替代遷移方式。

在開始升級前，請確保你的來源版本和目標版本都包含在支援矩陣中。

其他升級考慮

事件觸發程序：升級前預先檢查會封鎖事件觸發程序，因為它們會連接到 DDL 命令，且可能參考在主要版本之間變動的系統目錄。升級前先把所有 EVENT TRIGGERS 丟掉，升級後再重新建立，這樣升級會順利。
大型物件（LO）：升級處理包含數百萬個大型物件（儲存在 pg_largeobject的資料庫）的方式，取決於目標的主要版本：
- 目標 PostgreSQL 15 或更新版本：升級採用優化的批量方法來傳輸大型物件元資料，因此記憶體與暫存磁碟使用不再隨大型物件數量而調整。擁有數千萬甚至數億大型物件的資料庫，能可靠地升級，無需額外準備。不需要事先執行 vacuumlo 或擴充伺服器規模來因應大型物件數量過多的問題，不過基於其他原因，你仍然可以執行 vacuumlo 來移除未使用的大型物件。
- 目標 PostgreSQL 14 或更早版本：擁有數百萬大型物件的資料庫，因記憶體使用量或日誌量過高，可能導致升級失敗。使用 vacuumlo 工具清理未使用的大型物件，若仍有許多大型物件在使用，建議在升級前先擴充伺服器規模。

警告

使用 vacuumlo時請小心。 vacuumlo 會根據傳統參考行 (oid、lo) 識別孤立大型物件。若應用程式使用自訂或間接參考型別，有效的大型物件可能會被誤刪。此外，可能會 vacuumlo 消耗大量 CPU、記憶體和 IOPS，尤其是在擁有數百萬個大型物件的資料庫中。在維護期間執行，並先在非生產環境測試。

升級後

在主要版本升級完成後，在每個資料庫執行該 ANALYZE 指令來刷新資料 pg_statistic 表。遺失或過時的統計數據可能會導致不正確的查詢計劃，進而可能會降低效能並佔用過多的記憶體。

postgres=> analyze;
ANALYZE

檢視升級記錄

使用 PG_Upgrade_Logs 監控升級進度並排除問題。在升級期間及升級後檢視日誌，追蹤進度、診斷故障或延遲，並找出阻塞問題，以便迅速採取修正措施。

啟用使用伺服器日誌參數的升級日誌

設定 logfiles.download_enable 為 ON。
使用logfiles.retention_days設定保留。

請參考下載 PostgreSQL 及升級日誌以開始。

備註

自動移轉的伺服器支援就地主要版本升級。在已自動移轉的伺服器上成功完成就地執行的主要版本升級後，便不再支援使用者名稱格式 username@servername。取而代之的是，使用標準格式： username。若要避免驗證問題，請仔細檢閱並更新應用程式和腳本中的所有連接字串，以確保它們會在升級之後使用更新的用戶名稱格式。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-07-16