Upgrade in loco

Questa pagina descrive come eseguire upgrade e downgrade in loco delle istanze Cloud SQL.

Apportare modifiche in loco a un'istanza Cloud SQL

Puoi utilizzare le modifiche in loco per eseguire l'upgrade o il downgrade della versione, del tipo di macchina, del tipo di archiviazione o della versione del database dell'istanza Cloud SQL. Apportare modifiche in loco è il modo più semplice e meno soggetto a errori per riconfigurare un'istanza.

Prima di iniziare

Assicurati che l'istanza sia in esecuzione su MySQL versione 8.0.31 o successive.

Se l'istanza utilizza una versione precedente di MySQL, devi eseguire l'upgrade a MySQL 8.0.31 o versioni successive. Per ulteriori informazioni, consulta Eseguire l'upgrade in loco della versione principale del database e Eseguire l'upgrade della versione secondaria del database.

Le diverse versioni supportano tipi di macchine diversi che utilizzano opzioni di archiviazione diverse. I tipi di macchine C4 e C4A ad alte prestazioni utilizzano l'archiviazione Hyperdisk bilanciato anziché una delle opzioni di disco permanente utilizzate dai tipi di macchine precedenti.

Quando modifichi la versione o il tipo di macchina che stai utilizzando, anche il tipo di archiviazione potrebbe cambiare, il che potrebbe comportare un periodo di inattività e una modifica dei costi di archiviazione. Quando passi a Google Cloud Hyperdisk bilanciato, sono disponibili opzioni di configurazione aggiuntive che puoi specificare. Per ulteriori informazioni, consulta Modifiche allo spazio di archiviazione.

Tieni presente le modifiche allo spazio di archiviazione dei log delle transazioni PITR

Se esegui l'upgrade di un'istanza della versione Cloud SQL Enterprise che archivia i log binari utilizzati per PITR su disco, tieni presente che la procedura di upgrade alla versione Cloud SQL Enterprise Plus sposta la posizione di archiviazione di questi log dal disco a Cloud Storage. Per determinare la posizione corrente dei log binari PITR per l'istanza, consulta Controllare la posizione di archiviazione dei log delle transazioni utilizzati per PITR.

Per una spiegazione completa di come gli upgrade in loco possono influire sulla posizione dei log binari, consulta Modifiche alla posizione di archiviazione dei log binari per PITR.

Modificare la versione di un'istanza in loco

Questa sezione mostra come modificare la versione dell'istanza Cloud SQL in loco alla versione Cloud SQL Enterprise Plus o viceversa. La versione Cloud SQL Enterprise Plus offre alcuni vantaggi e miglioramenti delle prestazioni che la versione Cloud SQL Enterprise non offre. Per ulteriori informazioni sulle versioni di Cloud SQL, consulta la panoramica sulle versioni di Cloud SQL.

L'upgrade alla versione Cloud SQL Enterprise Plus richiede alcuni minuti per essere completato e comporta un periodo di inattività quasi nullo. Il passaggio alla versione Cloud SQL Enterprise comporta un periodo di inattività più lungo. Nessuna delle due procedure richiede la modifica degli endpoint a cui si connettono le applicazioni.

Utilizza la procedura descritta in questa sezione per eseguire l'upgrade di un'istanza della versione Cloud SQL Enterprise alla versione Cloud SQL Enterprise Plus o per eseguire il downgrade di un'istanza della versione Cloud SQL Enterprise Plus alla versione Cloud SQL Enterprise.

Console

  1. Nella Google Cloud console, 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 Scegli una versione di Cloud SQL , fai clic su Esegui l'upgrade se l'istanza utilizza la versione Cloud SQL Enterprise o su Passa a Enterprise se l'istanza utilizza la versione Cloud SQL Enterprise Plus.
  5. Utilizza il riquadro che si apre per specificare la configurazione dell'istanza utilizzando la nuova versione. Consulta [Opzioni per apportare modifiche in loco](#change-options).
  6. Inserisci l'ID istanza per confermare queste scelte, quindi fai clic su Esegui l'upgrade della versione o Cambia versione a seconda che tu stia eseguendo l'upgrade o il downgrade.

Puoi anche avviare una modifica della versione nella pagina Istanze se selezioni Modifica nella colonna Azioni dell'istanza.

Inoltre, se l'istanza utilizza la versione Cloud SQL Enterprise, puoi avviare un upgrade facendo clic sul link Esegui l'upgrade accanto al campo della versione nella sezione Configurazione della pagina dell'istanza.

gcloud

