升級至新主要版本

Databases for MongoDB 提供兩種不同的升級路徑：

就地升級至新主要版本（目前支援 MongoDB 標準方案、MongoDB 企業方案）。
從備份還原（標準 MongoDB 方案與 MongoDB 企業方案皆支援）。

就地主要版本升級

就地主要版本升級功能可讓您將系統部署升級至下一個新的主要版本，而無需將備份還原為新的部署。此方法可維持相同的連線字串，無需重新設定部署。但是，如果新的主要版本需要調整應用程式，則必須處理這些調整。

在原地主要版本升級視窗 (包括備份) 期間，部署會設定為 setUserWriteBlockMode，僅允許讀取操作，但不允許對部署進行寫入操作，以確保安全升級。一旦部署的主要版本升級完成，便會 writeBlockMode 移除。

執行原地主要版本升級時，有兩個選項：

就地主要版本升級並備份：此路徑會在執行實際升級前建立備份，提供額外的安全保障（企業 MongoDB 方案的唯一選項）。
無備份就地主要版本升級：此選項繼續進行升級，而不事先建立備份。如果就地升級不成功，您需要從最新的備份還原部署到新的部署中。

不建議在沒有備份的情況下就地升級。如果升級在任何階段失敗，可能會導致資料遺失，因為沒有即時的備份可以還原。

某個版本的「特定時間點還原」及「特定時間點還原 (PITR) 離線還原」功能將暫時無法使用，直到該版本的快照完成並成功備份為止。此快照未出現在您的備份清單中。

開始之前

開始升級程序前，請考慮下列各方面。

升級前，您的部署必須處於健康狀態。
您的部署必須至少有 2 GB 可用磁碟空間。
您的部署中必須沒有具有以下權限的使用者 bypassWriteBlockingMode.
您只能升級到下一個主要版本，而不是指定您所選擇的版本。
每個主要版本都包含一些可能無法與先前版本向後相容的功能。查看資料庫供應商的發行說明，以瞭解可能影響您的應用程式的任何變更。
不支援將部署降級為先前的版本。
原地主要版本升級一旦開始就無法取消。
對於 MongoDB Enterprise Edition，在升級之前必須至少有一份可用備份。
針對 MongoDB Enterprise Edition，在就地進行主要版本升級後，若要透過 PITR（點時還原）使用較早版本的點時點來還原及升級，必須分兩個獨立步驟進行。

在使用者介面中升級

建立一個新的「Databases for MongoDB」，以測試升級流程。
透過「還原備份」功能，從您現有的同版本部署中建立新的部署。
將您的預備環境應用程式指向測試部署環境。
請更新您的預備環境應用程式，使其指向測試部署。確認您的測試應用程式可以成功連線至暫存部署，且應用程式的運作符合預期。對暫存環境執行任何所需的效能與作業測試。
請點擊「概覽」頁面的「升級主要版本」按鈕，以升級您的測試部署的主要版本。
這將使您的資料庫在升級程序完成期間進入唯讀模式。請注意升級完成所需的時間，以便您可以使用升級到期設定，將升級包含在維護視窗內。
請確認您的預備環境應用程式能與新版資料庫正常運作。
如果您的應用程式運作正常，此步驟可確認升級生產環境資料庫應是安全的。
將您的生產環境資料庫部署升級至新版本。
確認您的應用程式在使用新版資料庫時運作正常後，即可返回管理主控台，並開始升級生產環境部署的流程。在總覽頁面的部署詳細資訊部分，按一下升級主要版本按鈕，然後按步驟進行。

就地升級程序一旦啟動，就無法停止或回退。因此，萬一發生錯誤時，您的資料庫部署可能會變得無法復原。因此，請建立一個備份，然後用於還原到新的部署。如果您選擇「使用備份就地升級主要版本」，建立的備份可用於在新部署中還原。

expiration for starting upgrade 允許您設定「超時」期限，升級工作必須在該期限內啟動，否則會自動取消。此外，請先在暫存階段測試升級，以確保升級能在您所需的時間視窗內完成。例如，如果您希望在 1 小時內完成升級，而您測試升級後知道升級需要 30 分鐘，那麼您的升級工作必須在您確認要升級後的 30 分鐘內開始。因此，請將到期時間設定為 30 分鐘，如此一來，如果在這段時間內沒有啟動，就不會超過您的視窗。

透過 API 升級

使用下列指令就地升級：

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/version -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"version": "7.0"}'

expiration for starting upgrade 允許您設定「超時」期限，升級工作必須在該期限內啟動，否則會自動取消。此外，請先在暫存階段測試升級，以確保升級能在您所需的時間視窗內完成。例如，如果您希望在 1 小時內完成升級，而您測試升級後知道升級需要 30 分鐘，那麼您的升級工作必須在您確認要升級後的 30 分鐘內開始。因此，請將到期時間設定為 30 分鐘後的時間戳，如此一來，如果它沒有在這段時間內開始，就不會超過您的視窗。到期時間必須在 5 分鐘（預設）到 24 小時之間。如需詳細資訊，請參閱 Cloud Databases API。

透過 CLI 升級

適用於 CDB 外掛程式版本 >= 0.20.0

若要檢視部署允許的升級和還原轉換清單，請參閱「升級和還原轉換」：

ibmcloud cdb deployment-capability-show <NAME|CRN> versions

要使用所需參數升級指令：

ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>

若要檢視指令參數的完整詳細資訊：

ibmcloud cdb deployment-version-upgrade --help

透過 Terraform 升級

適用於 Terraform 提供者版本 >= 1.79.2

若要升級，只需在您的組態中新增或變更 version 值即可。還有一個可選的 bool 標誌，version_upgrade_skip_backup，可以設定為跳過備份。

不建議跳過備份。在版本升級前跳過備份是很危險的，如果升級在任何階段失敗，可能會導致資料遺失 - 因為沒有即時備份可以還原。

在升級過程中，資料庫將進入「唯讀」模式。強烈建議在升級前先進行測試。

升級可能需要比預設超時更長的時間。可以使用 timeouts 屬性設定較長的逾時值。

Terraform 有超時而非到期時間戳記。因此，請增加您的逾時時間，因為您的逾時更新值會被用作過期。例如，如果您設定逾時為 20 分鐘，過期時間就會設定為 20 分鐘，如果在該時間內沒有開始升級，過期時間就會過期，升級也不會開始。請注意，最長的過期時間為 24 小時 - 因此即使您設定 36 小時的逾時時間，如果在前 24 小時內尚未開始升級，升級也會過期。

如果正在進行升級，請注意某些任務可能已排成佇列，在版本升級完成之前不會繼續進行。

疑難排解

使用者具有 bypassWriteBlockingMode

為了確保安全升級，在備份或升級期間，任何使用者都不能執行寫入動作。在資料庫進入寫入封鎖模式 (writeBlockMode ) 之前，會先檢查是否有任何使用者有權限. bypassWriteBlockingMode. 如果識別出這樣的使用者，任務就會進入失敗狀態。任何重試都會失敗，只有移除具有此權限的使用者，才能執行原地主要版本升級。

健康檢查

如果服務實例的資源不足，任務就會失敗，因為在這種情況下無法保證安全升級。使用監控整合可評估資源消耗。如果不是所有資料庫元件都可以升級，升級工作會失敗。

對於 MongoDB Enterprise Edition ，PITR 的支援要求當前存在無間隙的快照，且升級期間不會執行任何快照操作。若無法保證 PITR，就地升級將會失敗。

此狀態可能因維護作業或資料庫使用而發生。因健康檢查失敗而失敗的任務可以稍後再重試。若任務持續失敗，請向 IBM Cloud 支援團隊提交支援票證。

從備份還原

在資料庫的主要版本達到壽命終點 (EOL) 之前，從備份還原到新的資料庫實例，升級到下一個可用的主要版本。

準備在 EOL 日期之前的最新版本上執行，然後移轉至。如需相關資訊，請參閱版本化原則。

不支援回復版本。

升級至 Databases for MongoDB可用的 MongoDB 最新版本。從型錄頁面、Cloud Databases CLI 外掛程式指令 ibmcloud cdb deployables-show 或從 Cloud Databases API /deployables 端點尋找最新版本。

升級是透過將資料的備份還原至新的部署來處理。從備份還原具有各種優點:

原始資料庫會維持執行，正式作業工作則可以不間斷。
您可以在正式作業之外測試新資料庫，並處理任何應用程式不相容。
整個流程可在任何時候重新執行。
進行一次全新的還原，可降低舊版資料庫中不必要的殘留資料被帶入新資料庫的可能性。

升級路徑

主要版本升級路徑
現行版本	主要版本升級路徑
MongoDB 7	MongoDB 8

在使用者介面中升級

對於新的託管模式 (獨立運算和共用運算)，可透過 CLI 和 API 升級至新的主要版本。

您可以透過以下方式升級到新版本恢復備份來自_備份和復原_您的部署頁面IBM Cloud安慰。點選恢復備份在備份上開啟新分頁中的頁面，您可以在其中更改新部署的一些選項。其中一個是資料庫版本，其中會自動移入可供您升級至的版本。選擇版本並點擊恢復備份啟動配置和恢復過程。

透過 CLI 升級

當您透過 IBM Cloud CLI 升級及從備份還原時，請從資源控制器使用佈建指令。

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>

參數 instance_name、service_id、service_plan_id 和 region 都是必要的。您也可以在 JSON 物件中提供版本及備份 ID 參數給 -p。在備份時，會使用與來源部署相同的磁碟及記憶體來自動調整新部署的大小。

ibmcloud resource service-instance-create example-upgrade databases-for-mongodb standard us-south \
-p \ '{
  "backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
  "version":"7.0"
}'

透過 API 升級

與透過 API 進行佈建類似，您必須先完成使用資源控制器 API 的必要步驟，才能使用它從備份升級。然後，傳送 POST 要求給 API。參數 name、target、resource_group 和 resource_plan_id 都是必要的。同時提供版本和備份 ID。新部署與備份時的來源部署具有相同的記憶體及磁碟配置。

curl -X POST   https://resource-controller.cloud.ibm.com/v2/resource_instances   -H 'Authorization: Bearer <>'   -H 'Content-Type: application/json'     -d '{
    "name": "my-instance",
    "target": "us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-mongodb-standard",
    "backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
    "version":"7.0"
  }'

透過 Terraform 升級

使用 Terraform 將備份從舊版本還原到新版本。

設定您的 backup_id。如需相關資訊，請參閱 backup_id。
在版本屬性中設定您的 version。如需相關資訊，請參閱 version。

程式碼如下：

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

如需詳細資訊，請參閱 Cloud Databases Terraform Registry。另外，您也可以使用 Terraform IBM Modules(TIM) 從備份實體建立新的資料庫實體。如需詳細資訊，請參閱從備份還原範例。