Esegui l'upgrade della versione principale del database in loco

Questa pagina descrive come eseguire l'upgrade della versione principale del database eseguendo l'upgrade dell'istanza Cloud SQL in loco anziché eseguendo la migrazione dei dati.

Introduzione

I fornitori di software per database rilasciano periodicamente nuove versioni principali che contengono nuove funzionalità, miglioramenti delle prestazioni e della sicurezza. Cloud SQL adotta le nuove versioni dopo il loro rilascio. Dopo che Cloud SQL offre il supporto per una nuova versione principale, puoi eseguire l'upgrade delle istanze per mantenere aggiornato il database.

Puoi eseguire l'upgrade della versione del database di un'istanza in loco o eseguendo la migrazione dei dati. Gli upgrade in loco sono un modo più semplice per eseguire l'upgrade della versione principale dell'istanza. Non è necessario eseguire la migrazione dei dati o modificare le stringhe di connessione dell'applicazione. Con gli upgrade in loco, puoi mantenere il nome, l'indirizzo IP e altre impostazioni dell'istanza corrente dopo l'upgrade. Gli upgrade in loco non richiedono lo spostamento dei file di dati e possono essere completati più rapidamente. In alcuni casi, il tempo di inattività è inferiore a quello richiesto dalla migrazione dei dati.

L'operazione di upgrade in loco di Cloud SQL per PostgreSQL utilizza l'utilità pg_upgrade.

Pianifica un upgrade della versione principale

  1. Verifica di disporre del ruolo richiesto per eseguire un upgrade della versione principale: Cloud SQL Owner o Cloud SQL Admin.

  2. Scegli una versione principale di destinazione.

    gcloud

    Per informazioni sull'installazione e su come iniziare a utilizzare gcloud CLI, consulta Installa gcloud CLI. Per informazioni sull'avvio di Cloud Shell, consulta Utilizza Cloud Shell.

    Per controllare le versioni del database che puoi scegliere come target per un upgrade in loco sulla tua istanza, segui questi passaggi:

    1. Esegui questo comando.
      2. gcloud sql instances describe INSTANCE_NAME

      Sostituisci INSTANCE_NAME con il nome dell'istanza.

    2. Nell'output del comando, individua la sezione con l'etichetta upgradableDatabaseVersions.
    3. Ogni sottosezione restituisce una versione del database disponibile per l'upgrade. In ogni sottosezione, esamina i seguenti campi.
      • majorVersion: la versione principale che puoi scegliere come target per l'upgrade in loco.
      • name: la stringa della versione del database che include la versione principale.
      • displayName: il nome visualizzato della versione del database.

    REST v1

    Per verificare quali versioni del database di destinazione sono disponibili per un upgrade sul posto della versione principale, utilizza il metodo instances.get dell'API Cloud SQL Admin.

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • INSTANCE_NAME: il nome dell'istanza

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    
upgradableDatabaseVersions:

{
  major_version: "POSTGRES_15_0"
  name: "POSTGRES_15_0"
  display_name: "PostgreSQL 15.0"
}

    REST v1beta4

    Per verificare quali versioni del database di destinazione sono disponibili per l'upgrade della versione principale di un'istanza, utilizza il metodo instances.get dell'API Cloud SQL Admin.

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • INSTANCE_NAME: il nome dell'istanza

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    
upgradableDatabaseVersions:

{
  major_version: "POSTGRES_15_0"
  name: "POSTGRES_15_0"
  display_name: "PostgreSQL 15.0"
}

    Per l'elenco completo delle versioni del database supportate da Cloud SQL, consulta Versioni del database e policy per le versioni.

  3. Considera le funzionalità offerte in ogni versione principale del database e risolvi le incompatibilità.

    Le nuove versioni principali introducono modifiche incompatibili che potrebbero richiedere la modifica del codice dell'applicazione, dello schema o delle impostazioni del database. Prima di poter eseguire l'upgrade dell'istanza del database, consulta le note di rilascio della versione principale di destinazione per determinare le incompatibilità che devi risolvere.

  4. Esegui il controllo preliminare per gli upgrade.

  5. Testa l'upgrade con un dry run.

    Esegui un dry run della procedura di upgrade end-to-end in un ambiente di test prima di eseguire l'upgrade del database di produzione. Puoi clonare l'istanza per creare una copia identica dei dati su cui testare il processo di upgrade.

    Oltre a verificare che l'upgrade venga completato correttamente, esegui test per assicurarti che l'applicazione si comporti come previsto sul database di cui è stato eseguito l'upgrade.

  6. Decidi quando eseguire l'upgrade.

    L'upgrade richiede che l'istanza non sia disponibile per un periodo di tempo. Pianifica l'upgrade in un periodo di tempo in cui l'attività del database è ridotta. Ti consigliamo di non eseguire un upgrade della versione principale durante periodi di traffico elevato o quando nel database sono attive transazioni di lunga durata.

Preparati a un upgrade della versione principale

