Upgrade de versão no Cloud SQL da Google Cloud sem migração de dados: como funciona para MySQL, PostgreSQL e SQL Server

Atualizar a versão principal de um banco de dados em produção costuma ser uma operação temida. No Cloud SQL, é possível fazer isso diretamente na instância existente, sem precisar criar um novo ambiente, mover dados ou alterar as strings de conexão da aplicação.

Por que atualizar a versão principal do banco?

Cada nova versão principal de MySQL, PostgreSQL e SQL Server traz melhorias de desempenho, correções de segurança e novas funcionalidades. Mais do que isso: versões antigas chegam ao fim de vida (EOL) e deixam de receber atualizações da comunidade.

No Cloud SQL, instâncias rodando versões em EOL são automaticamente inscritas no programa de suporte estendido, que permite continuar operando por até três anos, mas com cobrança adicional. Instancias em versões EOL podem entrar automaticamente no programa de Extended Support com cobrança adicional, conforme a política vigente do Cloud SQL. Doc. MySQL → Database versionsDoc. PostgreSQL → Database versions Migrar para uma versão com suporte ativo é a forma de evitar essa cobrança e garantir a segurança e a estabilidade da aplicação a longo prazo.

O que é o upgrade in-place?

O upgrade in-place é a forma mais simples de atualizar a versão principal do banco de dados no Cloud SQL. Em vez de criar uma nova instância, exportar os dados, importar em outro ambiente e redirecionar a aplicação, o upgrade in-place atualiza a instância existente diretamente.

Após o upgrade, a instância mantém o mesmo nome, o mesmo endereço IP e todas as configurações anteriores. Não é necessário alterar as strings de conexão da aplicação. Os arquivos de dados não são movidos, o que torna a operação mais rápida do que uma migração completa.

Como o Cloud SQL executa o upgrade

O mecanismo varia de acordo com o engine, mas o Cloud SQL cuida de toda a parte operacional. O DBA precisa apenas iniciar o processo e validar o resultado. Internamente, cada engine usa sua propria ferramenta nativa:

Backup automatico antes e depois do upgrade

O Cloud SQL cria automaticamente dois backups sob demanda durante qualquer upgrade de versao principal, chamados de upgrade backups Doc. MySQL → Upgrade backupsDoc. PostgreSQL → Upgrade backupsDoc. SQL Server → Upgrade backups:

Esses backups aparecem na lista de backups da instancia com o tipo On-demand e recebem labels identificaveis. Por exemplo, para um upgrade do MySQL 5.7 para o MySQL 8.0, o pre-upgrade backup aparece como Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0 e o pos-upgrade como Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.

Indisponibilidade durante o upgrade

O upgrade in-place exige que a instancia fique indisponivel por um periodo. A duracao varia de acordo com o engine e o tamanho da instancia:

A documentacao recomenda agendar o upgrade durante periodos de baixa atividade no banco de dados. Falhas em replicas não interrompem o upgrade da instancia primaria, mas podem afetar a estrategia de alta disponibilidade. Dependendo do setup, pode ser necessario recriar a replica apos o upgrade.

Estrategia recomendada: teste em clone antes de subir em producao

A documentacao do Cloud SQL recomenda fortemente realizar um dry run do upgrade em um clone da instancia de producao antes de executar o upgrade real. Essa pratica permite:

Para criar um clone no Cloud SQL, acesse a instancia no console, clique em Clonar e siga o processo de criacao. O clone e uma copia identica dos dados e configuracoes da instancia, criada sem impacto na producao.

Estrategia avancada: replicas em cascata para minimizar downtime (MySQL)

Para cenarios onde a indisponibilidade precisa ser minimizada ao maximo, o Google Cloud Blog documenta uma estrategia usando replicas em cascata. Trata-se de uma abordagem arquitetural avancada, nao um fluxo padrao do Cloud SQL, que exige atenção a delay de replicacao, inconsistencia temporaria entre versões e mudanca de endpoint da aplicacao:

Upgrade usando replicas em cascata: permite manter o stack antigo intacto como fallback enquanto o novo e validado. Fonte: Google Cloud Blog

Particularidades e cuidados por engine

PostgreSQL

