待審查的擴充功能與邏輯複製物件

在升級前，請確認以下事項：

pg_repack

請在升級前刪除 pg_repack ，並在升級後重新建立該資料夾。 pg_repack 使用特定版本的擴充套件，其客戶端與伺服器元件必須與 PostgreSQL 的主要版本相符。

DROP EXTENSION pg_repack;

請僅在升級後，若您的工作負載仍需使用該擴充功能時，才重新建立該擴充功能。

CREATE EXTENSION pg_repack;

old_snapshot

請在升級前刪除 old_snapshot 。 請勿在升級至 PostgreSQL 18後重新建立該項目，因為該項目已不再受支援。

DROP EXTENSION old_snapshot;

wal2json 複製槽

若您使用 wal2json 進行邏輯解碼，則必須在升級前刪除所有相關的複製槽。 pg_upgrade 工具嚴格禁止在存在複製槽的情況下進行主要版本升級，並會拋出嚴重錯誤並中止升級。

升級前：

1. 請確保所有待處理的 WAL 資料均已處理完畢。
2. 請停止使用該複製槽的應用程式。
3. 移除複製槽：

SELECT pg_drop_replication_slot('your_slot_name');

升級完成後，您可以根據需要重新建立複製槽。 請注意，wal2json 並非透過 CREATE EXTENSION 進行安裝，而是透過資料庫參數（wal_level、max_replication_slots、max_wal_senders ）及資料表權限進行設定，這些設定並不會阻礙系統升級。

anon

請在升級前移除「anon」擴充功能，若升級後仍需使用，請重新啟用該擴充功能。 在解除安裝「anon」之前，還需執行其他步驟。

若已安裝 anon 擴充套件，請在執行升級前完成以下步驟，並以管理員身分執行相關指令。

1. 移除所有遮蔽規則（若已啟用）。

   SELECT anon.remove_masks_for_all_columns();
   

2. 停用角色遮罩（如果任何角色被標記為遮罩，升級可能會失敗）。

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. 使用 cascade 選項刪除 anon 延伸。

   DROP EXTENSION anon CASCADE;
   

4. 如果「anon」擴充套件已安裝在同一執行個體內的多個資料庫中，請針對每個資料庫完成所述步驟。

5. 升級完成後，請重新啟用 anon 擴充套件，並視需要重新套用遮罩規則。

強烈建議在執行升級之前，先驗證刪除延伸功能之前和之後的資料，以確保遮罩的一致性。

PostGIS

如果您使用的是 PostGIS,，請先升級 PostGIS，再升級 PostgreSQL。

SELECT postgis_extensions_upgrade();

使用下列查詢驗證 PostGIS 延伸升級。

SELECT postgis_full_version();

Logical replication slots

請在升級前刪除所有邏輯複製槽，並在升級後重新建立它們。 邏輯槽位與來源伺服器的狀態相關聯，應在升級後的執行個體上重新建立，並確保其狀態為乾淨的初始狀態。

SELECT pg_drop_replication_slot('<slot_name>');

開始之前

在開始升級程序之前，請考慮以下幾方面。

• 請透過使用者介面 (UI)、API、命令列介面 (CLI) 或 Terraform 檢查部署功能資訊，以確認您的部署版本是否可進行版本升級。

  範例：使用 CLI 查詢版本升級資訊：

  ibmcloud cdb capability-show versions postgresql
  

• 在觸發 IPU 之前，請務必詳閱本主題中與預檢相關的要求。 IPU 直接在原始部署環境上運行，不會建立新的執行個體。 為確保客戶安全，本服務會在升級開始前執行預先檢查，若偵測到風險，將阻止該操作。 請特別確認以下事項：

  • 您的部署最多包含 3 名成員。
  • 您的部署狀態正常。
  • 您的部署環境中至少有 10% 的可用磁碟空間。 IPU 預檢的預設最大允許磁碟使用率為 90%。
  • 您的部署並未面臨嚴重的 I/O 壓力。 IPU 預檢查的預設最大允許 I/O 使用率為 90%。
  • 您的資料庫結構大小和物件數量均在預檢的預設閾值範圍內。 預設情況下，單一資料庫結構的大小不得超過 100 GB，且索引與序列的總數必須低於 50,000 個。
  • 您已在升級前完成所有必要的擴充功能及邏輯複製槽清理工作。