Prima di eseguire l'upgrade, completa i seguenti passaggi.

  1. Controlla il valore LC_COLLATE per i database template e postgres. Il set di caratteri per ogni database deve essere en_US.UTF8.

    Se il valore LC_COLLATE per i database template e postgres non è en_US.UTF8, l'upgrade della versione principale non va a buon fine. Per risolvere il problema, se uno dei database ha un set di caratteri diverso da en_US.UTF8, modifica il valore LC_COLLATE in en_US.UTF8 prima di eseguire l'upgrade.

    Per modificare la codifica di un database:

    1. Esegui il dump del database.
    2. Elimina il database.
    3. Crea un nuovo database con la codifica diversa (per questo esempio, en_US.UTF8).
    4. Ricarica i dati.

    Un'altra opzione è rinominare il database:

    1. Chiudi tutte le connessioni al database.
    2. Rinomina il database.
    3. Aggiorna le configurazioni dell'applicazione in modo da utilizzare il nuovo nome del database.
    4. Crea un nuovo database vuoto con la codifica predefinita.

    Ti consigliamo di eseguire questi passaggi su un'istanza clonata prima di applicarli a un'istanza di produzione.

  2. Gestisci le restanti estensioni PostgreSQL.

    La maggior parte delle estensioni funziona sulla versione principale del database di cui è stato eseguito l'upgrade. Elimina tutte le estensioni che non sono più supportate nella versione di destinazione. Ad esempio, elimina l'estensione chkpass se esegui l'upgrade a PostgreSQL 11 o versioni successive.

    Puoi eseguire l'upgrade di PostGIS e delle relative estensioni alle versioni supportate più recenti manualmente.

    A volte, l'upgrade dalle versioni 2.x di PostGIS può creare una situazione in cui rimangono oggetti del database non associati all'estensione PostGIS. Questo può bloccare l'operazione di upgrade. Per informazioni sulla risoluzione di questo problema, consulta Risoluzione di un'installazione di PostGIS Raster non funzionante.

    A volte, l'upgrade a PostGIS versione 3.1.7 o successive non può essere completato perché gli oggetti utilizzano funzioni deprecate. Questo può bloccare l'operazione di upgrade. Per controllare lo stato dell'upgrade, esegui SELECT PostGIS_full_version();. Se sono presenti avvisi, elimina tutti gli oggetti che utilizzano le funzioni ritirate e aggiorna l'estensione PostGIS a qualsiasi versione intermedia o successiva. Dopo aver completato queste azioni, esegui di nuovo il comando SELECT PostGIS_full_version();. Verifica che non vengano visualizzati avvisi. Quindi, procedi con l'operazione di upgrade.

    Per scoprire di più sull'upgrade delle estensioni PostGIS, consulta Esecuzione dell'upgrade di PostGIS. Per i problemi associati all'upgrade di PostGIS, consulta Controlla la versione dell'istanza PostgreSQL.
  3. Gestisci i flag di database personalizzati. Controlla i nomi di tutti i flag di database personalizzati che hai configurato per l'istanza PostgreSQL. Per i problemi associati a questi flag, consulta Controlla i flag personalizzati per l'istanza PostgreSQL.
  4. Quando esegui un upgrade da una versione principale a un'altra, prova a connetterti a ogni database per verificare se sono presenti problemi di compatibilità. Assicurati che i database possano connettersi tra loro. Controlla il campo datallowconn per ogni database per assicurarti che la connessione sia consentita. Un valore t indica che è consentito, mentre un valore f indica che non è possibile stabilire una connessione.
  5. Se utilizzi l'installazione di Datadog per eseguire l'upgrade dell'istanza Cloud SQL a PostgreSQL 10 o versioni successive, prima di eseguire l'upgrade, elimina la funzione pg_stat_activity().

  6. Gestire istanze con un numero elevato di oggetti.

    Il tempo necessario per un upgrade della versione principale in loco dipende dal numero di oggetti di database nell'istanza. Le istanze con un numero molto elevato di oggetti, in particolare tabelle e indici, potrebbero richiedere tempi di upgrade notevolmente più lunghi. Ciò aumenta il rischio di timeout dell'operazione. Cloud SQL è ottimizzato per istanze con un massimo di circa 100.000 relazioni. Se l'istanza supera questo limite, l'upgrade non viene bloccato, ma è considerato meno affidabile ed è più probabile che richieda un periodo di tempo prolungato o che non vada a buon fine dopo un timeout di 6 ore.

    Se l'istanza contiene un numero elevato di oggetti, segui questi passaggi prima di avviare il processo di upgrade principale:

    1. Controlla ed elimina gli oggetti inutilizzati: identifica e rimuovi eventuali tabelle vuote, tabelle utilizzate solo per i test o altri oggetti del database (schemi, viste, funzioni) che non sono più necessari.
    2. Strutture delle tabelle di ottimizzazione:
      • Se utilizzi il partizionamento delle tabelle, un numero eccessivo di partizioni potrebbe contribuire a un numero elevato di relazioni. In questo caso, valuta come ridurre il numero di partizioni che stai utilizzando.
      • Valuta la possibilità di eseguire la migrazione dei dati storici o ad accesso non frequente a un'opzione di datastore diversa. Ciò potrebbe ridurre il numero di tabelle attive o le dimensioni e la complessità di quelle esistenti.
    3. Esegui un test di upgrade: esegui un dry run dell'upgrade su un clone dell'istanza di produzione. In questo modo, puoi ottenere una stima realistica del tempo necessario e identificare eventuali problemi. Questa stima è particolarmente importante per i database con un numero elevato di oggetti.

    Riducendo il numero complessivo e la complessità degli oggetti, puoi ridurre i rischi e i tempi di inattività associati agli upgrade delle versioni principali.

  7. Gestisci le istanze con oggetti di grandi dimensioni (LOB).

    Il processo di upgrade in loco utilizza l'utilità PostgreSQL pg_upgrade. Questo processo può richiedere molto tempo se il database contiene un numero molto elevato di LOB, il che potrebbe causare un errore di upgrade dovuto al timeout.

    Per controllare il numero di Large Object nel tuo database, connettiti all'istanza del database utilizzando un client PostgreSQL, ad esempio psql, ed esegui questa query:

        SELECT count(*) AS total_large_objects FROM pg_largeobject_metadata;

    Se l'istanza contiene più di 30 milioni di LOB, il rischio di timeout è maggiore. Per queste istanze, valuta le seguenti azioni prima di avviare un upgrade:

    1. Esegui la pulizia degli oggetti di grandi dimensioni orfani: PostgreSQL non rimuove automaticamente i LOB che non sono più referenziati. Utilizza l'utilità vacuumlo, che fa parte del modulo contrib, per rimuovere i LOB orfani. Devi eseguire questo comando da un computer client che può connettersi alla tua istanza Cloud SQL.
      • Installa il pacchetto postgresql-contrib sulla tua macchina client se non hai vacuumlo.
      • Eseguire il seguente comando per effettuare una simulazione e verificare quali LOB verrebbero eliminati: 
                vacuumlo -h INSTANCE_IP -U DATABASE_USER --dry-run DATABASE_NAME
        Sostituisci INSTANCE_IP, DATABASE_USER e DATABASE_NAME con i dettagli dell'istanza. Ti verrà chiesta la password dell'utente.
      • Esegui questo comando per rimuovere i LOB identificati: 
                vacuumlo -h INSTANCE_IP -U DATABASE_USER DATABASE_NAME
        Dopo aver eseguito vacuumlo, controlla di nuovo il conteggio dei LOB per verificare che la pulizia sia andata a buon fine.
    2. Elimina manualmente gli oggetti di grandi dimensioni: esamina le policy sulla conservazione dei dati della tua applicazione e rimuovi tutti i LOB che non sono più necessari.
    3. Aumenta le risorse dell'istanza: aumenta le vCPU e la memoria dell'istanza in modo temporaneo o permanente. In questo modo, vengono fornite più risorse per il processo pg_upgrade.
    4. Esegui la migrazione dei dati: se il numero di LOB non può essere ridotto sufficientemente, valuta la possibilità di eseguire l'upgrade eseguendo la migrazione dei dati. Puoi creare un approccio personalizzato utilizzando pg_dump e pg_restore specificamente per le LOB. I metodi di replica logica standard potrebbero non supportare completamente i LOB, richiedendo potenzialmente passaggi aggiuntivi e tempi di inattività per la migrazione dei LOB.

  8. Registra le informazioni necessarie per ricreare tutti gli slot di replica logica nell'istanza, inclusi gli slot utilizzati da pglogical, la replica logica integrata di PostgreSQL, Datastream o qualsiasi altro consumer di decodifica logica.

Limitazioni note

Le seguenti limitazioni influiscono sugli upgrade della versione principale in loco per Cloud SQL per PostgreSQL:

  • Non puoi eseguire un upgrade della versione principale in loco su una replica esterna.
  • L'upgrade delle istanze con più di 1000 database da una versione all'altra potrebbe richiedere molto tempo e scadere.
  • Utilizza l'istruzione select * from pg_largeobject_metadata; per eseguire query sul numero di oggetti di grandi dimensioni in ogni database PostgreSQL della tua istanza Cloud SQL. Se il risultato di tutti i database è superiore a 10 milioni di oggetti di grandi dimensioni, l'upgrade non va a buon fine. Cloud SQL esegue il rollback alla versione precedente del database.
  • Prima di eseguire un upgrade della versione principale in loco a PostgreSQL 16 e versioni successive, esegui l'upgrade dell'estensione PostGIS per tutti i database alla versione 3.4.0. Per PostgreSQL 18, esegui l'upgrade a PostGIS versione 3.6.0.
  • Prima di eseguire un upgrade della versione principale in loco a PostgreSQL 17, esegui l'upgrade dell'estensione rdkit per tutti i tuoi database alla versione 4.6.1.
  • Prima di eseguire un upgrade della versione principale in loco a PostgreSQL 16, 17 o 18, esegui l'upgrade dell'estensione pg_squeeze per tutti i tuoi database alla versione 1.6, 1.7 o 1.8 rispettivamente.
  • Se utilizzi le versioni 9.6, 10, 11 o 12 di PostgreSQL, la versione 3.4.0 dell'estensione PostGIS non è supportata. Pertanto, per eseguire un upgrade della versione principale in loco a PostgreSQL 16 e versioni successive, devi prima eseguire l'upgrade a una versione intermedia di PostgreSQL (versioni 13, 14 o 15).

  • Se installi l'estensione pg_ivm per la tua istanza, non puoi eseguire l'upgrade della versione principale. Per risolvere il problema, disinstalla l'estensione e poi esegui l'upgrade. Per saperne di più sulle estensioni, consulta Configura le estensioni PostgreSQL.

  • Se attivi i flag vacuum_defer_cleanup_age e force_parallel_mode, non puoi eseguire un upgrade della versione principale. Per risolvere il problema, elimina questi flag ed esegui l'upgrade. Per ulteriori informazioni sui flag, incluso come eliminarli, consulta Configura i flag di database.

Valuta l'idoneità all'upgrade della tua istanza

Cloud SQL ti consente di eseguire un controllo preliminare sulla tua istanza prima di un upgrade alla versione principale. Questo controllo preliminare è un'operazione a lunga esecuzione (LRO) che verifica se l'istanza è pronta per un upgrade. Aiuta a trovare potenziali problemi come incompatibilità, problemi di configurazione o problemi relativi ai dati prima dell'operazione di upgrade.

Il controllo preliminare conferma che è possibile eseguire l'upgrade dell'istanza o elenca i problemi che devi risolvere prima e le relative soluzioni. Questi problemi potrebbero essere dovuti a estensioni incompatibili, dipendenze non supportate o problemi di formato dei dati.

Cloud SQL può eseguire il processo di controllo preliminare in parallelo con il tuo workload. L'esecuzione del controllo preliminare prima di eseguire l'upgrade della versione principale può aiutare a evitare un errore di upgrade.

Quando esegui il controllo preliminare, si verifica una delle seguenti situazioni:

  • Nessun problema rilevato: il controllo preliminare è stato completato correttamente e non sono stati rilevati problemi.
  • Problemi rilevati: il controllo preliminare è stato completato correttamente, ma ha rilevato errori che bloccheranno l'upgrade. I problemi devono essere risolti prima dell'upgrade.
  • Avvisi trovati: il controllo preliminare è stato completato correttamente e sono stati trovati avvisi. Esamina gli avvisi. Ti consigliamo di risolvere eventuali problemi prima di procedere con l'upgrade.

A seconda dei risultati del controllo preliminare, puoi procedere con l'upgrade o risolvere i problemi identificati prima di eseguirlo.

Limitazioni

