你的 Azure 資料庫用於 PostgreSQL 彈性伺服器實例支援 PostgreSQL 版本 18、17、16、15、14、13、12、11。 Postgres 社群大約一年會發行一次新的主要版本，其中包含新功能。 此外，每個主要版本都會以次要版本的形式收到定期的 BUG 修正。 次要版本升級包括與現有應用程式回溯相容的變更。 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體，在客戶的維護期間定期更新次要版本。
主要版本升級比次要版本升級更複雜。 它們可能包含內部變更，以及可能無法與現有應用程式回溯相容的新功能。
適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體具有一項功能，只要按一下即可執行伺服器的就地主要版本升級。 這項功能簡化升級流程，將使用者和存取伺服器的應用程式中斷降至最低。
就地升級會在升級主要版本之後，保留伺服器名稱和目前伺服器的其他設定。 它們不需要資料移轉或變更應用程式連接字串。 就地升級的速度比資料移轉更快，而且停機時間更短。
備註
適用於 PostgreSQL 的 Azure 資料庫僅支援將主要版本就地升級至目前支援的 PostgreSQL 版本。 例如，假設目標版本在升級時受到 Azure 的正式支援，您可以升級目前的版本。 無法選取不支援的版本作為升級目標，而且嘗試升級至已淘汰的版本可能會導致失敗或服務中斷。 在起始主要版本升級之前，請務必先參閱 Azure PostgreSQL 版本設定原則 和 升級檔 。
備註
PostgreSQL 18 的重大版本升級將分階段啟用。 目前，MVU 到 PostgreSQL 18 可在美國中北部及美國西部地區使用。
升級流程
以下是進行就地主要版本升級時一些重要的考慮事項：
- 開始升級之前，請確定您的伺服器至少有 10-20% 可用的可用記憶體。 在升級程式期間，暫存記錄檔和元數據作業可能會增加磁碟使用量。 可用空間不足可能會導致升級失敗或回復問題。
- 在就地主要版本升級過程中，PostgreSQL 的 Azure 資料庫彈性伺服器執行個體會執行預檢程序，以識別可能導致升級失敗的任何潛在問題。
- 如果前置檢查找到任何不相容狀況，則會建立記錄事件，顯示升級前置檢查失敗，並顯示錯誤訊息。
- 如果預先檢查成功，適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體會停止服務，並在開始升級之前進行隱含備份。 如果發生升級錯誤，服務可以使用此備份，將資料庫執行個體還原至其舊版。
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體使用 pg_upgrade 工具執行就地主要版本升級。 此服務可彈性略過版本，直接升級至更新版本。
- 在啟用高可用性的伺服器就地主要版本升級期間，服務會停用HA、在主伺服器上執行升級，然後在升級完成後重新啟用HA。
- 大部分擴充功能會在就地主要版本升級期間自動升級至更新版本，但有某些例外狀況。
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體就地主要版本升級流程會自動部署最新支援的次要版本。
- 進行就地主要版本升級是離線作業，這表示伺服器在升級過程中將無法使用。 雖然大部分的升級會在 15 分鐘內完成，但實際持續時間取決於資料庫的大小和複雜度。 具體而言，所需的時間會與 PostgreSQL 實例中的物件數目（數據表、索引、架構）直接成正比。 較大型或更複雜的架構可能會經歷較長的升級時間。
- 升級前，長時間執行的交易或高工作負載可能增加關閉資料庫所需的時間，並增加升級時間。
- 就地主要版本升級成功之後，沒有方法可自動還原為舊版。 不過，您可以執行時間點復原 (PITR)，將資料庫執行個體恢復到升級之前的狀態，以還原舊版。
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器例項會在升級時拍攝資料庫的快照。 升級開始之前會建立快照集。 如果升級失敗，系統會自動將資料庫從快照集還原至其狀態。
- PostgreSQL 16 引進角色型安全性 措施。 在「適用於 PostgreSQL 的 Azure 資料庫」彈性伺服器執行個體的主要版本升級之後，在獲授與 ADMIN 選項—之伺服器上—建立的第一位使用者，現在對於基本維護作業的其他角色會有系統管理權限。
升級考慮與限制
如果在就地主要版本升級期間預先檢查作業失敗，升級會遭到封鎖，並出現詳細的錯誤訊息。 以下是可能導致升級失敗或非預期行為的已知限制：
不支援的伺服器組態
- 就地升級期間不支援讀取複本。 您必須先刪除唯讀複本（包括任何連鎖唯讀複本），才能升級主伺服器。 升級之後，您可以重新建立複本。
- 網路流量規則可能會封鎖升級作業。
- 請確定您的彈性伺服器執行個體可以在其虛擬網路內的埠 5432 和 6432 上傳送/接收流量，並傳送至 Azure 儲存體 （用於記錄封存）。
- 如果網路安全組 （NSG） 限制此流量，HA 將不會在升級後自動啟用。 您可能需要手動更新 NSG 規則並重新啟用 HA。
- 就地主要版本升級期間不支援邏輯復寫插槽。
- 使用 SSDv2 記憶體的伺服器不符合主要版本升級的資格。
- 主要版本升級期間不支援相依於
pg_stat_activity的檢視。 - 如果要從PG11升級到更高版本，則必須先透過啟用SCRAM並重設所有登入角色密碼，將靈活伺服器配置為使用 SCRAM身份驗證 。
擴充功能限制
就地主要版本升級不支援所有 PostgreSQL 擴充功能。 如果找到不支援的延伸模組，升級會在預先檢查期間失敗。
- 下列延伸模組支援一般使用， 但會封鎖就地主要版本升級 (如果有的話)。 在升級之前移除它們，並在升級之後重新啟用它們（如果目標版本
timescaledb支援）：、dblink、orafce、postgres_fdw、。 - 下列延伸模組是 非持續性公用程式延伸模組 ，需要在設計升級後捨棄並重新建立：
pg_repack，hypopg。 - 升級至 PostgreSQL 17 時，不 支援 下列延伸模組，且必須在升級前移除。 只有在目標版本支援時，您才能重新啟用它們：
age、azure_ai、hll、pg_diskann、pgrouting、。
注意： 如果伺服器參數中 azure.extensions 出現這些擴充套件中的任何一個，則會封鎖升級。 在開始升級之前，請先將其從參數中移除。
PostGIS-Specific 考慮
如果您使用 PostGIS 或任何相依擴充功能，您必須設定search_path伺服器參數以包含：
- 與 PostGIS 相關的架構
- 相依延伸模組，包括：
postgis,postgis_raster,postgis_sfcgal,postgis_tiger_geocoder,postgis_topology,address_standardizer,address_standardizer_data_us,fuzzystrmatch - 無法正確設定 search_path 可能導致升級失敗或升級後物件損壞。
其他升級考慮
- 事件觸發程序：升級前置檢查會封鎖事件觸發程序，因為它們會連結至 DDL 命令，而且可能會參考在主要版本之間變更的系統目錄，請在升級之前卸除所有
EVENT TRIGGER，然後在升級後重新建立它們，以確保順利完成升級。 - 大型物件（LOS）：具有數百萬個大型對象的資料庫（儲存在
pg_largeobject中）可能會導致升級失敗，因為記憶體使用量或記錄磁碟區很高。 使用 vacuumlo 公用程式清除未使用的 LOs，而且如果許多 LOS 仍在使用中，請考慮在升級之前擴大您的伺服器。
警告
請謹慎使用 vacuumlo。
vacuumlo 會根據傳統參考行 (oid、lo) 識別孤立大型物件。 如果您的應用程式使用自定義或間接參考類型，可能會錯誤地刪除有效的大型物件。 此外， vacuumlo 可能會耗用大量的CPU、記憶體和IOPS，特別是在具有數百萬個大型物件的資料庫中。 在維護時段執行它，並先在非生產環境進行測試。
升級後
完成主要版本升級之後，建議您在每個資料庫中執行 ANALYZE 命令來重新整理 pg_statistic 數據表。 遺失或過時的統計數據可能會導致不正確的查詢計劃，進而可能會降低效能並佔用過多的記憶體。
postgres=> analyze;
ANALYZE
檢視升級記錄
主要版本升級記錄 (PG_Upgrade_Logs) 可直接存取詳細伺服器記錄。 將 PG_Upgrade_Logs 整合到升級流程有助於確保，以更順暢透明的方式轉換至新的 PostgreSQL 版本。
您可以使用下列伺服器參數，以與伺服器記錄相同的方式，設定主要版本升級記錄：
- 若要開啟此功能，請將
logfiles.download_enable設定為ON。 - 若要定義記錄檔的保留天數，請使用
logfiles.retention_days。
設定升級記錄
若要開始使用 PG_Upgrade_Logs，您可以設定 PostgreSQL 伺服器記錄和主要版本升級記錄的擷取。
您可以透過伺服器記錄的 UI 存取升級記錄。 您可以在那裡即時監視 PostgreSQL 主要版本升級的進度和詳細資料。 此 UI 提供檢視記錄的集中式位置，讓您更輕鬆追蹤和疑難排解升級流程。
使用升級記錄的優點
-
洞察性的診斷：
PG_Upgrade_Logs提供升級流程的重要見解。 它會擷取所執行作業的相關詳細資訊，並醒目提示任何發生的錯誤或警告。 此等級的詳細資料有助於診斷和解決升級期間可能發生的問題，讓轉換更順暢。 - 簡化的疑難排解：透過直接存取這些記錄，您可以快速找出並解決潛在的升級障礙、減少停機時間，並將對作業的影響降到最低。 記錄可以更有效率且有效的方式解決問題，作為重要的疑難排解工具。
備註
自動移轉的伺服器支援就地主要版本升級。 在自動移轉伺服器上成功就地進行主要版本升級之後，將不再支援使用者名稱格式 username@servername 。 相反地，您必須使用標準格式： username。 若要避免驗證問題，請仔細檢閱並更新應用程式和腳本中的所有連接字串，以確保它們會在升級之後使用更新的用戶名稱格式。