Il seguente esempio di codice [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) mostra come eseguire l'upgrade dell'istanza alla versione Cloud SQL Enterprise Plus:

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto dell'istanza di cui vuoi eseguire l'upgrade.
  • INSTANCE_ID: il nome dell'istanza di cui vuoi eseguire l'upgrade.
  • MACHINE_TYPE: il tipo di macchina dell'istanza di cui vuoi eseguire l'upgrade. Per ulteriori informazioni sui tipi di macchine per la versione Cloud SQL Enterprise Plus, consulta Tipi di macchine per le istanze della versione Cloud SQL Enterprise Plus.

REST

Il seguente comando esegue l'upgrade dell'istanza alla versione Cloud SQL Enterprise Plus e attiva un'operazione di riavvio.

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

  • PROJECT_ID: l'ID progetto dell'istanza di cui vuoi eseguire l'upgrade.
  • INSTANCE_ID: l'ID istanza dell'istanza di cui vuoi eseguire l'upgrade.
  • MACHINE_TYPE: il tipo di macchina dell'istanza di cui vuoi eseguire l'upgrade. Per ulteriori informazioni sui tipi di macchine per la versione Cloud SQL Enterprise Plus, consulta Tipi di macchine per le istanze della versione Cloud SQL Enterprise Plus.

Metodo HTTP e URL: 

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

Corpo JSON della richiesta: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Il seguente comando esegue l'upgrade dell'istanza alla versione Cloud SQL Enterprise Plus e attiva un'operazione di riavvio.

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

  • PROJECT_ID: l'ID progetto dell'istanza di cui vuoi eseguire l'upgrade.
  • INSTANCE_ID: l'ID istanza dell'istanza di cui vuoi eseguire l'upgrade.
  • MACHINE_TYPE: il tipo di macchina dell'istanza di cui vuoi eseguire l'upgrade. Per ulteriori informazioni sui tipi di macchine per la versione Cloud SQL Enterprise Plus, consulta Tipi di macchine per le istanze della versione Cloud SQL Enterprise Plus.

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

Corpo JSON della richiesta: 

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Opzioni per le modifiche in loco

La modifica della versione dell'istanza Cloud SQL può richiedere la modifica della serie di macchine, che a sua volta influisce sul tipo di archiviazione.

Modifiche alla macchina

Quando modifichi le versioni, devi modificare anche il tipo di macchina. Per ulteriori informazioni sulle serie di macchine supportate da Cloud SQL, consulta Scegliere una serie di macchine.

Quando esegui l'upgrade dalla versione Cloud SQL Enterprise alla versione Cloud SQL Enterprise Plus, puoi scegliere tra le serie di macchine N2, C4A e C4.

Quando esegui il downgrade dalla versione Cloud SQL Enterprise Plus alla versione Cloud SQL Enterprise, puoi scegliere tra una serie di macchine con core dedicati per uso generico, e una serie di macchine N4.

Puoi anche modificare il tipo di macchina senza modificare la versione. Dopo aver scelto di modificare l'istanza, vai alla sottosezione Macchina di Configurazione macchina nell'area Personalizza l'istanza. Utilizzando il menu a discesa, puoi selezionare un tipo di macchina diverso. Puoi anche scegliere un numero diverso di vCPU e abilitare o disabilitare la cache dei dati, se necessario.

Per informazioni più generali, consulta anche la documentazione di Compute Engine per le N2, C4A, C4 e N4.

Modifiche allo spazio di archiviazione

Se passi da una serie di macchine per uso generico o N2 a una serie di macchine N4, C4A o C4, lo spazio di archiviazione verrà migrato da unità a stato solido (SSD) a Google Cloud Hyperdisk bilanciato spazio di archiviazione. In genere, questo upgrade richiede un periodo di inattività minimo.

Lo spazio di archiviazione Google Cloud Hyperdisk bilanciato può essere personalizzato per il tuo caso d'uso impostando quanto segue:

  • Capacità dello spazio di archiviazione
  • IOPS sottoposte a provisioning
  • Throughput riservato

Google Cloud Hyperdisk bilanciato imposta i valori e i limiti predefiniti di IOPS e throughput in base alla configurazione dell'istanza, che include il tipo di macchina e la capacità di archiviazione. La capacità di archiviazione limita il valore predefinito, mentre il tipo di macchina imposta il valore massimo sia per le IOPS sia per il throughput. Per i dettagli, consulta Scegliere un'opzione di archiviazione.

Modifiche alla posizione dei log binari per PITR

Se l'istanza della versione Cloud SQL Enterprise archivia i log delle transazioni per PITR su disco, l'avvio della procedura di upgrade alla versione Cloud SQL Enterprise Plus sposta la posizione di archiviazione di questi log in Cloud Storage.