Quando utilizzi il controllo preliminare dell'upgrade della versione principale, tieni presente le seguenti limitazioni:

  • Lo stato dell'istanza deve essere impostato su RUNNING.
  • L'istanza deve essere un'istanza principale. Il controllo preliminare non supporta le istanze di replica.

  • L'istanza non deve avere operazioni di blocco in attesa. Se è in attesa un'operazione di blocco, il controllo preliminare genera un errore con il seguente messaggio:

    Operation failed because another operation was already in progress. Try
your request after the current operation is complete.

  • Il controllo preliminare deve connettersi a tutti i database dell'istanza. Se un database è inaccessibile, bloccato o non risponde, il controllo preliminare potrebbe non riuscire o mostrare errori. Ti consigliamo di eseguire il controllo preliminare quando il carico del database è basso.

Prima di iniziare

  • Assicurati che l'API Cloud SQL Admin sia abilitata per la tua istanza.
  • Verifica di avere l'autorizzazione IAM cloudsql.instances.preCheckMajorVersionUpgrade.

Esegui il controllo preliminare

Per eseguire il controllo preliminare dell'upgrade della versione principale, segui questi passaggi:

Console

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova l'istanza su cui vuoi eseguire il controllo preliminare. Per aprire la pagina Panoramica dell'istanza, fai clic sul nome dell'istanza.
  3. Fai clic su Modifica.
  4. In Informazioni istanza, fai clic su Convalida upgrade.
  5. Nella finestra di dialogo Convalida l'upgrade, seleziona la versione del database di cui eseguire l'upgrade, quindi fai clic su Convalida.

    Viene avviata l'operazione di controllo preliminare. Monitora lo stato dell'operazione di pre-controllo nel riquadro di notifica Operazioni.

  6. Al termine dell'operazione di controllo preliminare, si apre una nuova finestra denominata Convalida i risultati dell'upgrade. Questa finestra contiene i risultati della procedura di controllo preliminare. I risultati potrebbero essere uno dei seguenti:
    • Se l'operazione di controllo preliminare non contiene errori, fai clic su Pagina di upgrade per avviare la procedura di upgrade.
    • Se l'operazione di pre-controllo contiene messaggi info, esamina i risultati. Quando è tutto pronto per eseguire l'upgrade, fai clic su Pagina di upgrade per iniziare la procedura di upgrade.
    • Se il controllo preliminare contiene messaggi warning, esamina i risultati. Ti consigliamo di risolvere questi avvisi prima di procedere con l'upgrade, ma questi messaggi non bloccano il processo di upgrade.
    • Se l'operazione di pre-controllo contiene errors, esamina i risultati. Risolvi gli errori, quindi esegui nuovamente il processo di controllo preliminare. Devi risolvere tutti gli errori prima di iniziare la procedura di upgrade.

gcloud

  1. Utilizza gcloud sql instances pre-check-major-version-upgrade per eseguire il controllo preliminare:

    gcloud  sql instances pre-check-major-version-upgrade INSTANCE_NAME \
  --target-database-version=TARGET_DATABASE_VERSION \
  --project=PROJECT_ID \
  [--async]

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza
    • TARGET_DATABASE_VERSION: la versione principale a cui vuoi eseguire l'upgrade dell'istanza. Per trovare la versione del database, consulta Pianifica un upgrade.
    • PROJECT_ID: l'ID del tuo progetto Google Cloud .

    (Facoltativo) Utilizza il flag --async per eseguire il comando in modo asincrono.

  2. Se utilizzi il flag --async per eseguire il comando pre-check-major-version-upgrade in modo asincrono, segui questi passaggi:

    1. Recupera il nome dell'operazione di pre-controllo:

      Utilizza il comando gcloud sql operations list con il flag --instance:

      gcloud sql operations list --instance=INSTANCE_NAME

      Sostituisci quanto segue:

      • INSTANCE_NAME: il nome dell'istanza

    2. Monitora lo stato del controllo preliminare.

      Utilizza il comando gcloud sql operations describe:

      gcloud sql operations describe OPERATION_NAME

      Sostituisci quanto segue:

      • OPERATION_NAME: il nome dell'operazione di pre-controllo recuperato nel passaggio precedente.
  3. Se non esegui il comando pre-check-major-version-upgrade in modo asincrono, attendi il completamento del controllo preliminare per visualizzare i risultati.

REST v1

  1. Esegui il controllo preliminare.

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • PROJECT_ID: l'ID progetto
    • INSTANCE_ID: l'ID istanza
    • TARGET_DATABASE_VERSION: la versione principale di cui eseguire l'upgrade. Per un elenco delle versioni del database disponibili, consulta Pianifica un upgrade.

    Metodo HTTP e URL: 

    POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID/preCheckMajorVersionUpgrade

    Corpo JSON della richiesta: 

    {
  "preCheckMajorVersionUpgradeContext": {
    "targetDatabaseVersion": "TARGET_DATABASE_VERSION"
  }
}

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    {
  "message": "Precheck description of finding",
  "message_type": "ERROR",
  "actions_required": [
    "Precheck action required to fix the finding"
  ]
}

  2. Ottieni il nome dell'operazione di pre-controllo.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .

  3. Monitora lo stato del controllo preliminare.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .
    • OPERATION_NAME: il nome dell'operazione di pre-controllo recuperato nel passaggio precedente.

REST v1beta4

  1. Esegui il controllo preliminare.

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • PROJECT_ID: l'ID progetto
    • INSTANCE_ID: l'ID istanza
    • TARGET_DATABASE_VERSION: la versione principale di cui eseguire l'upgrade. Per trovare un elenco delle versioni del database disponibili, consulta Pianifica un upgrade.

    Metodo HTTP e URL: 

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID/preCheckMajorVersionUpgrade

    Corpo JSON della richiesta: 

    {
  "preCheckMajorVersionUpgradeContext": {
    "targetDatabaseVersion": "TARGET_DATABASE_VERSION"
  }
}

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    {
  "message": "Precheck description of finding",
  "message_type": "ERROR",
  "actions_required": [
    "Precheck action required to fix the finding"
  ]
}

  2. Ottieni il nome dell'operazione di pre-controllo.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .

  3. Monitora lo stato del controllo preliminare.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operation/OPERATION_NAME

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .
    • operation_name: il nome dell'operazione di pre-controllo recuperato nel passaggio precedente.

Esamina i risultati del controllo preliminare

Al termine del controllo preliminare, l'istanza è pronta per l'upgrade o presenta problemi che richiedono la tua attenzione.

Pronto per l'upgrade

Se il controllo preliminare viene completato correttamente e l'array preCheckResponse è vuoto, significa che non sono stati rilevati problemi o avvisi. L'istanza è pronta per l'upgrade della versione principale. Per continuare, consulta Esegui l'upgrade della versione principale.

Non pronto per l'upgrade

Se il controllo preliminare è stato eseguito correttamente e l'array preCheckResponse contiene problemi, l'istanza non è pronta per l'upgrade e richiede attenzione. I problemi identificati potrebbero bloccare o meno l'upgrade. Questi problemi sono indicati nel preCheckResponse con i seguenti tipi di messaggi:

Tipo Descrizione Blocco degli upgrade?
INFO Un messaggio informativo. No
WARNING È stato rilevato un potenziale problema, ma non blocca l'upgrade. Cloud SQL consiglia di esaminare e risolvere l'avviso prima di eseguire l'upgrade per garantire la compatibilità completa. No
ERROR È stato rilevato un problema critico che blocca l'upgrade. Questi problemi potrebbero causare l'interruzione dell'upgrade. Devi risolverli prima di eseguire l'upgrade dell'istanza. Sì
Se l'istanza contiene solo messaggi INFO o WARNING, puoi eseguirne l'upgrade, ma potresti riscontrare problemi dopo l'upgrade. Ti consigliamo di esaminare i dettagli del messaggio e di risolvere il problema prima di eseguire l'upgrade. Se la tua istanza contiene ERROR messaggi, devi risolvere questi problemi prima di eseguire l'upgrade.

Ogni tipo di problema include un campo message e un campo actions_required. Esamina ogni problema per comprenderne il tipo e come risolverlo. Per saperne di più sui problemi comuni e sulle relative soluzioni, consulta Errori comuni dei controlli preliminari per l'upgrade della versione principale.

Dopo aver risolto i problemi, esegui nuovamente il controllo preliminare per verificare che l'istanza sia pronta per l'upgrade. Poi, procedi con l'upgrade dell'istanza una volta completato il controllo preliminare.

Esegui l'upgrade della versione principale

Puoi eseguire l'upgrade della versione principale di una singola istanza Cloud SQL oppure puoi eseguire l'upgrade della versione principale di un'istanza principale e includere nell'upgrade tutte le sue repliche, incluse le repliche in cascata e tra regioni.

Esegui l'upgrade della versione principale di una singola istanza