• 每個主要版本都包含一些功能，這些功能可能與先前版本不具向後相容性。 請查閱資料庫供應商的 發行說明，以確認是否有任何可能影響您應用程式的變更。

• 不支援將部署降級至先前版本。

• 就地主要版本升級一旦開始，便無法取消。

• 如果您沒有最新的備份，請考慮在升級前先進行備份。

此外，請注意，升級完成後，您的資料庫將運行 PostgreSQL 的新主要版本。 由於 PostgreSQL 會以特定版本的格式儲存資料，因此升級前的備份和 PITR 還原點均屬於較早版本的時間軸，無法還原至已升級的版本中。 為確保新版本能維持完整的還原及 PITR（特定時間點還原）功能，請在升級完成後立即執行新的備份。 該備份將成為新版本時間軸上未來還原作業的基準。

如果 IPU 失敗，仍可透過 PITR 使用升級前的有效備份，將較早的 PostgreSQL 版本還原至新實例中。

疑難排解

若您的應用程式在成功執行就地主要版本升級後出現意外問題，且需要回退至先前 PostgreSQL 版本，請聯繫我們的支援團隊以獲取指導。 請避免自行啟動 PITR 或還原備份，因為這可能會使復原作業變得複雜。

就地重大升級將在所有預檢驗全部通過後才會進行。 由於升級程序會直接在原始執行個體上運作，因此設有這些安全措施以保護您的部署。 若升級受阻，請檢查以下項目：

• 成員數量：就地主要版本升級支援最多 3 個成員的部署。 若您的部署包含超過 3 名成員，預檢查會阻擋升級程序。 無法透過 水平擴展 移除成員，因此請先向 IBM Cloud 技術支援 提交支援單，以減少成員數量，然後再重新嘗試升級。
• 叢集狀態：確保 Patroni 叢集運作正常，且具備明確的領導者／副本狀態。 若 Patroni 報告系統不穩定或發生故障轉移狀況，則無法進行升級作業。
• 磁碟空間：請確認是否有足夠的可用空間。 該過程採用 pg_upgrade 鏈接模式，需要足夠的餘量。 若磁碟使用量超過設定的限制（預設值：90%），請在重新嘗試前釋放空間。
• 磁碟 I/O 負載：檢查當前的 I/O 使用率與 IOPS。 當系統處於高負載狀態時，升級作業將暫停執行，以避免效能下降或升級失敗。
• 架構大小與物件數量：如前所述，架構大小直接影響就地主要版本升級的持續時間。 請確保任何單一模式皆未超過最大容量限制（預設值：100 GB），且索引與序列物件的總數量維持在限制範圍內（預設值：50,000）。 大型架構或異常龐大的物件數量，在進行升級前可能需要執行清理或優化作業。 pg_upgrade 透過建立新的系統表並直接重複使用舊的用戶資料檔案，實現快速升級。 建立這些系統表所需的時間會隨著資料庫物件的數量而增加。 可 透過監控整合 功能評估資源消耗狀況。 若並非所有資料庫元件皆可進行升級，則升級任務將失敗。 這可能是由於維護作業所致。 因健康檢查失敗而失敗的任務，可稍後重新嘗試執行。 若任務持續失敗，IBM Cloud 請向支援部門提交支援單。 若某些檢查項目與您的環境無關，但升級程序仍遭阻擋，請建立支援票證以獲取進一步協助。

直接執行促銷和升級

若要評估主要版本升級的影響，請觸發測試執行。 測試會模擬促銷及升級，並將結果列印至資料庫日誌。 透過 日誌分析整合 存取和查看資料庫日誌。 這可確保您目前與其延伸一起執行的版本可以順利升級至您想要的版本。

在執行測試時，必須將 skip_initial_backup 設為 false，並定義 version。

指令看起來如下:

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \