Aggiornamento a una nuova versione principale

Aggiornamento nell'interfaccia utente

1. Creare un nuovo Databases for MongoDB per testare il processo di aggiornamento.
   Creare l'installazione client ripristinando un backup dell'installazione client esistente con la stessa versione.

2. Puntare l'applicazione di staging all'installazione di prova.
   Aggiornare l'applicazione di staging per puntare alla distribuzione di prova. Confermare che l'applicazione di prova può connettersi con successo all'installazione di staging e che l'applicazione funziona come previsto. Eseguire tutti i test operativi e di performance richiesti per l'ambiente di staging.

3. Aggiornare la versione principale dell'installazione di prova facendo clic sul pulsante Aggiorna versione principale nella pagina Panoramica.
   In questo modo il database verrà messo in modalità di sola lettura mentre il processo di aggiornamento viene completato. Tenere presente quanto tempo impiega l'aggiornamento a completarsi, in modo da poter utilizzare l'impostazione di scadenza dell'aggiornamento per contenere gli aggiornamenti all'interno della finestra di manutenzione.

4. Confermare che l'applicazione di staging funziona con la nuova versione del database.
   Se l'applicazione funziona, questo passaggio conferma che l'aggiornamento del database di produzione è sicuro.

5. Aggiornare la distribuzione del database di produzione alla nuova versione.
   Una volta confermato che l'applicazione funziona correttamente utilizzando la nuova versione del database, è possibile tornare alla console di gestione e avviare il processo di aggiornamento della distribuzione di produzione. Nella sezione Dettagli dell'installazione client della pagina Panoramica, fate clic sul pulsante Aggiorna versione principale e seguite la procedura.

   Una volta avviato, il processo di aggiornamento in-place non può essere interrotto o annullato. Pertanto, nell'improbabile caso di un errore, la distribuzione del database potrebbe diventare irrecuperabile. Pertanto, creare un backup da utilizzare per ripristinare una nuova distribuzione. Se si seleziona "Aggiornamento della versione principale in loco con backup", il backup creato può essere utilizzato per il ripristino in una nuova distribuzione.

Il sito expiration for starting upgrade consente di configurare un periodo di "timeout" entro il quale il lavoro di aggiornamento deve iniziare prima di essere annullato automaticamente. Inoltre, testate in anticipo l'aggiornamento in staging per assicurarvi che l'aggiornamento venga completato entro la finestra temporale desiderata. Se, ad esempio, si desidera completare l'aggiornamento entro un'ora e si è testato l'aggiornamento e si sa che richiede 30 minuti, il lavoro di aggiornamento deve iniziare entro 30 minuti dalla conferma dell'aggiornamento. Pertanto, impostate la scadenza a 30 minuti, in modo che, se non si avvia entro questo tempo, non superi la finestra.

Aggiornamento tramite l'API

Utilizzare il seguente comando per eseguire l'aggiornamento in-place:

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"}'

Il sito expiration for starting upgrade consente di configurare un periodo di "timeout" entro il quale il lavoro di aggiornamento deve iniziare prima di essere annullato automaticamente. Inoltre, testate in anticipo l'aggiornamento in staging per assicurarvi che l'aggiornamento venga completato entro la finestra temporale desiderata. Se, ad esempio, si desidera completare l'aggiornamento entro un'ora e si è testato l'aggiornamento e si sa che richiede 30 minuti, il lavoro di aggiornamento deve iniziare entro 30 minuti dalla conferma dell'aggiornamento. Pertanto, impostate la scadenza a un timestamp di 30 minuti da oggi, in modo che, se non si avvia entro tale periodo, non superi la finestra. La scadenza deve essere compresa tra 5 minuti (valore predefinito) e 24 ore. Per ulteriori informazioni, consultare l'API Cloud Databases.

Aggiornamento tramite la CLI

Disponibile nella versione plugin CDB >= 0.20.0

Per visualizzare l'elenco delle transizioni di aggiornamento e ripristino consentite per l'installazione client:

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

Per aggiornare il comando con i parametri richiesti:

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

Per visualizzare tutti i dettagli dei parametri di comando:

ibmcloud cdb deployment-version-upgrade --help