Quando avvii un'operazione di upgrade per una singola istanza, Cloud SQL esegue le seguenti operazioni:

  1. Controlla la configurazione dell'istanza per assicurarsi che sia compatibile con un upgrade.
  2. Dopo che Cloud SQL ha verificato la configurazione, l'istanza non è più disponibile.
  3. Esegue un backup pre-upgrade.
  4. Esegue l'upgrade dell'istanza.
  5. Rende disponibile l'istanza.
  6. Esegue un backup post-upgrade.

Console

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Per aprire la pagina Panoramica di un'istanza, fai clic sul nome dell'istanza.
  3. Fai clic su Modifica.
  4. Nella sezione Informazioni sull'istanza, fai clic sul pulsante Esegui l'upgrade e conferma che vuoi andare alla pagina di upgrade.
  5. Nella pagina Scegli una versione del database, fai clic sull'elenco Versione del database per l'upgrade e seleziona una delle versioni principali del database disponibili.
  6. Fai clic su Continua.
  7. Nella casella ID istanza, inserisci il nome dell'istanza e fai clic sul pulsante Avvia l'upgrade.
Il completamento dell'operazione richiede diversi minuti.

Verifica che la versione principale del database di cui è stato eseguito l'upgrade venga visualizzata sotto il nome dell'istanza nella pagina Panoramica dell'istanza.

gcloud

  1. Avvia l'upgrade.

    Utilizza il comando gcloud sql instances patch con il flag --database-version.

    Prima di eseguire il comando, sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza.
    • DATABASE_VERSION: l'enum per la versione principale del database, che deve essere successiva alla versione attuale. Specifica una versione del database per una versione principale disponibile come target di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio della Pianificazione dell'upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Il completamento degli upgrade della versione principale richiede alcuni minuti. Potresti visualizzare un messaggio che indica che l'operazione sta richiedendo più tempo del previsto. Puoi ignorare questo messaggio o eseguire il comando gcloud sql operations wait per chiuderlo.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza il comando gcloud sql operations list con il flag --instance.

    Prima di eseguire il comando, sostituisci quanto segue: * INSTANCE_NAME: il nome dell'istanza. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitora lo stato dell'upgrade.

    Utilizza il comando gcloud sql operations describe.

    Prima di eseguire il comando, sostituisci la variabile OPERATION con il nome dell'operazione di upgrade recuperato nel passaggio precedente. 

    gcloud sql operations describe OPERATION

REST v1

  1. Avvia l'upgrade in loco.

    Utilizza una richiesta PATCH con il metodo instances:patch.

    Prima di utilizzare i dati della richiesta, sostituisci queste variabili:

    • PROJECT_ID: l'ID del progetto.
    • INSTANCE_NAME: il nome dell'istanza.

    Metodo HTTP e URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Corpo JSON della richiesta: 

    {
  "databaseVersion": DATABASE_VERSION
}

    Sostituisci DATABASE_VERSION con l'enum della versione principale del database, che deve essere successiva alla versione corrente. Specifica una versione del database per una versione principale disponibile come target di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio della Pianificazione dell'upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseVersion.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza una richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitora lo stato dell'upgrade.

    Utilizza una richiesta GET con il metodo operations.get dopo aver sostituito le seguenti variabili:

    • PROJECT_ID: l'ID del progetto.
    • OPERATION_NAME: il nome dell'operazione di upgrade recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Per eseguire l'upgrade della versione principale del database utilizzando Terraform, devi impostare l'argomento database_version nella definizione della risorsa google_sql_database_instance sulla versione principale di destinazione. Devi utilizzare il provider Terraform per Google Cloud versione 4.34.0 o successive.

Gli esempi seguenti mostrano una configurazione google_sql_database_instance di base. Per eseguire l'upgrade della versione principale, imposta l'argomento database_version sulla versione principale pertinente.

resource "google_sql_database_instance" "default" {
  name             = "postgres-instance"
  region           = "us-central1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
  }
}

Apporta le seguenti modifiche agli argomenti di Terraform:

  • database_version: imposta questo valore sulla versione principale di destinazione per l'upgrade.
  • deletion_protection: definisce la protezione Terraform a livello di root contro l'eliminazione dell'istanza.
    • true: impedisce a Terraform di eliminare l'istanza. Qualsiasi operazione Terraform che prevede l'eliminazione di questa risorsa è bloccata.
    • false: consente a Terraform di eliminare l'istanza.

Esamina il piano Terraform

Prima di applicare qualsiasi modifica, esegui sempre terraform plan e controlla attentamente l'output. I simboli accanto al nome della risorsa indicano come Terraform applicherà le modifiche:

  • ~ Aggiornamento in loco: questo simbolo indica che Terraform modificherà l'istanza esistente. Questo è il risultato previsto e sicuro per un upgrade della versione principale in loco quando si modifica database_version.
  • +/- Ricrea (sostituzione forzata): questo simbolo indica che Terraform prevede di eliminare l'istanza corrente e crearne una nuova.
    • Se deletion_protection è impostato su true, Terraform genera un errore e blocca questa sostituzione pericolosa. Dovresti impostare esplicitamente deletion_protection = false nella configurazione ed eseguire di nuovo terraform apply per aggiornare lo stato, prima che un successivo apply consenta la distruzione e la ricreazione.
    • Se deletion_protection è impostato su false, terraform apply procederà con la perdita di dati.

    La sostituzione (eliminazione e nuova creazione) delle istanze può essere pianificata a causa di una modifica della configurazione o di un percorso di upgrade non supportato per la modifica in loco. Se trovi un'istanza per cui è pianificata l'eliminazione e la nuova creazione, devi interrompere immediatamente l'operazione e indagare sul motivo della sostituzione pianificata prima che proceda.

Dopo aver esaminato l'output di terraform plan per assicurarti che indichi solo un aggiornamento in loco (~) per la modifica della versione del database, applica la configurazione

Per applicare la configurazione Terraform in un progetto Google Cloud , completa i passaggi descritti nelle sezioni seguenti.

Prepara Cloud Shell

  1. Avvia Cloud Shell.

  2. Imposta il progetto Google Cloud predefinito in cui vuoi applicare le configurazioni Terraform.

    Devi eseguire questo comando una sola volta per progetto e puoi eseguirlo in qualsiasi directory.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Le variabili di ambiente vengono sostituite se imposti valori espliciti nel file di configurazione Terraform.

Prepara la directory

Ogni file di configurazione Terraform deve avere la propria directory (chiamata anche modulo principale).

  1. In Cloud Shell, crea una directory e un nuovo file al suo interno. Il nome file deve avere l'estensione .tf, ad esempio main.tf. In questo tutorial, il file è denominato main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Se stai seguendo un tutorial, puoi copiare il codice campione in ogni sezione o passaggio.

    Copia il codice campione nel file main.tf appena creato.

    Facoltativamente, copia il codice da GitHub. Questa opzione è consigliata quando lo snippet Terraform fa parte di una soluzione end-to-end.

  3. Esamina e modifica i parametri di esempio da applicare al tuo ambiente.
  4. Salva le modifiche.
  5. Inizializza Terraform. Devi eseguire questa operazione una sola volta per directory. 
    terraform init

    Facoltativamente, per utilizzare l'ultima versione del provider Google, includi l'opzione -upgrade: 

    terraform init -upgrade

Applica le modifiche

  1. Esamina la configurazione e verifica che le risorse che Terraform creerà o aggiornerà corrispondano alle tue aspettative: 
    terraform plan

    Apporta le correzioni necessarie alla configurazione.

  2. Applica la configurazione Terraform eseguendo il comando seguente e inserendo yes al prompt: 
    terraform apply

    Attendi finché Terraform non visualizza il messaggio "Apply complete!".

  3. Apri il tuo progetto Google Cloud per visualizzare i risultati. Nella console Google Cloud , vai alle risorse nell'interfaccia utente per assicurarti che Terraform le abbia create o aggiornate.

Quando effettui una richiesta di upgrade sul posto, Cloud SQL esegue prima un controllo pre-upgrade. Se Cloud SQL determina che l'istanza non è pronta per un upgrade, la richiesta di upgrade non va a buon fine e viene visualizzato un messaggio che suggerisce come risolvere il problema. Consulta anche Risolvi i problemi relativi all'upgrade di una versione principale.

Includi le repliche nell'upgrade della versione principale

Se l'istanza principale ha delle repliche, puoi includerle tutte nell'upgrade. Cloud SQL può eseguire l'upgrade di tutte le repliche dell'istanza principale, incluse le repliche tra regioni e le repliche a cascata.

