Aggiornamento a una nuova versione principale

Gen 2

Databases for MongoDB offre due diversi percorsi di aggiornamento:

  • Aggiornamento in loco a una nuova versione principale (attualmente supportato per il piano Standard di MongoDB ).
  • Ripristino da backup (funzionalità supportata per il piano Standard di MongoDB e il piano Enterprise di MongoDB ).

Aggiornamenti alla versione principale senza reinstallazione

L'aggiornamento alla versione principale in loco consente di aggiornare l'installazione alla versione principale successiva, eliminando la necessità di ripristinare un backup in una nuova installazione. Questo approccio mantiene le stesse stringhe di connessione, senza che sia necessario riconfigurare l'implementazione. Tuttavia, se la nuova versione principale richiede modifiche all'applicazione, queste devono essere apportate.

Durante la finestra temporale prevista per l'aggiornamento alla versione principale senza interruzione del servizio (compreso il backup), l'ambiente di distribuzione viene impostato in modalità setUserWriteBlockMode, che consente solo operazioni di lettura ma non di scrittura sull'ambiente stesso, al fine di garantire un aggiornamento sicuro. Non appena l'aggiornamento alla versione principale della distribuzione sarà completato, il writeBlockMode viene rimosso.

Quando si esegue un aggiornamento alla versione principale senza reinstallare il sistema, sono disponibili due opzioni:

  • Aggiornamento alla versione principale in loco con backup: questa procedura crea un backup prima di eseguire l'aggiornamento vero e proprio, garantendo un ulteriore livello di sicurezza.

  • Aggiornamento alla versione principale in loco senza backup: questa opzione esegue l'aggiornamento senza creare prima un backup. Nel caso in cui l'aggiornamento in loco non vada a buon fine, sarà necessario ripristinare la distribuzione dall'ultimo backup in una nuova distribuzione.

    Si sconsiglia di eseguire l'aggiornamento in loco senza effettuare un backup. Se l'aggiornamento dovesse fallire in qualsiasi fase, ciò potrebbe comportare la perdita dei dati, poiché non sarà disponibile un backup immediato da cui effettuare il ripristino.

Prima di iniziare

Prima di avviare la procedura di aggiornamento, è opportuno tenere in considerazione i seguenti aspetti.

  • Prima di procedere all'aggiornamento, l'ambiente di distribuzione deve essere in uno stato corretto.
  • L'installazione deve disporre di almeno 2 GB di spazio libero su disco.
  • La vostra distribuzione non deve includere alcun utente con il privilegio di bypassWriteBlockingMode.
  • È possibile effettuare l'aggiornamento solo alla versione principale successiva, anziché specificare la versione desiderata.
  • Ogni versione principale contiene alcune funzionalità che potrebbero non essere retrocompatibili con le versioni precedenti. Controlla le note di rilascio fornite dal fornitore del database per verificare se ci sono modifiche che potrebbero influire sulle tue applicazioni.
  • Il downgrade di una distribuzione a una versione precedente non è supportato.
  • L'aggiornamento alla versione principale in loco non può essere annullato una volta avviato.
  • Per MongoDB Enterprise Edition, è necessario che sia disponibile almeno un backup prima di procedere all'aggiornamento.

Aggiornamento nell'interfaccia utente

  1. Crea un nuovo Databases for MongoDB per testare la procedura di aggiornamento.
    Crea la distribuzione ripristinando un backup dalla distribuzione esistente con la stessa versione.

  2. Punta l'applicazione di staging verso l'ambiente di test.
    Aggiorna la tua applicazione di staging in modo che punti alla distribuzione di prova. Verifica che l'applicazione di test riesca a connettersi correttamente all'ambiente di staging e che funzioni come previsto. Eseguire tutti i test prestazionali e operativi necessari sull'ambiente di staging.

  3. Aggiorna la versione principale della tua distribuzione di prova facendo clic sul pulsante " Aggiorna versione principale " nella pagina Panoramica.
    In questo modo il database passerà alla modalità SOLO LETTURA fino al completamento del processo di aggiornamento. Prendi nota della durata dell'aggiornamento, in modo da poter utilizzare l'impostazione relativa alla scadenza dell'aggiornamento per far sì che gli aggiornamenti avvengano all'interno della tua finestra di manutenzione.

  4. Verifica che la tua applicazione di staging funzioni con la nuova versione del database.
    Se l'applicazione funziona, questo passaggio conferma che è possibile aggiornare il database di produzione in tutta sicurezza.

  5. Esegui l'aggiornamento dell'implementazione del database di produzione alla nuova versione.
    Una volta verificato che l'applicazione funzioni correttamente con la nuova versione del database, è possibile tornare alla console di gestione e avviare il processo di aggiornamento dell'ambiente di produzione. Nella sezione " Dettagli dell'implementazione " della pagina " Panoramica ", fare clic sul pulsante " Aggiorna versione principale " e seguire la procedura indicata.

    Una volta avviato il processo di aggiornamento in loco, non è possibile interromperlo né annullarlo. Pertanto, nell'improbabile eventualità di un errore, l'implementazione del database potrebbe diventare irrecuperabile. Pertanto, crea un backup che potrai poi utilizzare per il ripristino su una nuova installazione. Se si seleziona "Aggiornamento alla versione principale in loco con backup", il backup creato potrà essere utilizzato per il ripristino in una nuova distribuzione.

