Upgrade no local

Nesta página, descrevemos como fazer upgrades e downgrades no local das instâncias do Cloud SQL.

Fazer mudanças no local em uma instância do Cloud SQL

É possível usar mudanças no local para fazer upgrade ou downgrade da edição da instância do Cloud SQL, do tipo de máquina, do tipo de armazenamento ou da versão do banco de dados. Fazer mudanças no local é a maneira mais fácil e menos propensa a erros de reconfigurar uma instância.

Antes de começar

Verifique se a instância está executando o MySQL versão 8.0.31 ou mais recente.

Se a instância estiver em uma versão anterior do MySQL, faça upgrade para o MySQL 8.0.31 ou mais recente. Para mais informações, consulte Fazer upgrade da versão principal do banco de dados no local e Fazer upgrade da versão secundária do banco de dados.

Edições diferentes oferecem suporte a tipos de máquinas diferentes que usam opções de armazenamento diferentes. Os tipos de máquina C4 e C4A de alta performance usam Hyperdisk Balanced armazenamento em vez de uma das opções de disco permanente usadas por tipos de máquinas mais antigos.

Quando você faz uma mudança na edição ou no tipo de máquina que está usando, o tipo de armazenamento também pode mudar, o que pode resultar em algum tempo de inatividade e uma mudança nos custos de armazenamento. Ao migrar para o Google Cloud Hyperdisk Balanced, há outras opções de configuração que podem ser especificadas. Para mais informações, consulte Mudanças de armazenamento.

Esteja ciente das mudanças no armazenamento de registros de transações da PITR

Se você estiver fazendo upgrade de uma instância do Cloud SQL edição Enterprise que armazena os registros binários usados para a PITR no disco, saiba que o processo de upgrade para o Cloud SQL edição Enterprise Plus move o local de armazenamento desses registros do disco para o Cloud Storage. Para determinar o local atual dos registros binários da PITR da instância, consulte Verificar o local de armazenamento dos registros de transações usados para a PITR.

Para uma explicação completa de como os upgrades no local podem afetar o local dos registros binários, consulte Mudanças no local de armazenamento de registros binários para PITR.

Mudar a edição de uma instância no local

Esta seção mostra como mudar a edição da instância do Cloud SQL no local para ou do Cloud SQL edição Enterprise Plus. O Cloud SQL edição Enterprise Plus oferece alguns benefícios e melhorias de performance que o Cloud SQL edição Enterprise não oferece. Para mais informações sobre as edições do Cloud SQL, consulte Visão geral das edições do Cloud SQL.

O upgrade para o Cloud SQL edição Enterprise Plus leva alguns minutos para ser concluído e tem um tempo de inatividade quase zero. A mudança de volta para o Cloud SQL edição Enterprise resulta em um tempo de inatividade maior. Nenhum dos processos exige a mudança dos endpoints aos quais os aplicativos se conectam.

Use o procedimento nesta seção para fazer upgrade de uma instância do Cloud SQL edição Enterprise para o Cloud SQL edição Enterprise Plus ou para fazer downgrade de uma instância do Cloud SQL edição Enterprise Plus para o Cloud SQL edição Enterprise.