Quando includi le repliche in un upgrade della versione principale, Cloud SQL esegue le seguenti operazioni:

  1. Controlla la configurazione dell'istanza principale e delle repliche per assicurarsi che siano compatibili per un upgrade.
  2. Rende non disponibile l'istanza principale.
  3. Esegue un backup pre-upgrade dell'istanza principale.
  4. Interrompe la replica per tutte le repliche.
  5. Esegue l'upgrade sull'istanza principale.
  6. Se l'upgrade dell'istanza principale va a buon fine, l'istanza principale diventa nuovamente disponibile e riavvia la replica.
  7. Cloud SQL esegue un backup post-upgrade dell'istanza principale.
  8. Cloud SQL procede con l'upgrade di tutte le repliche.

Anche se l'upgrade della versione principale di una replica non va a buon fine, l'istanza principale continua a essere disponibile.

Per includere le repliche in un upgrade della versione principale, non puoi utilizzare la consoleGoogle Cloud o Terraform. Puoi utilizzare solo gcloud CLI o l'API Cloud SQL Admin.

gcloud

  1. Avvia l'upgrade.

    Utilizza il comando gcloud sql instances patch con i flag --database-version e --include-replicas-for-major-version-upgrade.

    Prima di eseguire il comando, sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza principale.
    • DATABASE_VERSION: l'enum per la versione principale del database, che deve essere successiva alla versione attuale. Specifica una versione del database per una versione principale disponibile come target di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio della Pianificazione dell'upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --include-replicas-for-major-version-upgrade

    Il completamento degli upgrade della versione principale richiede alcuni minuti. Potresti visualizzare un messaggio che indica che l'operazione sta richiedendo più tempo del previsto. Puoi ignorare questo messaggio o eseguire il comando gcloud sql operations wait per chiuderlo. L'upgrade delle repliche può richiedere diversi minuti. Per controllare lo stato dell'upgrade, segui questi passaggi:

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza il comando gcloud sql operations list con il flag --instance.

    Prima di eseguire il comando, sostituisci la variabile INSTANCE_NAME con il nome dell'istanza. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitora lo stato dell'upgrade.

    Utilizza il comando gcloud sql operations describe.

    Prima di eseguire il comando, sostituisci la variabile OPERATION con il nome dell'operazione di upgrade recuperato nel passaggio precedente. 

    gcloud sql operations describe OPERATION

REST

  1. Avvia l'upgrade in loco.

    Utilizza una richiesta PATCH con il metodo instances:patch.

    Prima di utilizzare i dati della richiesta, sostituisci queste variabili:

    • PROJECT_ID: l'ID del progetto
    • INSTANCE_NAME: il nome dell'istanza

    Metodo HTTP e URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Corpo JSON della richiesta: 

    {
  "databaseVersion": DATABASE_VERSION
  "includeReplicasForMajorVersionUpgrade": true
}
    • Sostituisci DATABASE_VERSION con l'enum della versione principale del database, che deve essere successiva alla versione corrente. Specifica una versione del database per una versione principale disponibile come target di upgrade per l'istanza. Puoi ottenere questo enum come primo passaggio della Pianificazione dell'upgrade. Se hai bisogno di un elenco completo degli enum delle versioni del database, consulta SqlDatabaseVersion.
    • Nel campo includeReplicasForMajorVersionUpgrade, specifica true.

  2. Recupera il nome dell'operazione di upgrade.

    Utilizza una richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitora lo stato dell'upgrade.

    Utilizza una richiesta GET con il metodo operations.get dopo aver sostituito le seguenti variabili:

    • PROJECT_ID: l'ID del progetto
    • OPERATION_NAME: il nome dell'operazione di upgrade recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Backup degli upgrade automatici

Quando esegui un upgrade della versione principale, Cloud SQL esegue automaticamente due backup on demand, chiamati backup di upgrade:

  • Il primo backup dell'upgrade è il backup pre-upgrade, che viene eseguito immediatamente prima di iniziare l'upgrade. Puoi utilizzare questo backup per ripristinare l'istanza del database allo stato della versione precedente.
  • Il secondo backup di upgrade è il backup post-upgrade, che viene eseguito immediatamente dopo che sono consentite nuove scritture nell'istanza del database di cui è stato eseguito l'upgrade.

Quando visualizzi l'elenco dei backup, i backup di upgrade sono elencati con il tipo On-demand. I backup di upgrade sono etichettati in modo da poterli identificare rapidamente. Ad esempio, se esegui l'upgrade da PostgreSQL 14 a PostgreSQL 15, il backup pre-upgrade è etichettato come Pre-upgrade backup, POSTGRES_14 to POSTGRES_15. e il backup post-upgrade è etichettato come Post-upgrade backup, POSTGRES_14 to POSTGRES_15..

Come per gli altri backup on demand, i backup di upgrade vengono conservati fino a quando non li elimini o non elimini l'istanza. Se hai attivato il PITR, non puoi eliminare i backup di upgrade mentre si trovano nella finestra di conservazione. Se devi eliminare i backup dell'upgrade, devi disattivare il PITR o attendere che i backup dell'upgrade non rientrino più nella finestra di conservazione.

Annulla l'upgrade della versione principale

Puoi annullare un'operazione di upgrade della versione principale in loco, ma solo mentre l'istanza esegue l'upgrade della versione effettiva.

Finestra di annullamento

Un upgrade della versione principale prevede una sequenza di passaggi. Puoi annullare l'upgrade solo durante la fase principale.

  1. Inizializzazione: Cloud SQL prepara l'istanza e le relative risorse. Non puoi annullare l'operazione durante questa fase.

  2. Fase di upgrade principale: Cloud SQL esegue l'upgrade attivo dei dati alla nuova versione principale. Puoi annullare l'operazione solo durante questa fase.

  3. Finalizzazione: l'istanza completa l'upgrade ed esegue le verifiche finali.

Per determinare quando l'istanza è entrata nella fase annullabile, controlla la disponibilità dei log di upgrade. I log di upgrade sono disponibili all'indirizzo projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log

Quando le voci di log iniziano a essere visualizzate in questo file di log, la fase di upgrade principale è attiva e puoi annullare l'operazione.

Esegui l'annullamento

Per annullare un upgrade della versione principale in loco, devi avere l'ID dell'operazione. Devi specificare questo ID nel comando gcloud o dell'API REST in modo che Cloud SQL sappia quale operazione annullare.

Puoi utilizzare i comandi gcloud o dell'API REST per annullare un'operazione di upgrade della versione principale.

gcloud

  1. Recupera l'ID dell'operazione di upgrade.

    Utilizza il comando gcloud sql operations list con il flag --instance:

    gcloud sql operations list --instance=INSTANCE_NAME

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza

  2. Annullare l'upgrade.

    Utilizza il comando gcloud sql operations cancel:

    gcloud sql operations cancel OPERATION_ID

    Sostituisci quanto segue:

    • OPERATION_ID: l'ID operazione recuperato nel passaggio precedente.

  3. Controlla lo stato di annullamento.

    Utilizza il comando gcloud sql operations describe:

    gcloud sql operations describe OPERATION_ID

    Sostituisci quanto segue:

    • OPERATION_ID: l'ID operazione recuperato nel primo passaggio.

REST v1

  1. Recupera l'ID dell'operazione di upgrade.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .

  2. Annullare l'upgrade.

    Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .
    • OPERATION_ID: l'ID operazione recuperato nel passaggio precedente.

    Metodo HTTP e URL: 

    POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID/cancel

    Per inviare la richiesta, espandi una di queste opzioni:

    Dovresti ricevere una risposta JSON simile alla seguente:

    Questa chiamata API REST non restituisce alcuna risposta.

  3. Controlla lo stato di annullamento.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .
    • OPERATION_ID: l'ID operazione recuperato nel primo passaggio.

REST v1beta4

  1. Recupera l'ID dell'operazione di upgrade.

    Utilizza la richiesta GET con il metodo operations.list dopo aver sostituito PROJECT_ID con l'ID del progetto.

    GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .

  2. Annullare l'upgrade.

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud .
  • OPERATION_ID: l'ID operazione recuperato nel passaggio precedente.

Metodo HTTP e URL: 

POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID/cancel

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Questa chiamata API REST non restituisce alcuna risposta.

  1. Controlla lo stato di annullamento.

    Utilizza la richiesta GET con il metodo operations.list:

    GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del tuo progetto Google Cloud .
    • OPERATION_ID: l'ID operazione recuperato nel primo passaggio.

Se la richiesta di annullamento viene accettata, Cloud SQL interrompe il processo di upgrade in corso e inizia a ripristinare l'istanza allo stato originale.

Risolvi i problemi di annullamento

Problema Risoluzione dei problemi

Messaggio di errore: The operation OPERATION_ID cannot be canceled at the moment. Please retry in approximately 5-10 minutes

 L'upgrade non ha ancora raggiunto la finestra annullabile. Attendi qualche minuto e riprova ad annullare.

