Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus utilizzando l'upgrade in situ

Questa pagina mostra come utilizzare il metodo di upgrade in loco per eseguire l'upgrade di un'istanza Cloud SQL Enterprise alla versione Cloud SQL Enterprise Plus. Inoltre, descrive anche la procedura per passare da un'istanza Cloud SQL Enterprise Plus a Cloud SQL Enterprise.

L'upgrade alla versione Cloud SQL Enterprise Plus offre diversi vantaggi e miglioramenti delle prestazioni. Per saperne di più, consulta la Introduzione alle versioni di Cloud SQL per MySQL.

Per attivare questi miglioramenti per le istanze Cloud SQL Enterprise esistenti, devi eseguire l'upgrade alla versione Cloud SQL Enterprise Plus. Il processo di upgrade richiede alcuni minuti e ha un tempo di inattività quasi nullo. Il passaggio alla versione Cloud SQL Enterprise può richiedere fino a 60 secondi di inattività.

Inoltre, questa procedura di upgrade non richiede di modificare gli endpoint a cui si connettono le tue applicazioni.

Prima di iniziare

• Assicurati di eseguire un'istanza Cloud SQL Enterprise 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 maggiori informazioni, vedi Eseguire l'upgrade in loco della versione principale del database e Eseguire l'upgrade della versione secondaria del database.

Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR

Tutte le istanze Cloud SQL Enterprise Plus sono abilitate automaticamente con il recupero point-in-time (PITR). Se l'istanza di Cloud SQL Enterprise che vuoi eseguire l'upgrade archivia i log binari utilizzati per il PITR su disco, la procedura di upgrade a Cloud SQL Enterprise Plus sposta la posizione di archiviazione dei log binari dal disco a Cloud Storage.

Prima di eseguire l'upgrade alla versione Cloud SQL Enterprise Plus, controlla se l'istanza Cloud SQL Enterprise subirà il cambio di posizione di archiviazione per i log binari utilizzati per il PITR. Per ulteriori informazioni e istruzioni su come controllare l'istanza, vedi Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il recupero point-in-time.

Per ulteriori informazioni sul cambio della posizione di archiviazione del log delle transazioni durante la procedura di upgrade, vedi Posizione di archiviazione dei log delle transazioni utilizzati per il PITR.

Esegui l'upgrade di un'istanza alla versione Cloud SQL Enterprise Plus

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

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

Posizione di archiviazione dei log delle transazioni utilizzati 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.

Al processo di cambio di località si applicano le seguenti condizioni:

• Il processo richiede all'incirca 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 dei 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 di 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:
  • l'impostazione di configurazione PITR transactionLogRetentionDays precedente al cambio, 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 log e dei backup di Cloud SQL Enterprise Plus

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

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

• 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 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 in modo che corrisponda a 1 giorno, così potrai ridurre le dimensioni del disco allocate e i costi di archiviazione su disco. Per ulteriori informazioni sull'archiviazione dei log delle transazioni e sul PITR, consulta 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 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 un upgrade della versione principale, non potrai eseguire il recupero point-in-time (PITR) a un momento precedente all'upgrade della versione principale. Questa limitazione si applica anche se il periodo di conservazione copre quel periodo di tempo. Puoi ripristinare l'istanza a un punto temporale dopo aver avviato l'upgrade della versione principale.

Passare alla versione Cloud SQL Enterprise

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

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

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE"
  }
}

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

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

Valori predefiniti di archiviazione di backup e log di Cloud SQL Enterprise

Il passaggio a Cloud SQL Enterprise Edition non cambia la posizione di archiviazione dei log delle transazioni utilizzati per il PITR. Se l'istanza Cloud SQL Enterprise Plus memorizza i log delle transazioni per il PITR in Cloud Storage, i log rimangono in Cloud Storage. Tuttavia, anziché archiviare 14 giorni di log delle transazioni per PITR per impostazione predefinita, il valore predefinito è stato modificato a 7 giorni. La configurazione del backup non viene modificata.

Genera automaticamente l'endpoint di scrittura

Un endpoint di scrittura è un nome DNS (Domain Name Service) globale che si risolve automaticamente nell'indirizzo IP dell'istanza Cloud SQL primaria corrente. Questo endpoint reindirizza automaticamente le connessioni in entrata alla nuova istanza principale in caso di operazione di failover della replica. Puoi utilizzare l'endpoint di scrittura in una stringa di connessione SQL anziché un indirizzo IP. Utilizzando un endpoint di scrittura, puoi evitare di dover apportare modifiche alla connessione dell'applicazione quando si verifica un'interruzione a livello di regione.

Se esegui l'upgrade dell'istanza con un indirizzo IP privato sulla nuova architettura di rete alla versione Cloud SQL Enterprise Plus e abiliti l'API DNS per il tuo progettoTrusted Cloud , Cloud SQL genera automaticamente l'endpoint di scrittura. Tuttavia, il certificato del server associato all'istanza non avrà aggiunto l'endpoint di scrittura (nome DNS globale). Pertanto, se vuoi verificare il nome DNS, devi ruotare il certificato. Al termine della rotazione di questo certificato, Cloud SQL aggiunge il nome DNS al certificato. Puoi utilizzare il nome DNS per la verifica dell'identità del server.

Passaggi successivi

• Scopri di più sulla versione Cloud SQL Enterprise Plus.