Console

  1. No Google Cloud console, acesse a página Instâncias do Cloud SQL.

    Acesse "Instâncias do Cloud SQL"

  2. Para abrir a página Visão geral de uma instância, clique no nome dela.
  3. Clique em Editar.
  4. Na seção Escolher uma edição do Cloud SQL , clique em Fazer upgrade se a instância estiver usando o Cloud SQL edição Enterprise ou em Mudar para Enterprise se a instância estiver usando o Cloud SQL edição Enterprise Plus.
  5. Use o painel que é aberto para especificar a configuração da instância usando a nova edição. Consulte [Opções ao fazer mudanças no local](#change-options).
  6. Insira o ID da instância para confirmar essas opções e clique em Fazer upgrade da edição ou Mudar edição , dependendo se você está fazendo upgrade ou downgrade.

Também é possível iniciar uma mudança de edição na página Instâncias se você selecionar Editar na coluna Ações da instância.

Além disso, se a instância estiver no Cloud SQL edição Enterprise, você poderá iniciar um upgrade clicando no link Upgrade ao lado do campo de edição na seção Configuration da página da instância.

gcloud

O exemplo de código [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) a seguir mostra como fazer upgrade da sua instância para o Cloud SQL edição Enterprise Plus:

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

Substitua:

  • PROJECT_ID: o ID do projeto da instância que você quer fazer upgrade.
  • INSTANCE_ID: o nome da instância que você quer fazer upgrade.
  • MACHINE_TYPE: o tipo de máquina da instância para a qual você quer fazer upgrade. Para mais informações sobre os tipos de máquinas do Cloud SQL edição Enterprise Plus, consulte Tipos de máquinas para instâncias da edição Cloud SQL Enterprise Plus.

REST

O comando a seguir faz upgrade da instância para o Cloud SQL edição Enterprise Plus e aciona uma operação de reinicialização.

Antes de usar os dados da solicitação abaixo, faça estas substituições:

  • PROJECT_ID: o ID do projeto da instância que você quer fazer upgrade.
  • INSTANCE_ID: o ID da instância que você quer fazer upgrade.
  • MACHINE_TYPE: o tipo de máquina da instância para a qual você quer fazer upgrade. Para mais informações sobre os tipos de máquinas do Cloud SQL Enterprise Plus, consulte Tipos de máquinas para instâncias da edição Cloud SQL Enterprise Plus.

Método HTTP e URL: 

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

Corpo JSON da solicitação: 

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

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

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

O comando a seguir faz upgrade da instância para o Cloud SQL edição Enterprise Plus e aciona uma operação de reinicialização.

Antes de usar os dados da solicitação abaixo, faça estas substituições:

  • PROJECT_ID: o ID do projeto da instância que você quer fazer upgrade.
  • INSTANCE_ID: o ID da instância que você quer fazer upgrade.
  • MACHINE_TYPE: o tipo de máquina da instância para a qual você quer fazer upgrade. Para mais informações sobre os tipos de máquinas do Cloud SQL Enterprise Plus, consulte Tipos de máquinas para instâncias da edição Cloud SQL Enterprise Plus.

Método HTTP e URL: 

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

Corpo JSON da solicitação: 

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

Para enviar a solicitação, expanda uma destas opções:

Você receberá uma resposta JSON semelhante a esta:

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

Opções para mudanças no local

A mudança da edição da instância do Cloud SQL pode exigir a mudança da série de máquinas, o que, por sua vez, afeta o tipo de armazenamento.

Mudanças de máquina

Ao mudar de edição, também é necessário mudar o tipo de máquina. Consulte Escolher uma série de máquinas para mais informações sobre as séries de máquinas com suporte do Cloud SQL.

Ao fazer upgrade do Cloud SQL edição Enterprise para o Cloud SQL edição Enterprise Plus, é possível escolher entre as N2, C4A e C4.

Ao fazer downgrade do Cloud SQL edição Enterprise Plus para o Cloud SQL edição Enterprise, é possível escolher entre um núcleo dedicado de uso geral, e uma série de máquinas N4.

Também é possível mudar o tipo de máquina sem mudar a edição. Depois de escolher editar a instância, acesse a subseção Máquina de Configuração da máquina na área Personalizar sua instância. Usando o menu suspenso, é possível selecionar um tipo de máquina diferente. Também é possível escolher um número diferente de vCPUs e ativar ou desativar o cache de dados, se apropriado.

Para mais informações gerais, consulte também a documentação do Compute Engine para as séries de máquinas N2, C4A, C4 e N4.

Mudanças de armazenamento

Se você estiver mudando de uma série de máquinas de uso geral ou N2 para uma série de máquinas N4, C4A ou C4, o armazenamento será migrado de unidade de estado sólido (SSD) para Google Cloud Hyperdisk balanceado armazenamento. Esse upgrade geralmente exige um tempo de inatividade mínimo.

O armazenamento balanceado do Google Cloud Hyperdisk pode ser personalizado para seu caso de uso definindo o seguinte:

  • Capacidade de armazenamento
  • IOPS provisionadas
  • Capacidade de processamento provisionada

O Google Cloud Hyperdisk Balanced define valores padrão de IOPS e capacidade de processamento e limites com base na configuração da instância, que inclui o tipo de máquina e a capacidade de armazenamento. A capacidade de armazenamento limita o valor padrão, e o tipo de máquina define o valor máximo para IOPS e capacidade de processamento. Consulte Escolher uma opção de armazenamento para mais detalhes.

Mudanças de local de registros binários para PITR

Se a instância do Cloud SQL edição Enterprise armazenar registros de transação para PITR no disco, iniciar o processo de upgrade para o Cloud SQL edição Enterprise Plus mudará o local de armazenamento desses registros para o Cloud Storage.

As seguintes condições se aplicam à mudança de local:

  • O processo leva aproximadamente a duração da transactionLogRetentionDays configuração da PITR para concluir a mudança para o Cloud Storage.
  • Se você tiver valores definidos para a flag expire_logs_days ou binlog_expire_logs_seconds na instância, eles serão preservados.
  • Durante a mudança para o Cloud Storage, não é possível modificar os valores das flags expire_logs_days ou binlog_expire_logs_seconds na instância.
  • Durante a mudança para o Cloud Storage, recomendamos que você não modifique a configuração da PITR transactionLogRetentionDays. Mesmo que você aumente transactionLogRetentionDays, os registros binários não serão mantidos no disco por mais do que o padrão de sete dias para uma instância do Cloud SQL edição Enterprise.
  • Enquanto a mudança estiver em andamento, o Cloud SQL só manterá registros no disco pelo valor mínimo de um dos seguintes itens:
    • A configuração da PITR transactionLogRetentionDays de antes da mudança, que é de sete dias por padrão.
    • As flags expire_logs_days ou binlog_expire_logs_seconds definidas manualmente na instância.
  • Após a mudança, o Cloud SQL manterá a mesma quantidade de registros binários no disco que você tinha antes da mudança a menos que você tenha definido as flags expire_logs_days ou binlog_expire_logs_seconds na instância. Se você tiver definido essas flags, o Cloud SQL manterá registros binários no disco com base no valor mínimo da configuração transactionLogRetentionDays ou no valor das flags.

Padrões de armazenamento de backups e registros do Cloud SQL edição Enterprise Plus

Depois que a mudança para o Cloud Storage for concluída em uma instância, o Cloud SQL ainda manterá cópias de registros binários no disco para fins de replicação. Armazenar registros binários no disco pode ser útil quando você quer navegar por registros binários com o utilitário mysqlbinlog.

Se você configurou as flags expire_logs_days e binlog_expire_logs_seconds na instância antes do upgrade, os valores configurados permanecerão intactos.

Como os registros binários usados para executar a PITR estão armazenados no Cloud Storage depois da mudança, verifique se os valores das flags refletem a retenção dos registros de transações no disco esperado. O Cloud SQL só mantém registros no disco pelo valor mínimo de um dos seguintes itens:

  • a definição da configuração PITR de transactionLogRetentionDays antes da mudança, sete dias por padrão
  • As flags expire_logs_days ou binlog_expire_logs_seconds definidas manualmente na instância

Se você quiser economizar espaço em disco, depois que o upgrade for concluído, configure o valor da flag expire_logs_days ou binlog_expire_logs_seconds para o equivalente de um dia para reduzir o tamanho do disco alocado e os custos de armazenamento em disco. Para mais informações sobre o armazenamento de registros de transações e a PITR, consulte Armazenamento de registros para PITR.

Após a conclusão do upgrade para o Cloud SQL Enterprise Plus, o período de armazenamento padrão do registro de transações de todas as instâncias atualizadas será aumentado para 14 dias. Para esse e qualquer outro aumento que você configurar para o período de armazenamento do registro de transações, é necessário um valor novo e maior para alcançar a janela de armazenamento completa da PITR. Por exemplo, se o valor antigo dos dias de armazenamento do registro de transações for 7 e o novo valor aumentar para 14, a janela da PITR nos primeiros sete dias após o upgrade será de apenas sete dias. No oitavo dia, a janela da PITR vira oito dias. No nono dia, ela vira nove dias, até que a janela de armazenamento seja finalmente aumentada para 14 dias no 14º dia.

Além disso, o número padrão de backups automatizados aumenta de 8 para 15.

Se você fizer upgrade para o Cloud SQL edição Enterprise Plus após um upgrade da versão principal, não será possível executar a PITR para um momento anterior ao upgrade da versão principal. Essa limitação é aplicável mesmo que o período de armazenamento inclua esse período. É possível restaurar a instância para um momento após o início do upgrade da versão principal.