Messaggio di errore: The operation OPERATION_ID cannot be cancelled as it has passed the cancellable state. The operation is in its final stage and should complete soon.

 La procedura di upgrade ha superato la finestra di annullamento. L'annullamento non è più possibile e l'upgrade dovrebbe terminare a breve.

Messaggio di errore: You can't cancel operation OPERATION_ID because it isn't in progress.

 L'operazione è già stata completata, con esito positivo o negativo, e non può più essere annullata.

Messaggi di errore:

  • You can't cancel operation OPERATION_ID because Cloud SQL doesn't support the cancellation of this OPERATION_TYPE operation.
  • The operation OPERATION_ID cannot be cancelled.
 Questo errore si verifica in genere quando passi un valore OPERATION_ID errato al comando cancel, in particolare l'ID di un tipo di operazione che non supporta l'annullamento. Verifica di utilizzare l'OPERATION_ID associato all'upgrade della versione principale del database in loco che vuoi annullare.

Se l'annullamento non è andato a buon fine dopo l'accettazione della richiesta di annullamento, devi ripristinare l'istanza dal backup pre-upgrade eseguito automaticamente all'inizio del processo. Se i problemi persistono, contatta l'assistenzaGoogle Cloud .

Completa l'upgrade della versione principale

Dopo aver completato l'upgrade dell'istanza principale, esegui i seguenti passaggi per completare l'upgrade:

  1. Aggiorna le statistiche del database.

    Esegui ANALYZE sull'istanza principale per aggiornare le statistiche di sistema dopo l'upgrade. Statistiche accurate assicurano che Query Planner di PostgreSQL elabori le query in modo ottimale. La mancanza di statistiche può portare a piani di query errati, che a loro volta potrebbero peggiorare le prestazioni e occupare troppa memoria.

  2. Esegui test di accettazione.

    Esegui test per assicurarti che il sistema aggiornato funzioni come previsto.

  3. Per evitare l'interruzione degli stream di replica, ricrea gli slot di replica logica dell'istanza utilizzando le informazioni registrate prima di avviare l'upgrade (consulta Preparati a un upgrade della versione principale).

Risolvi i problemi relativi all'upgrade della versione principale

Cloud SQL restituisce un messaggio di errore se tenti un comando di upgrade non valido, ad esempio se l'istanza contiene flag di database non validi per la nuova versione.

Se la richiesta di upgrade non va a buon fine, controlla la sintassi della richiesta. Se la richiesta ha una struttura valida, prova a esaminare i seguenti suggerimenti.

Visualizza log degli errori

Se si verificano problemi con una richiesta di upgrade valida, Cloud SQL pubblica i log degli errori in projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log. Ogni voce di log contiene un'etichetta con l'identificatore dell'istanza per aiutarti a identificare l'istanza con l'errore di upgrade. Cerca questi errori di upgrade e risolvili.

Per visualizzare i log degli errori, utilizza la console Google Cloud:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Per aprire la pagina Panoramica di un'istanza, fai clic sul nome dell'istanza.

  3. Nel riquadro Operazioni e log della pagina Panoramica dell'istanza, fai clic sul link Visualizza i log degli errori PostgreSQL.

    Viene visualizzata la pagina Esplora log.

  4. Visualizza i log nel seguente modo:

    • Per elencare tutti i log degli errori in un progetto, seleziona il nome del log nel filtro Nome log.

    Per saperne di più sui filtri delle query, consulta Query avanzate.

    • Per filtrare i log degli errori di upgrade per una singola istanza, inserisci la seguente query nella casella Cerca in tutti i campi, dopo aver sostituito DATABASE_ID

    con l'ID progetto seguito dal nome dell'istanza in questo formato: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

    Ad esempio, per filtrare i log degli errori di upgrade in base a un'istanza denominata shopping-db in esecuzione nel progetto buylots, utilizza il seguente filtro di query:

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fpostgres-upgrade.log"

    Puoi esaminare tutti i log segnalati in un determinato periodo di tempo o filtrarli in base alla gravità. Un'opzione comune per la risoluzione dei problemi potrebbe includere la selezione dei seguenti filtri:

    • Emergenza
    • Avviso
    • Critico
    • Errore

Le voci di log con il prefisso pg_upgrade_dump indicano che si è verificato un errore di upgrade. Ad esempio:

pg_upgrade_dump: error: query failed: ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transaction.

Inoltre, le voci di log etichettate con un nome file secondario .txt potrebbero elencare altri errori che potresti voler risolvere prima di riprovare l'upgrade.

Tutti i nomi file si trovano nel file postgres-upgrade.log. Per individuare un nome file, controlla il campo labels.FILE_NAME.

I nomi file che potrebbero contenere errori da risolvere includono:

  • tables_with_oids.txt: Questo file contiene tabelle elencate con identificatori di oggetti (OID). Elimina le tabelle o modificale in modo che non utilizzino gli OID.
  • tables_using_composite.txt: Questo file contiene tabelle elencate utilizzando tipi compositi definiti dal sistema. Elimina le tabelle o modificale in modo che non utilizzino questi tipi compositi.
  • tables_using_unknown.txt: Questo file contiene tabelle elencate utilizzando il tipo di dati UNKNOWN. Elimina le tabelle o modificale in modo che non utilizzino questo tipo di dati.
  • tables_using_sql_identifier.txt: Questo file contiene tabelle elencate utilizzando il tipo di dati SQL_IDENTIFIER. Elimina le tabelle o modificale in modo che non utilizzino questo tipo di dati.
  • tables_using_reg.txt: Questo file contiene tabelle elencate utilizzando il tipo di dati REG* (ad esempio REGCOLLATION o REGNAMESPACE). Elimina le tabelle o modificale in modo che non utilizzino questo tipo di dati.
  • postfix_ops.txt: Questo file contiene tabelle elencate utilizzando operatori postfix (unari a destra). Elimina le tabelle o modificale in modo che non utilizzino questi operatori.

Controlla la memoria

Se l'istanza non dispone di memoria condivisa sufficiente, potresti visualizzare questo messaggio di errore: ERROR: out of shared memory. Questo errore è più probabile che si verifichi se hai più di 10.000 tabelle.

Prima di tentare un upgrade, imposta il valore del flag max_locks_per_transaction su un valore pari a circa il doppio del numero di tabelle nell'istanza. L'istanza viene riavviata quando modifichi il valore di questo flag.

Controlla la capacità delle connessioni

Se l'istanza non ha una capacità di connessione sufficiente, potresti visualizzare questo messaggio di errore: ERROR: Insufficient connections.

Cloud SQL consiglia di aumentare il valore del flag max_connections in base al numero di database nell'istanza. L'istanza viene riavviata quando modifichi il valore di questo flag.

Controlla se è presente un riferimento di colonna ambiguo

Cloud SQL esegue automaticamente un controllo pre-upgrade per identificare le viste definite dall'utente che dipendono dalle viste del catalogo di sistema, come pg_stat_activity o pg_stat_replication. La struttura delle colonne di queste viste del catalogo di sistema può cambiare tra le versioni principali di PostgreSQL. Se hai viste che select * o si basano sull'ordine delle colonne di queste viste di sistema, potrebbero diventare incompatibili dopo un upgrade, generando un errore, ad esempio ERROR: column reference "column_name" is ambiguous.

Il controllo pre-upgrade rileva queste viste verificando la presenza di dipendenze. Se vengono trovate visualizzazioni incompatibili, il processo di upgrade viene interrotto e viene visualizzato un messaggio di errore. Questo messaggio elenca le viste incompatibili in ogni database che devono essere corrette.

Esempio di messaggio di errore

  • Per problemi relativi a pg_stat_activity: 

    Please remove the following usages of views that depend on functions returning
data types of pg_stat_activity before attempting an upgrade:
(database: my_db, schema name: public, view name: my_stat_activity_view)

  • Per problemi relativi a pg_stat_replication:

    Please remove the following usages of views that depend on functions returning
data types of pg_stat_replication before attempting an upgrade:
(database: my_db, schema name: public, view name: my_replication_stats_view)

Per risolvere questi problemi e procedere con l'upgrade: 1. Identifica le viste elencate nel messaggio di errore del controllo pre-upgrade.

  1. Elimina queste visualizzazioni utilizzando DROP VIEW view_name;.

  2. Riprova a eseguire l'upgrade della versione principale.

  3. Al termine dell'upgrade, ricrea le visualizzazioni. Assicurati che le nuove definizioni delle viste siano compatibili con lo schema delle viste del catalogo di sistema nella versione attuale di PostgreSQL. Potresti dover elencare esplicitamente le colonne anziché utilizzare select * per evitare problemi futuri.

Per un esempio più dettagliato del problema e ulteriori approfondimenti, consulta questa discussione su Stack Overflow.

Controlla la presenza di SRF nelle istruzioni CASE