Il sito expiration for starting upgrade consente di configurare un periodo di "timeout" entro il quale il lavoro di aggiornamento deve iniziare prima di essere annullato automaticamente. Inoltre, testate in anticipo l'aggiornamento in staging per assicurarvi che l'aggiornamento venga completato entro la finestra temporale desiderata. Se, ad esempio, si desidera completare l'aggiornamento entro un'ora e si è testato l'aggiornamento e si sa che richiede 30 minuti, il lavoro di aggiornamento deve iniziare entro 30 minuti dalla conferma dell'aggiornamento. Pertanto, impostate la scadenza a 30 minuti, in modo che, se non si avvia entro questo tempo, non superi la finestra. La scadenza deve essere compresa tra 5 minuti (valore predefinito) e 24 ore. Esistono due modi per impostare la scadenza utilizzando la CLI --expire-in o --expire-at. Per ulteriori informazioni, consultare la guida del comando.

Aggiornamento tramite Terraform

Disponibile nella versione del provider Terraform >= 1.79.2

Per aggiornare, basta aggiungere o modificare il valore version nella configurazione. Esiste anche un flag bool opzionale, version_upgrade_skip_backup, che può essere impostato per saltare il backup.

Non è consigliabile saltare un backup. Saltare un backup prima di un aggiornamento di versione è pericoloso e può comportare la perdita di dati se l'aggiornamento fallisce in qualsiasi fase: non ci sarà un backup immediato da cui ripristinare.

Durante l'aggiornamento, il database verrà messo in modalità di sola lettura. Si consiglia vivamente di eseguire un test prima di eseguire l'aggiornamento.

L'aggiornamento potrebbe richiedere più tempo del timeout predefinito. È possibile impostare un valore di timeout più lungo utilizzando l'attributo timeout.

Terraform ha dei timeout invece di timestamp di scadenza. Pertanto, aumentare il timeout, poiché il valore di aggiornamento del timeout viene utilizzato come scadenza. Ad esempio, se si imposta un timeout di 20 minuti, la scadenza sarà impostata a 20 minuti e se l'aggiornamento non viene avviato in quel lasso di tempo, scade e l'aggiornamento non viene avviato. Si noti che la scadenza massima è di 24 ore, quindi anche se si imposta un timeout di 36 ore, l'aggiornamento scadrà se non è stato avviato entro le prime 24 ore.

Se è in corso un aggiornamento, è possibile che alcune attività siano in coda e non vengano eseguite fino al completamento dell'aggiornamento della versione.

Aggiornamento nell'interfaccia utente

Per i nuovi modelli di hosting (calcolo isolato e calcolo condiviso), l'aggiornamento a una nuova versione principale è disponibile tramite la CLI e l'API.

È possibile eseguire l'aggiornamento a una nuova versione mediante ripristino di un backup dalla pagina Backup e ripristino dell'installazione client sulla console IBM Cloud. Fare clic su Ripristina backup su un backup per aprire una pagina in una nuova scheda in cui è possibile modificare alcune opzioni per la nuova distribuzione. Una di queste è la versione del database, che viene popolata automaticamente con le versioni disponibili per l'aggiornamento. Selezionare una versione e fare clic su Ripristina backup per avviare il processo di fornitura e ripristino.

Aggiornamento tramite la CLI

Quando esegui l'upgrade e il ripristino dal backup tramite la CLI IBM Cloud, utilizza il comando di provisioning dal controller della risorsa.

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

I parametri instance_name, service_id, service_plan_id e region sono tutti obbligatori. Fornisci anche a -p i parametri di versione e ID backup in un oggetto JSON. La nuova distribuzione viene ridimensionata automaticamente con lo stesso disco e la stessa memoria della distribuzione di origine al momento del backup.

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"
}'

Aggiornamento tramite l'API

Come per il provisioning tramite l'API, è necessario completare i passaggi necessari per utilizzare l'API del controller delle risorse prima di poterla utilizzare per l'aggiornamento da un backup. Invia quindi all'API una richiesta POST. I parametri name, target, resource_group e resource_plan_id sono tutti obbligatori. Fornire anche la versione e l'ID del backup. La nuova distribuzione ha la stessa assegnazione di memoria e disco della distribuzione di origine al momento del backup.

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"
  }'

Aggiornamento tramite Terraform

Usare Terraform per ripristinare un backup da una versione precedente a una nuova.

1. Impostate il vostro backup_id. Per ulteriori informazioni, vedere backup_id.
2. Impostate il vostro version nell'attributo version. Per ulteriori informazioni, vedere version.

Il codice si presenta come segue:

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

Per ulteriori informazioni, consultare il Registro di Terraform Cloud Databases. In alternativa, è possibile utilizzare Terraform IBM Modules(TIM) per creare una nuova istanza di database da un'istanza di backup. Per ulteriori informazioni, consultare l'esempio di Ripristino da backup.