O Cloud SQL para PostgreSQL oferece um recurso de precheck antes do upgrade. Trata-se de uma operacao de longa duracao que verifica se a instancia esta pronta para o upgrade sem causar indisponibilidade. Doc. PostgreSQL → Run precheck O resultado pode ser um dos seguintes:

Alem disso, ha limitacoes especificas para o PostgreSQL no upgrade in-place:

• Instancias com mais de 1.000 bancos de dados podem levar muito tempo e sofrer timeout
• Se o total de Large Objects (LOBs) em todos os bancos ultrapassar 10 milhoes, o upgrade falha e o Cloud SQL faz rollback automatico para a versao anterior Doc. PostgreSQL → Limitations
• Para PostgreSQL 16 e versoes posteriores, a extensao PostGIS deve ser atualizada para a versao 3.4.0 antes do upgrade da instancia
• Replicas externas nao participam automaticamente do processo de upgrade e precisam ser tratadas separadamente

MySQL

O upgrade de MySQL 5.7 para 8.0 exige recursos adicionais de memoria para converter os metadados antigos para o novo dicionario de dados. A documentacao recomenda garantir mais de 100 KB de memoria para cada tabela antes de iniciar. Doc. MySQL → Before you begin Se necessario, o tipo de maquina pode ser aumentado temporariamente antes do upgrade.

Apos o upgrade para MySQL 8.0, e recomendado revisar os privilegios de usuarios. O MySQL 8.0 alterou os sistemas de seguranca e gerenciamento de contas, e usuarios migrados do 5.7 podem nao ter os mesmos privilegios que usuarios criados diretamente no 8.0. Por exemplo, privilegios como CREATE ROLE e DROP ROLE nao existiam no MySQL 5.7 e podem precisar ser concedidos manualmente.

SQL Server

Para o SQL Server, alem do upgrade da versao, e necessario atualizar o nivel de compatibilidade dos bancos de dados manualmente apos o upgrade. Doc. SQL Server → Compatibility level Essa etapa nao causa reinicializacao nem indisponibilidade, mas e necessaria para que os bancos utilizem os recursos da nova versao. Por exemplo, o SQL Server 2017 usa o nivel de compatibilidade 140 e o SQL Server 2022 usa o nivel 160.

-- Verificar o nivel de compatibilidade atual do banco
USE DATABASE_NAME
GO
SELECT compatibility_level FROM sys.databases
WHERE name = 'DATABASE_NAME'

-- Atualizar o nivel de compatibilidade apos o upgrade
ALTER DATABASE DATABASE_NAME
SET COMPATIBILITY_LEVEL = 160 -- 160 para SQL Server 2022

Como executar o upgrade in-place

O upgrade pode ser feito pelo console do Google Cloud, pelo gcloud CLI ou pela API. O processo e identico para os tres engines:

Pelo console do Google Cloud

Passo 3: o botao Upgrade aparece na secao de informacoes da instancia, abaixo da versao do banco. Fonte: Google Cloud Blog

Passo 4: selecao da versao de destino disponivel para upgrade via dropdown. Fonte: Google Cloud Blog

Passo 5: confirmacao do upgrade digitando o nome da instancia para evitar operacoes acidentais. Fonte: Google Cloud Blog

Acompanhamento do progresso do upgrade em tempo real na pagina de visao geral da instancia. Fonte: Google Cloud Blog

Upgrade concluido: a instancia exibe a nova versao do banco de dados na pagina de visao geral. Fonte: Google Cloud Blog

Pelo gcloud CLI

# Verificar versoes disponiveis para upgrade
gcloud sql instances describe INSTANCE_NAME \
  --format="json(upgradableDatabaseVersions)"

# Executar o upgrade in-place
gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION

# Exemplo para PostgreSQL 15 para PostgreSQL 16
gcloud sql instances patch minha-instancia \
  --database-version=POSTGRES_16

# Exemplo para MySQL 8.0 para MySQL 8.4
gcloud sql instances patch minha-instancia \
  --database-version=MYSQL_8_4

# Incluir replicas no upgrade (apenas via gcloud ou API, nao disponivel no console)
gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --include-replicas-for-major-version-upgrade

O que fazer apos o upgrade