L' expiration for starting upgrade e consente di configurare un periodo di "timeout" entro il quale il processo di aggiornamento deve avviarsi prima di essere automaticamente annullato. Inoltre, testate preventivamente l'aggiornamento nell'ambiente di staging per assicurarvi che venga completato entro la finestra temporale desiderata. Se, ad esempio, desideri completare l'aggiornamento entro un'ora e, dopo averlo testato, sai che richiede 30 minuti, allora il processo di aggiornamento dovrà avviarsi entro 30 minuti dalla conferma della tua intenzione di procedere con l'aggiornamento. Pertanto, imposta la scadenza a 30 minuti, in modo che, se non si avvia entro tale lasso di tempo, non superi il limite di tempo previsto.

Aggiornamento tramite l'API

Utilizza il seguente comando per eseguire l'aggiornamento in loco:

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

L' expiration for starting upgrade e consente di configurare un periodo di "timeout" entro il quale il processo di aggiornamento deve avviarsi prima di essere automaticamente annullato. Inoltre, testate preventivamente l'aggiornamento nell'ambiente di staging per assicurarvi che venga completato entro la finestra temporale desiderata. Se, ad esempio, desideri completare l'aggiornamento entro un'ora e, dopo averlo testato, sai che richiede 30 minuti, allora il processo di aggiornamento dovrà avviarsi entro 30 minuti dalla conferma della tua intenzione di procedere con l'aggiornamento. Pertanto, imposta la scadenza su un timestamp di 30 minuti da ora, in modo che, se non dovesse avviarsi entro tale lasso di tempo, non superi la finestra temporale prevista. La scadenza deve essere compresa tra 5 minuti (impostazione predefinita) e 24 ore a partire da ora. Per ulteriori informazioni, consultare l'API " Cloud Databases ".

Aggiornamento tramite CLI

Disponibile nella versione del plugin CDB >= 0.20.0

Per visualizzare l'elenco delle transizioni di aggiornamento e ripristino consentite per la distribuzione:

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

Per eseguire il comando di aggiornamento con i parametri richiesti:

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

Per visualizzare tutti i dettagli relativi ai parametri di comando:

ibmcloud cdb deployment-version-upgrade --help

L' expiration for starting upgrade e consente di configurare un periodo di "timeout" entro il quale il processo di aggiornamento deve avviarsi prima di essere automaticamente annullato. Inoltre, testate preventivamente l'aggiornamento nell'ambiente di staging per assicurarvi che venga completato entro la finestra temporale desiderata. Se, ad esempio, desideri completare l'aggiornamento entro un'ora e, dopo averlo testato, sai che richiede 30 minuti, allora il processo di aggiornamento dovrà avviarsi entro 30 minuti dalla conferma della tua intenzione di procedere con l'aggiornamento. Pertanto, imposta la scadenza a 30 minuti, in modo che, se non si avvia entro tale lasso di tempo, non superi il limite di tempo previsto. La scadenza deve essere compresa tra 5 minuti (impostazione predefinita) e 24 ore a partire da ora. Esistono due modi per impostare la scadenza tramite CLI: --expire-in oppure --expire-at. Per ulteriori informazioni, consultare la guida del comando.

Aggiornamento tramite Terraform

Disponibile nella versione del provider Terraform >= 1.79.2

Per effettuare l'aggiornamento, è sufficiente aggiungere o modificare il valore " version " nella configurazione. È inoltre disponibile un flag booleano opzionale, version_upgrade_skip_backup``, che è possibile impostare per saltare il backup.

Si sconsiglia di saltare un backup. Saltare il backup prima di un aggiornamento di versione è pericoloso e può comportare la perdita dei dati se l'aggiornamento fallisce in qualsiasi fase: non ci sarà infatti alcun backup immediato da cui ripristinare i dati.

Durante l'aggiornamento, il database verrà impostato in modalità SOLO LETTURA. Si consiglia vivamente di eseguire dei test prima di procedere all'aggiornamento.

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

Terraform utilizza i timeout anziché i timestamp di scadenza. Pertanto, aumenta il timeout, poiché il valore di aggiornamento del timeout viene utilizzato come data di scadenza. Ad esempio, se si imposta un timeout di 20 minuti, la scadenza sarà fissata a 20 minuti e, se l'aggiornamento non viene avviato entro tale lasso di tempo, scadrà e l'aggiornamento non verrà avviato. Si noti che la scadenza massima è di 24 ore: pertanto, 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, tieni presente che alcune attività potrebbero essere messe in coda e non verranno eseguite fino al completamento dell'aggiornamento della versione.

