Upgrade in loco

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

Apporta modifiche in loco a un'istanza Cloud SQL

Puoi utilizzare le modifiche in loco per eseguire l'upgrade o il downgrade dell'edizione, del tipo di macchina o del tipo di archiviazione dell'istanza Cloud SQL oppure per eseguire l'upgrade della versione del database. L'esecuzione di 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 la tua istanza utilizza una versione precedente di MySQL, devi eseguire l'upgrade a MySQL 8.0.31 o versioni successive. Per ulteriori informazioni, vedi Eseguire l'upgrade della versione principale del database sul posto e Eseguire l'upgrade della versione secondaria del database.

Tieni presente le potenziali modifiche allo spazio di archiviazione correlate al tipo di macchina

Le diverse edizioni 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 persistent disk utilizzate dai tipi di macchine meno recenti.

Quando apporti una modifica alla versione o al tipo di macchina che utilizzi, anche il tipo di spazio di archiviazione potrebbe cambiare, il che potrebbe comportare tempi di inattività e una variazione dei costi di archiviazione. Quando passi a Google Cloud Hyperdisk Balanced, puoi specificare opzioni di configurazione aggiuntive. Per saperne di più, vedi Modifiche allo spazio di archiviazione.

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

Se esegui l'upgrade di un'istanza Cloud SQL Enterprise che archivia i log binari utilizzati per il recupero point-in-time sul 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 attuale dei log binari PITR per la tua 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 il recupero point-in-time.

Modificare la versione di un'istanza sul posto

Questa sezione mostra come modificare la versione della tua istanza Cloud SQL in loco alla versione Cloud SQL Enterprise Plus o viceversa. La versione Enterprise Plus di Cloud SQL offre alcuni vantaggi e miglioramenti delle prestazioni che la versione Enterprise di Cloud SQL non offre. Per saperne di più sulle versioni di Cloud SQL, consulta la panoramica delle versioni di Cloud SQL.

L'upgrade alla versione Cloud SQL Enterprise Plus richiede alcuni minuti e ha tempi di inattività quasi azzerati. Il passaggio alla versione Cloud SQL Enterprise comporterà un tempo di inattività più lungo. Nessuno dei due processi richiede la modifica degli endpoint a cui si connettono le tue applicazioni.

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

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

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

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

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

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

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

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

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "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 dell'edizione 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 cambi edizione, devi modificare anche il tipo di macchina. Consulta Scegliere una serie di macchine per saperne di più sulle serie di macchine supportate da Cloud SQL.

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 N4 e una serie di macchine con core dedicato per uso generico.

Puoi anche modificare il tipo di macchina senza cambiare edizione. 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 attivare o disattivare la cache dei dati, se necessario.

Per informazioni più generali, consulta anche la documentazione di Compute Engine per le serie di macchine 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 Balanced. Questo upgrade in genere richiede un tempo di inattività minimo.

L'archiviazione Google Cloud Hyperdisk Balanced può essere personalizzata 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 predefiniti di IOPS e velocità effettiva e i limiti 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 che per il throughput. Per maggiori dettagli, consulta Scegliere un'opzione di archiviazione.

Modifiche alla posizione dei log binari per il PITR

Se la tua istanza Cloud SQL Enterprise Edition archivia i log delle transazioni per il PITR su disco, l'avvio della procedura di upgrade a Cloud SQL Enterprise Plus Edition cambia la posizione di archiviazione di questi log in Cloud Storage.

Si applicano le seguenti condizioni alla modifica della località:

• La procedura richiede circa la durata dell'impostazione di configurazione transactionLogRetentionDays PITR per completare il passaggio a Cloud Storage.
• Se hai impostato valori per il flag expire_logs_days o binlog_expire_logs_seconds nella tua istanza, questi valori vengono conservati.
• Durante il passaggio a Cloud Storage, non puoi modificare i valori per i flag expire_logs_days o binlog_expire_logs_seconds nella tua 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, il valore predefinito per un'istanza Cloud SQL Enterprise.

• Mentre il passaggio è in corso, Cloud SQL conserva i log su disco solo per il valore minimo di uno dei seguenti elementi:
  • L'impostazione di configurazione PITR transactionLogRetentionDays precedente al cambio, ovvero 7 giorni per impostazione predefinita.
  • I flag expire_logs_days o binlog_expire_logs_seconds impostati manualmente sull'istanza.
• Dopo il cambio, Cloud SQL conserva la stessa quantità di log binari su disco che avevi prima del cambio a meno che tu non abbia impostato i flag expire_logs_days o binlog_expire_logs_seconds sulla tua 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 di archiviazione dei backup e dei log di Cloud SQL Enterprise Plus

Una volta completato il passaggio a Cloud Storage per un'istanza, Cloud SQL conserva comunque copie dei log binari su disco a scopo di 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 sulla tua istanza prima dell'upgrade, i valori configurati rimangono invariati.

Dopo il passaggio, poiché i log binari utilizzati per eseguire PITR ora sono 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 per il valore minimo di uno dei seguenti elementi:

• l'impostazione di configurazione PITR transactionLogRetentionDays prima del cambio, 7 giorni per impostazione predefinita
• i flag expire_logs_days o binlog_expire_logs_seconds impostati manualmente nell'istanza

Se vuoi risparmiare spazio su disco, al termine dell'upgrade, configura il valore del flag expire_logs_days o binlog_expire_logs_seconds in modo che corrisponda a 1 giorno, in modo da ridurre le dimensioni del disco allocate e i costi di archiviazione su disco. Per saperne di più sull'archiviazione dei log delle transazioni e sul PITR, vedi Archiviazione dei log per il PITR.

Al termine dell'upgrade alla versione Cloud SQL Enterprise Plus, il periodo di conservazione predefinito del log delle transazioni per tutte le istanze sottoposte ad upgrade viene aumentato a 14 giorni. Per questo aumento e per qualsiasi altro aumento che configuri 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 del 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 il PITR per i primi 7 giorni dopo l'upgrade è di soli 7 giorni. L'ottavo giorno, la finestra per il PITR diventa di 8 giorni, il nono giorno diventa di 9 giorni, fino a quando la finestra di conservazione non viene aumentata a 14 giorni il 14° giorno.

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

Se esegui l'upgrade alla versione Cloud SQL Enterprise Plus dopo aver eseguito un upgrade della versione principale, non potrai eseguire il 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 specifico dopo aver avviato l'upgrade della versione principale.