Le seguenti condizioni si applicano alla modifica della posizione:

  • La procedura richiede circa la durata del transactionLogRetentionDays impostazione di configurazione PITR per completare il passaggio a Cloud Storage.
  • Se hai impostato valori per il flag expire_logs_days o binlog_expire_logs_seconds sull'istanza, questi valori vengono mantenuti.
  • Durante il passaggio a Cloud Storage, non puoi modificare i valori dei flag expire_logs_days o binlog_expire_logs_seconds sull'istanza.
  • Durante il passaggio a Cloud Storage, ti consigliamo di non modificare l'impostazione di configurazione PITR transactionLogRetentionDays. Anche se aumenti transactionLogRetentionDays, i log binari non verranno conservati su disco per più di 7 giorni, che è il valore predefinito per un'istanza della versione Cloud SQL Enterprise.
  • Durante il passaggio, Cloud SQL conserva i log su disco solo per il valore minimo di uno dei seguenti:
    • L'impostazione di configurazione PITR transactionLogRetentionDays precedente al passaggio, che per impostazione predefinita è di 7 giorni.
    • I flag expire_logs_days o binlog_expire_logs_seconds impostati manualmente sull'istanza.
  • Dopo il passaggio, Cloud SQL conserva la stessa quantità di log binari su disco che avevi prima del passaggio, a meno che tu non abbia impostato i flag expire_logs_days o binlog_expire_logs_seconds sull'istanza. Se hai impostato questi flag, Cloud SQL conserva i log binari su disco in base al valore minimo dell'impostazione di configurazione transactionLogRetentionDays o al valore dei flag.

Valori predefiniti per l'archiviazione di backup e log della versione Cloud SQL Enterprise Plus

Al termine del passaggio a Cloud Storage per un'istanza, Cloud SQL conserva comunque copie dei log binari su disco per la replica. L'archiviazione dei log binari su disco può essere utile se vuoi sfogliarli con l'utilità mysqlbinlog.

Se hai configurato i flag expire_logs_days e binlog_expire_logs_seconds sull'istanza prima dell'upgrade, i valori configurati rimangono invariati.

Dopo il passaggio, poiché i log binari utilizzati per eseguire PITR vengono ora archiviati in Cloud Storage, assicurati che i valori dei flag riflettano la conservazione dei log delle transazioni su disco che ti aspetti. Cloud SQL conserva i log su disco solo per il valore minimo di uno dei seguenti:

  • l'impostazione di configurazione PITR transactionLogRetentionDays prima del passaggio, che per impostazione predefinita è di 7 giorni
  • i flag expire_logs_days o binlog_expire_logs_seconds impostati manualmente sull'istanza

Se vuoi risparmiare spazio su disco, al termine dell'upgrade configura il valore del flag expire_logs_days o binlog_expire_logs_seconds sull'equivalente di 1 giorno in modo da poter ridurre le dimensioni del disco allocate e i costi di archiviazione su disco. Per ulteriori informazioni sull'archiviazione dei log delle transazioni e su PITR, consulta Archiviazione dei log per PITR.

Al termine dell'upgrade alla versione Cloud SQL Enterprise Plus, il periodo di conservazione predefinito dei log delle transazioni per tutte le istanze di cui è stato eseguito l'upgrade viene aumentato a 14 giorni. Per questo aumento e per qualsiasi altro aumento configurato per il periodo di conservazione dei log delle transazioni, è necessario un periodo di tempo pari al nuovo valore aumentato per raggiungere la finestra di conservazione completa di PITR. Ad esempio, se il vecchio valore per i giorni di conservazione dei log delle transazioni è 7 e il nuovo valore viene aumentato a 14, la finestra per PITR per i primi 7 giorni dopo l'upgrade è di soli 7 giorni. L'ottavo giorno, la finestra per PITR diventa di 8 giorni, il nono giorno diventa di 9 giorni e così via, fino a quando la finestra di conservazione non viene aumentata a 14 giorni il quattordicesimo giorno.

Inoltre, il numero predefinito di backup automatici viene aumentato da 8 a 15.

Se esegui l'upgrade alla versione Cloud SQL Enterprise Plus dopo aver eseguito l'upgrade della versione principale, non potrai eseguire PITR a un momento precedente all'upgrade della versione principale. Questa limitazione si applica anche se il periodo di conservazione copre questo periodo di tempo. Puoi ripristinare l'istanza a un momento successivo all'avvio dell'upgrade della versione principale.