Risoluzione dei problemi

Utente con bypassWriteBlockingMode

Per garantire un aggiornamento sicuro, nessun utente deve poter eseguire operazioni di scrittura durante il backup o l'aggiornamento. Prima che il database entri in modalità writeBlockMode, viene verificato se qualche utente disponga del privilegio di bypassWriteBlockingMode. Se viene identificato un utente di questo tipo, l'attività passa allo stato "fallita". Qualsiasi nuovo tentativo fallirà e solo la rimozione di un utente in possesso di tale privilegio consentirà di eseguire l'aggiornamento alla versione principale in loco.

Controlli di stato

Se un'istanza di servizio dispone di risorse insufficienti, l'operazione fallisce poiché in tali circostanze non è possibile garantire un aggiornamento sicuro. È possibile valutare il consumo di risorse utilizzando l'integrazione di monitoraggio. Se non tutti i componenti del database sono disponibili per l'aggiornamento, l'operazione di aggiornamento fallisce. Ciò può verificarsi a causa di interventi di manutenzione. Le attività che non sono andate a buon fine a causa di controlli di integrità falliti possono essere riprovate in un secondo momento. Se l'operazione continua a non andare a buon fine, apri un ticket di assistenza presso il supporto di IBM Cloud.

Ripristino dal backup

Prima che una versione principale di un database raggiunga la fine del ciclo di vita (EOL), eseguire l'aggiornamento alla versione principale successiva disponibile ripristinando i dati da un backup in una nuova istanza del database.

Preparatevi a continuare a utilizzare l'ultima versione e poi a migrare ad essa prima della data di fine del ciclo di vita (EOL). Per ulteriori informazioni, consultare la Politica sulla gestione delle versioni.

Il rollback delle versioni non è supportato.

Esegui l'aggiornamento all'ultima versione di MongoDB, disponibile all'indirizzo Databases for MongoDB. È possibile trovare l'ultima versione nella pagina del catalogo, tramite il comando del plug-in CLI di Cloud Databases ibmcloud cdb deployables-show oppure tramite l'endpoint dell'API di Cloud Databases /deployables.

L'aggiornamento viene effettuato ripristinando un backup dei dati in una nuova installazione. Il ripristino da un backup presenta diversi vantaggi:

  • Il database originale rimane in esecuzione e il lavoro di produzione può non essere interrotto.
  • Puoi verificare il nuovo database all'esterno della produzione e agire su ogni incompatibilità dell'applicazione.
  • L'intero processo può essere ripetuto in qualsiasi momento.
  • Un ripristino completo riduce la probabilità che nel nuovo database vengano trasferiti elementi superflui provenienti dalla versione precedente.

Percorsi di aggiornamento

Percorsi di aggiornamento alla versione principale
Versione corrente Percorso di aggiornamento alla versione principale
MongoDB 7 MongoDB 8

Aggiornamento nell'interfaccia utente

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

È possibile eseguire l'aggiornamento a una nuova versione ripristinando un backup dalla pagina " Backup e ripristino " della propria distribuzione nella console IBM Cloud. Fai clic su "Ripristina backup " su un backup per aprire una pagina in una nuova scheda, dove potrai modificare alcune opzioni per la nuova distribuzione. Una di queste è la versione del database, che viene compilata automaticamente con le versioni disponibili per l'aggiornamento. Seleziona una versione e fai clic su "Ripristina backup " per avviare la procedura di configurazione e ripristino.

Aggiornamento tramite CLI

Quando si esegue l'aggiornamento e il ripristino da backup tramite la CLI di IBM Cloud, utilizzare il comando di provisioning dal controller delle risorse.

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. Inoltre, è necessario fornire all' -p, in un oggetto JSON, i parametri relativi alla versione e all'ID del backup. La nuova distribuzione viene configurata automaticamente con le stesse dimensioni di disco e 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

Analogamente alla configurazione tramite l'API, è necessario completare i passaggi necessari per l'utilizzo dell'API del controller delle risorse prima di poterla utilizzare per eseguire l'aggiornamento da un backup. A questo punto, invia una richiesta POST all'API. I parametri name, target, resource_group e resource_plan_id sono tutti obbligatori. Fornisci anche la versione e l'ID del backup. La nuova distribuzione presenta la stessa allocazione di memoria e spazio su 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

Utilizza Terraform per ripristinare da un backup di una versione precedente a una versione più recente.

  1. Imposta il tuo backup_id. Per ulteriori informazioni, consultare backup_id.
  2. Imposta " version " nell'attributo "version". Per ulteriori informazioni, consultare version.

Il codice è il seguente:

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 Terraform di Cloud Databases.