Se esegui l'upgrade dell'istanza da PostgreSQL 9.6 e utilizzi funzioni che restituiscono set nelle istruzioni CASE, potresti visualizzare questo messaggio di errore ERROR: set-returning functions are not allowed in CASE. Questo problema si verifica perché, a partire dalla versione 10, non è consentito l'utilizzo di funzioni che restituiscono set nelle istruzioni CASE.

Per risolvere il problema ed eseguire l'upgrade dell'istanza, assicurati che tutte le istruzioni CASE che utilizzano funzioni che restituiscono set vengano modificate per evitarne l'uso prima di riprovare l'upgrade. Ecco alcuni SRF di uso comune:

  • unnest()
  • generate_series()
  • array_agg()
  • regexp_split_to_table()
  • jsonb_array_elements()
  • json_array_elements()
  • sonb_each()
  • json_each()

Controlla le viste create su cast personalizzati

Se hai una vista creata su un cast personalizzato, viene visualizzato un messaggio di errore simile al seguente: ERROR: cannot cast type <type_1> to <type_2>. Questo problema si verifica a causa di problemi di autorizzazione relativi ai cast creati in modo personalizzato.

Per risolvere il problema, aggiorna l'istanza a [PostgreSQL version].R20240910.01_02

Per saperne di più, consulta Manutenzione self-service.

Controlla la proprietà del trigger di eventi

In Cloud SQL, tutti i trigger di eventi devono essere di proprietà di un utente con il ruolo cloudsqlsuperuser. Cloud SQL esegue un controllo pre-upgrade per convalidare la proprietà di tutti i trigger di eventi. Se un trigger di evento è di proprietà di un utente che non dispone del ruolo cloudsqlsuperuser, il processo di upgrade viene interrotto e potresti ricevere un messaggio di errore, ad esempio:

Please ensure that the owners of all event triggers have the cloudsqlsuperuser
role assigned to them before attempting an upgrade:
(database: your_db, triggerName your_trigger, owner: non_super_user)

Per risolvere il problema, cambia il proprietario del trigger di eventi in un utente con il ruolo cloudsqlsuperuser, ad esempio postgres, oppure concedi il ruolo cloudsqlsuperuser al proprietario attuale.

Per identificare i trigger di eventi con proprietari che non dispongono del ruolo richiesto, esegui il seguente comando:

SELECT
  t.evtname AS trigger_name,
  r.rolname AS current_owner
FROM pg_event_trigger t
JOIN pg_roles r ON t.evtowner = r.oid
WHERE NOT pg_has_role(r.rolname, 'cloudsqlsuperuser', 'member');

I risultati mostrano tutti i trigger di eventi con un proprietario che non ha il ruolo cloudsqlsuperuser.

Controlla le colonne generate dalle tabelle non registrate

Se hai una tabella non registrata con colonne generate, potresti visualizzare il messaggio di errore ERROR: unexpected request for new relfilenumber in binary upgrade mode. Questo problema si verifica a causa di discrepanze nelle caratteristiche di persistenza tra le tabelle e le relative sequenze per le colonne generate.

Per risolvere questo problema:

  1. Elimina le tabelle non registrate: se possibile, elimina tutte le tabelle non registrate collegate alle colonne generate. Prima di procedere, assicurati che la perdita di dati possa essere mitigata in sicurezza.
  2. Converti in tabelle permanenti: converti temporaneamente le tabelle non registrate in tabelle permanenti seguendo questi passaggi:
    1. Converti la tabella in una tabella registrata ALTER TABLE SET LOGGED;
    2. Esegui l'upgrade della versione principale
    3. Converti la tabella in una tabella non registrata ALTER TABLE SET UNLOGGED

Puoi identificare tutte queste tabelle utilizzando la seguente query :

SELECT
  relnamespace::regnamespace,
  c.relname AS table_name,
  a.attname AS column_name,
  a.attidentity AS identity_type
FROM
  pg_catalog.pg_class c
  JOIN pg_catalog.pg_attribute a ON a.attrelid = c.oid
WHERE
  a.attidentity IN ('a', 'd') AND c.relkind = 'r' AND c.relpersistence = 'u'
ORDER BY c.relname, a.attname;

Controlla i flag personalizzati per l'istanza PostgreSQL

Se esegui l'upgrade a un'istanza PostgreSQL, versione 14 o successive, controlla i nomi di tutti i flag di database configurati per l'istanza. Questo perché PostgreSQL ha introdotto ulteriori limitazioni sui nomi consentiti per i parametri personalizzati.

Il primo carattere di un flag di database personalizzato deve essere alfabetico (A-Z o a-z). Tutti i caratteri successivi possono essere alfanumerici, il carattere speciale trattino basso (_) o il carattere speciale simbolo del dollaro ($).

Rimuovi estensioni

Se esegui l'upgrade dell'istanza Cloud SQL, potresti visualizzare questo messaggio di errore: pg_restore: error: could not execute query: ERROR: role "16447" does not exist.

Per risolvere il problema, procedi nel seguente modo:

  1. Rimuovi le estensioni pg_stat_statements e pgstattuple.
  2. Esegui l'upgrade.
  3. Reinstalla le estensioni.

Operazione MVU in esecuzione per un periodo di tempo più lungo

Esistono due attività di base associate a un upgrade della versione principale:

  • Operazione di controllo preliminare: restituisce un errore di timeout se non viene completata entro tre ore.
  • Operazione di upgrade: restituisce un errore di timeout se non viene completata entro sei ore.

Se l'istanza ha un'operazione MAJOR_VERSION_UPGRADE in corso per un periodo di tempo più lungo del previsto, esamina i log degli errori di PostgreSQL. Ciò potrebbe essere dovuto a problemi comuni, ad esempio:

  • Un numero elevato di tabelle, viste o indici
  • Risorse insufficienti, ad esempio CPU o memoria
  • Transazioni principali che bloccano l'arresto dei database per l'avvio del processo di upgrade. Puoi utilizzare la console Google Cloud per controllare i processi in corso.

Errori comuni dei controlli preliminari per l'upgrade della versione principale

I problemi rilevati dal controllo preliminare dell'upgrade della versione principale rientrano nelle seguenti categorie:

  • Estensioni incompatibili: si tratta di estensioni Cloud SQL per PostgreSQL nell'istanza che non funzionano con la nuova versione principale.

  • Dipendenze non supportate: si tratta di dipendenze che non sono supportate dalla nuova versione principale o che richiedono aggiornamenti per funzionare con quest'ultima.

  • Incompatibilità del database: si tratta di problemi con il database o i dati che potrebbero verificarsi dopo un upgrade della versione principale. Sono incluse le differenze nelle strutture dei database, nei tipi di dati, nella codifica, nelle regole di confronto o nelle modifiche al catalogo di sistema specifiche della nuova versione.

Estensioni incompatibili

La tabella seguente elenca gli errori comuni relativi alle estensioni incompatibili che potrebbero essere rilevati dal controllo preliminare dell'upgrade della versione principale:

Tipo Esempio di errore Risoluzione
Estensione non supportata o deprecata Your installation contains unsupported extensions for the new version. These extensions must be removed before attempting an upgrade: (database: %s, Extension name: %s) Rimuovi l'estensione da tutti i database che la utilizzano con DROP EXTENSION $extension_name;.
Versione dell'estensione non compatibile Your installation contains incompatible version extensions. These extensions must be upgraded to a compatible version before attempting an upgrade: (database: %s, Extension name: %s) Aggiorna l'estensione a una versione compatibile con la versione di Cloud SQL per PostgreSQL di destinazione. Per le versioni compatibili, consulta Configura le estensioni Cloud SQL per PostgreSQL.
PostGIS file non pacchettizzati PostGIS version upgrade has not been completed, unpackaged raster files present. Follow the steps at https://postgis.net/documentation/tips/tip-removing-raster-from-2-3/ to fix before major version upgrade. Elimina i file raster non pacchettizzati.
PostGIS funzioni ritirate PostGIS version upgrade has not been completed, deprecated functions present. Please drop all objects using deprecated functions and upgrade to a different version of PostGIS before major version upgrade. Trova e rimuovi o modifica gli oggetti del database che utilizzano funzioni PostGIS deprecate prima di eseguire l'upgrade dell'estensione PostGIS.
Proprietà dell'estensione Please ensure that the owner of the postgres_fdw extension has the cloudsqlsuperuser role assigned to them before attempting an upgrade: (database: my_db, extension name: postgres_fdw, owner: some_user) Cambia il proprietario dell'estensione utilizzando ALTER EXTENSION postgres_fdw OWNER TO postgres;.

Dipendenze non supportate

La tabella seguente elenca gli errori comuni relativi alle dipendenze non supportate che potrebbero essere rilevati dal controllo preliminare dell'upgrade della versione principale:

Tipo Esempio di errore Risoluzione
Proprietà dei trigger evento Please ensure that the owners of all event triggers have the cloudsqlsuperuser role assigned to them before attempting an upgrade: (database: your_db, triggerName your_trigger, owner: non_super_user) Connettiti al database identificato utilizzando psql o Cloud SQL Studio e cambia il proprietario del trigger in un utente postgres.
Istruzioni preparate non sottoposte a commit Please commit/rollback the following usages of 'Uncommitted Prepared Statements'... (database: my_db, gid: my_prepared_xact) Esegui il commit o il rollback dell'istruzione preparata.
Flag deprecati Your installation contains deprecated flags for the new version . These flags must be removed before attempting an upgrade: (database: %s, Flag name: %s) Rimuovi il flag di database dalla configurazione dell'istanza.

Incompatibilità del database

La tabella seguente elenca gli errori comuni relativi alle incompatibilità dei formati dei dati che il controllo preliminare dell'upgrade della versione principale potrebbe rilevare:

Tipo Esempio di errore Risoluzione
Tipo di dati sconosciuto Please remove the following usages of 'Unknown' data types before attempting an upgrade: (database: my_db, relation: my_table, attribute: my_column) Rimuovi la colonna o la tabella oppure modifica il tipo di dati della tabella utilizzando ALTER TABLE my_table ALTER COLUMN my_column TYPE TEXT;.
Tipo di dati reg* Please remove the following usages of 'reg*' data types before attempting an upgrade: (database: my_db, relation: my_table, attribute: my_column) Rimuovi la colonna o modifica il tipo di dati.
Tipo di dati rimosso Please remove the following usages of 'sql_identifier' data types before attempting an upgrade: ... Converti in TEXT, timestamptz o in un altro tipo di dati adatto.
​​aclitem Formato interno Please remove the following usages of 'aclitem' data types before attempting an upgrade: ... Interrompi l'utilizzo di aclitem nelle definizioni delle tabelle del database.
Tipi di dati compositi definiti dal sistema Please remove the following usages of 'composite' data types before attempting an upgrade: (database: my_db, relation: my_table, attribute: my_column) Modifica le colonne identificate in modo da utilizzare un tipo composito definito dall'utente o un tipo di dati standard. I tipi compositi di sistema potrebbero non essere coerenti tra le versioni principali.
Tabelle con OIDS Please remove the following usages of tables with OIDs before attempting an upgrade: (database: my_db, relation: my_table) Aggiorna la tabella utilizzando ALTER TABLE my_table SET WITHOUT OIDS;.
Operatori postfix definiti dall'utente Please remove the following usages of 'postfix operators' before attempting an upgrade: (database: my_db, operation id: 12345, operation namespace: public, operation name: !!, type namespace: public, type name: mytype) Rimuovi gli operatori postfix personalizzati. Potresti dover riscrivere il codice per utilizzare operatori di prefisso o chiamate di funzione.
Funzioni polimorfiche incompatibili Please remove the following usages of 'incompatible polymorphic' functions before attempting an upgrade: (database: my_db, object kind: function, object name: public.my_poly_func) Rimuovi o modifica la funzione per rimuovere le funzioni polimorfiche incompatibili. Ciò potrebbe comportare la modifica delle firme o della logica delle funzioni per funzionare con Cloud SQL per PostgreSQL 14 e versioni successive.
Conversioni di codifica definite dall'utente Please remove the following usages of user-defined encoding conversions before attempting an upgrade: (database: my_db, namespace name: public, encoding conversions name: my_encoding_conv) Rimuovi la conversione della codifica definita dall'utente. Potresti doverla ricreare dopo l'upgrade con una firma che funzioni con la nuova versione.
Controlla se è presente un riferimento di colonna ambiguo Cloud SQL controlla automaticamente la presenza di viste definite dall'utente che si basano sulle viste del catalogo di sistema. La struttura delle colonne di queste viste del catalogo di sistema potrebbe cambiare tra le versioni principali.

Please remove the following usages of views that depend on functions returning data types of pg_stat_activity before attempting an upgrade: (database: my_db, schema name: public, view name: my_stat_activity_view) 		Trova le visualizzazioni elencate nel messaggio di errore e rimuovile utilizzando il comando DROP VIEW. Dopo l'upgrade, ricrea le visualizzazioni.
Tabelle non registrate con colonne generate o sequenze registrate Please drop the following usages of 'Unlogged Tables with Logged Sequence' before attempting an upgrade: (database: your_db, table name: problematic_table) Puoi convertire la tabella in LOGGED o rimuoverla utilizzando il comando DROP TABLE. Ricrea la tabella dopo l'upgrade.
Risolvi il problema del percorso di ricerca vuoto Please update the search path of the 'll_to_earth' function (database: your_db, search path: ) L'estensione earthdistance utilizza earth e cube types senza specificare il percorso di ricerca della funzione. Aggiorna il percorso di ricerca utilizzando ALTER FUNCTION ll_to_earth SET search_path = public;.

Ripristina l'istanza principale alla versione principale precedente

Se il sistema di database di cui è stato eseguito l'upgrade non funziona come previsto, potresti dover ripristinare l'istanza principale alla versione precedente. Per farlo, ripristina il backup pre-upgrade in un'istanza di recupero Cloud SQL, ovvero una nuova istanza che esegue la versione pre-upgrade.

Per ripristinare la versione precedente di un'istanza principale, segui questi passaggi:

  1. Identifica il backup precedente all'upgrade.

    Consulta Backup automatici degli upgrade.

  2. Crea un'istanza di recupero.

    Crea una nuova istanza Cloud SQL utilizzando la versione principale di Cloud SQL in esecuzione al momento della creazione del backup pre-upgrade. Imposta gli stessi flag e le stesse impostazioni dell'istanza utilizzati dall'istanza originale.

  3. Ripristina il backup precedente all'upgrade.

    Ripristina il backup precedente all'upgrade nell'istanza di recupero. L'operazione potrebbe richiedere diversi minuti.

  4. Aggiungi le repliche di lettura.

    Se utilizzi repliche di lettura, aggiungile singolarmente.

  5. Connetti la tua applicazione.

    Dopo aver recuperato il sistema di database, aggiorna l'applicazione con i dettagli dell'istanza di recupero e delle relative repliche di lettura. Puoi riprendere la gestione del traffico sulla versione del database precedente all'upgrade.

Domande frequenti

Durante l'upgrade della versione principale del database potrebbero sorgere le seguenti domande.

La mia istanza non è disponibile durante un upgrade?
Sì. L'istanza rimane non disponibile per un periodo di tempo durante il quale Cloud SQL esegue l'upgrade.
Quanto tempo richiede un upgrade?

In genere, l'upgrade di una singola istanza richiede meno di 10 minuti. Se la configurazione dell'istanza ha un numero ridotto di vCPU o di memoria, l'upgrade potrebbe richiedere più tempo.

Se l'istanza ospita troppi database o tabelle o se i database sono molto grandi, l'upgrade potrebbe richiedere ore o addirittura scadere, perché il tempo totale dell'upgrade corrisponde al numero di oggetti nei database. Se devi eseguire l'upgrade di più istanze, il tempo di upgrade aumenta proporzionalmente. Se includi le repliche nell'upgrade, l'operazione di upgrade può richiedere fino a un'ora, a seconda del numero di repliche dell'istanza principale.

Posso monitorare ogni passaggio del processo di upgrade?
Sebbene Cloud SQL ti consenta di monitorare se un'operazione di upgrade è ancora in corso, non puoi monitorare i singoli passaggi di ogni upgrade.
Posso annullare l'upgrade dopo averlo avviato?
Sì, ma solo in condizioni specifiche. Puoi annullare l'operazione durante la fase di upgrade principale. Per informazioni dettagliate su come identificare la finestra annullabile, consulta Annulla l'upgrade della versione principale. Inoltre, l'annullamento non è supportato se includi repliche di lettura con l'istanza principale. Per mantenere la possibilità di annullare, devi eseguire l'upgrade senza includere le repliche di lettura.
Cosa succede alle mie impostazioni durante un upgrade?

Quando esegui un upgrade della versione principale in loco, Cloud SQL conserva le impostazioni del database, inclusi il nome dell'istanza, l'indirizzo IP, i valori dei flag configurati esplicitamente e i dati utente. Tuttavia, il valore predefinito delle variabili di sistema potrebbe cambiare. Ad esempio, il valore predefinito del flag password_encryption in PostgreSQL 13 e versioni precedenti è md5. Quando esegui l'upgrade a PostgreSQL 14, il valore predefinito di questo flag cambia in scram-sha-256.

Per scoprire di più, consulta Configura i flag di database. Se un determinato flag o valore non è più supportato nella versione di destinazione, Cloud SQL lo rimuove automaticamente durante l'upgrade, a condizione che non sia stato impostato da te. Se hai configurato un flag non supportato nella versione di destinazione, devi rimuoverlo prima di eseguire l'upgrade.

Passaggi successivi