Nesta página, descrevemos como fazer upgrade da versão principal do banco de dados fazendo upgrade da instância do Cloud SQL no local, em vez de migrar os dados.
Introdução
Os provedores de software de banco de dados lançam periodicamente novas versões principais que contêm novos recursos, melhorias de desempenho e melhorias de segurança. O Cloud SQL recebe novas versões após o lançamento delas. Depois que o Cloud SQL passar a oferecer suporte para uma nova versão principal, será possível fazer upgrade das instâncias para manter o banco de dados atualizado.
Para fazer upgrade da versão do banco de dados de uma instância no local, basta migrar os dados. Os upgrades no local são uma maneira mais simples de fazer upgrade da versão principal da instância. Não é necessário migrar os dados ou mudar as strings de conexão do aplicativo. Com os upgrades no local, é possível manter o nome, o endereço IP e outras configurações da instância atual após o upgrade. Os upgrades no local não exigem a movimentação de arquivos de dados e podem ser concluídos mais rapidamente. Em alguns casos, o tempo de inatividade é menor do que o exigido pela migração de dados.
A operação de upgrade no local do Cloud SQL para SQL Server usa o utilitário de upgrade no local do SQL Server.Planejar um upgrade da versão principal
Escolha uma versão principal de destino.
Considere os recursos oferecidos em cada versão principal do banco de dados e as incompatibilidades de endereço.
Consulte os recursos desativados e as alterações interruptivas do SQL Server.
As novas versões principais apresentam alterações incompatíveis que podem exigir que você modifique o código do aplicativo, o esquema ou as configurações do banco de dados. Antes de fazer upgrade da instância do banco de dados, analise as notas da versão principal de destino para determinar as incompatibilidades que você precisa resolver.
Teste o upgrade com uma simulação.
Faça uma simulação do processo de upgrade de ponta a ponta em um ambiente de teste antes de fazer upgrade do banco de dados de produção. Você pode clonar sua instância para criar uma cópia idêntica dos dados em que o processo de upgrade será testado.
Além de validar se o upgrade foi concluído com sucesso, execute testes para garantir que o aplicativo se comporta conforme o esperado no banco de dados atualizado.
Escolha um horário para o upgrade.
O upgrade exige que a instância fique indisponível por um período. Planeje o upgrade durante um período em que a atividade do banco de dados estiver baixa.
Atualize a versão principal do banco de dados no local
Quando você inicia uma operação de upgrade, o Cloud SQL verifica primeiro a configuração da sua instância para garantir que ela seja compatível com um upgrade. Depois de verificar a configuração, o Cloud SQL disponibiliza a instância, faz um backup pré-upgrade, executa o upgrade, disponibiliza a instância e depois faz um backup pós-upgrade.
Console
-
No console do Google Cloud, acesse a página Instâncias do Cloud SQL.
- Para abrir a página Visão geral de uma instância, clique no nome dela.
- Clique em Editar.
- Na seção Informações da instância, clique no botão Fazer upgrade e confirme que você quer acessar a página de upgrade.
- Na página Escolha uma versão de banco de dados, clique no campo Versão do banco de dados para upgrade e selecione uma das versões principais disponíveis do banco de dados.
- Clique em Continuar.
- Na caixa ID da instância, insira o nome da instância e clique no botão Iniciar upgrade.
Verifique se a versão principal atualizada do banco de dados aparece abaixo do nome da instância na página Visão geral da instância.
gcloud
Iniciar o upgrade.
Use o comando
gcloud sql instances patch
com a sinalização--database-version
.Antes de executar o comando, substitua o seguinte:
- INSTANCE_NAME: o nome da instância
- DATABASE_VERSION: a enumeração da versão principal do banco de dados, que precisa ser superior à versão atual. Veja as enums de versão do banco de dados disponíveis.
gcloud sql instances patch INSTANCE_NAME \ --database-version=DATABASE_VERSION
Os upgrades das versões principais levam vários minutos para serem concluídos. Talvez você veja uma mensagem indicando que a operação está demorando mais que o esperado. Você pode ignorar essa mensagem ou executar o comando
gcloud sql operations wait
para dispensá-la.Recebe o nome da operação de upgrade.
Use o comando
gcloud sql operations list
com a sinalização--instance
.Antes de executar o comando, substitua a variável INSTANCE_NAME pelo nome da instância.
gcloud sql operations list --instance=INSTANCE_NAME
Monitore o status do upgrade.
Use o comando
gcloud sql operations describe
:Antes de executar o comando, substitua a variável OPERATION pelo nome da operação de upgrade recuperada na etapa anterior.
gcloud sql operations describe OPERATION
REST v1
Inicie o upgrade no local.
Use uma solicitação PATCH com o método
instances:patch
.Antes de usar qualquer um dos dados da solicitação, substitua estas variáveis:
- project_id: o ID do projeto
- instance_name: o nome da instância
Método HTTP e URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance_name
Corpo JSON da solicitação:
{ "databaseVersion": enum DATABASE_VERSION }
Substitua DATABASE_VERSION pela enumeração para a versão principal do banco de dados, que precisa ser superior à versão atual. Veja as enums de versão do banco de dados disponíveis.
Envie sua solicitação usando curl ou PowerShell. Consulte Editar instâncias.
Recebe o nome da operação de upgrade.
Use uma solicitação GET com o método
operations.list
após substituir project_id pelo ID do projeto.Método HTTP e URL:
GET https://sqladmin.googleapis.com/v1/projects/project-id/operations
Monitore o status do upgrade.
Use uma solicitação GET com o método
operations.get
após substituir as seguintes variáveis:- project_id: o ID do projeto
- operation_name: o nome da operação de upgrade recuperada na etapa anterior.
Método HTTP e URL:
GET https://sqladmin.googleapis.com/v1/projects/project-id/operation/operation_name
Terraform
Para atualizar a versão do banco de dados, use um recurso do Terraform e o provedor do Terraform para o Google Cloud, versão 4.34.0 ou posterior.
Aplique as alterações
Para aplicar a configuração do Terraform em um projeto do Google Cloud, conclua as etapas nas seções a seguir.
Preparar o Cloud Shell
- Inicie o Cloud Shell.
-
Defina o projeto padrão do Google Cloud em que você quer aplicar as configurações do Terraform.
Você só precisa executar esse comando uma vez por projeto, e ele pode ser executado em qualquer diretório.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
As variáveis de ambiente serão substituídas se você definir valores explícitos no arquivo de configuração do Terraform.
Preparar o diretório
Cada arquivo de configuração do Terraform precisa ter o próprio diretório, também chamado de módulo raiz.
-
No Cloud Shell, crie um diretório e um novo
arquivo dentro dele. O nome do arquivo precisa ter a extensão
.tf
, por exemplo,main.tf
. Neste tutorial, o arquivo é chamado demain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Se você estiver seguindo um tutorial, poderá copiar o exemplo de código em cada seção ou etapa.
Copie o exemplo de código no
main.tf
recém-criado.Se preferir, copie o código do GitHub. Isso é recomendado quando o snippet do Terraform faz parte de uma solução de ponta a ponta.
- Revise e modifique os parâmetros de amostra para aplicar ao seu ambiente.
- Salve as alterações.
-
Inicialize o Terraform. Você só precisa fazer isso uma vez por diretório.
terraform init
Opcionalmente, para usar a versão mais recente do provedor do Google, inclua a opção
-upgrade
:terraform init -upgrade
Aplique as alterações
-
Revise a configuração e verifique se os recursos que o Terraform vai criar ou
atualizar correspondem às suas expectativas:
terraform plan
Faça as correções necessárias na configuração.
-
Para aplicar a configuração do Terraform, execute o comando a seguir e digite
yes
no prompt:terraform apply
Aguarde até que o Terraform exiba a mensagem "Apply complete!".
- Abra seu projeto do Google Cloud para ver os resultados. No console do Google Cloud, navegue até seus recursos na IU para verificar se foram criados ou atualizados pelo Terraform.
Excluir as alterações
Para excluir as mudanças, faça o seguinte:
- Para desativar a proteção contra exclusão, no arquivo de configuração do Terraform, defina o argumento
deletion_protection
comofalse
.deletion_protection = "false"
- Para aplicar a configuração atualizada do Terraform, execute o comando a seguir e digite
yes
no prompt:terraform apply
-
Remova os recursos aplicados anteriormente com a configuração do Terraform executando o seguinte comando e inserindo
yes
no prompt:terraform destroy
Quando você faz uma solicitação de upgrade no local, o Cloud SQL realiza uma verificação de pré-upgrade. Se o Cloud SQL determinar que a instância não está pronta para upgrade, a solicitação de upgrade falhará com uma mensagem sugerindo como resolver o problema. Consulte também Resolver problemas com um upgrade de versão principal.
Backups automáticos de upgrade
Quando você realiza um upgrade de versão principal, o Cloud SQL faz automaticamente dois backups sob demanda, chamados de backups de upgrade:
- O primeiro é o backup pré-upgrade, que é feito imediatamente antes do início do upgrade. É possível usar esse backup para restaurar a instância do banco de dados para o estado na versão anterior.
- O segundo backup de upgrade é o backup de pós-upgrade, que é feito imediatamente após as novas gravações serem permitidas para a instância de banco de dados atualizada.
Quando você visualiza a lista de
backups, os
backups de upgrade são listados com o tipo On-demand
. Os backups de upgrade são marcados para que
você possa identificá-los facilmente.
Por exemplo, se você estiver fazendo upgrade do SQL Server Enterprise 2017 para o SQL Server Enterprise 2019, seu backup pré-upgrade será rotulado como Pre-upgrade backup, SQLSERVER_2017_ENTERPRISE to SQLSERVER_2019_ENTERPRISE.
e o backup após o upgrade é rotulado como
Post-upgrade backup, SQLSERVER_2019_ENTERPRISE from SQLSERVER_2017_ENTERPRISE.
Assim como acontece com outros backups sob demanda, os backups de upgrade permanecem até que você os exclua ou exclua a instância.
Fazer upgrade do nível de compatibilidade do banco de dados
O nível de compatibilidade do banco de dados determina como ele se comporta em relação ao aplicativo veiculado. O nível de compatibilidade do banco de dados garante compatibilidade com versões anteriores do SQL Server e está relacionado às alterações do Transact-SQL e do otimizador de consultas. Quando a versão de um banco de dados da instância do SQL Server é atualizada, os níveis de compatibilidade dos bancos de dados atuais são preservados, para que o aplicativo possa continuar operando na versão mais recente do SQL Server. O upgrade do nível de compatibilidade ajuda você a aproveitar os novos recursos, as melhorias no processamento de consultas e outras alterações.
Depois de fazer upgrade da versão do mecanismo de banco de dados de uma instância, quando o aplicativo veiculado pelo banco de dados estiver pronto, faça upgrade do nível de compatibilidade de cada banco de dados na instância. Quando o nível de compatibilidade é definido como o mais recente, os bancos de dados são atualizados com os recursos mais recentes e melhor desempenho.
Para fazer upgrade do nível de compatibilidade do banco de dados, siga estas etapas:
Identifique o nível de compatibilidade atual do banco de dados.
Por exemplo, para o SQL Server 2017, o nível de compatibilidade padrão é 140. Para verificar o nível de compatibilidade atual do banco de dados, execute o comando a seguir no Transact-SQL, depois de substituir
DATABASE_NAME
pelo nome do banco de dados na instância do SQL Server.
USE DATABASE_NAME GO SELECT compatibility_level FROM sys.databases WHERE name = 'DATABASE_NAME'
Determine o nível de compatibilidade de destino.
Identifique a designação do nível de compatibilidade padrão para sua versão atualizada do banco de dados para determinar o nível de compatibilidade de destino para seu banco de dados. Por exemplo, para o SQL Server 2022, o nível de compatibilidade padrão é 160. Consulte a tabela de mapeamento de novas versões do SQL Server com níveis de compatibilidade.
Avalie as diferenças entre os níveis de compatibilidade atuais e desejados.
Antes de fazer upgrade do nível de compatibilidade, estude as diferenças de comportamento do sistema entre seu nível de compatibilidade atual e seu nível de compatibilidade de destino. Confira a lista completa das diferenças entre os níveis de compatibilidade.
Colete um valor de referência dos dados de carga de trabalho.
Antes de fazer upgrade do nível de compatibilidade, colete um valor de referência dos dados da carga de trabalho usando o SQL Server Query Store para identificar e abordar posteriormente as consultas regressas. Use o Query Store para capturar consultas e planos de um ciclo de negócios típico a fim de estabelecer um valor de referência de desempenho. Para um fluxo de trabalho guiado, use o recurso Query Tuning Assistant no SQL Server Management Studio.
Fazer upgrade do nível de compatibilidade
Para alterar o nível de compatibilidade do banco de dados, execute o comando a seguir no Transact-SQL, depois de substituir
DATABASE_NAME
pelo nome do banco de dados na instância do SQL Server e
TARGET_COMPATIBILITY_LEVEL
pelo nível de compatibilidade desejado.ALTER DATABASE DATABASE_NAME SET COMPATIBILITY_LEVEL = TARGET_COMPATIBILITY_LEVEL; GO
Colete dados de carga de trabalho atualizados.
Colete dados de carga de trabalho atualizados usando o Query Store para comparação e detecção de regressão.
Resolver problemas com consultas regredidas.
Na maioria dos casos, as alterações do Otimizador de consulta nos níveis de compatibilidade atualizados melhoram o desempenho. No entanto, às vezes, certas consultas podem diminuir o desempenho. O recurso Consultas regressadas do Query Store ajuda a identificar as consultas que regressaram e permite forçar o último plano de consulta válido conhecido. O SQL Server também oferece correção automática de planos, que pode ser alternada automaticamente para o último plano válido conhecido no caso de uma regressão de consulta.
Concluir o upgrade da versão principal
Depois de concluir o upgrade da instância principal, execute testes de aceitação para garantir que o sistema atualizado tenha o desempenho esperado.
Resolver problemas de upgrade da versão principal
O Cloud SQL retornará uma mensagem de erro se você tentar utilizar um comando de upgrade inválido, por exemplo, se a instância contiver flags de banco de dados inválidas para a nova versão.
Se a solicitação de upgrade falhar, confira a sintaxe dela. Se a solicitação tiver uma estrutura válida, tente analisar as sugestões a seguir.
Ver registros de upgrade
Se ocorrer algum problema com uma solicitação de upgrade válida, o Cloud SQL
publicará registros de erro em projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fsqlserver.err
. Cada entrada de registro contém um rótulo com o
identificador da instância para ajudar você a identificá-la com o erro de upgrade.
Procure esses erros de upgrade e resolva-os.
Para ver os registros de erro, siga estas etapas:
-
No console do Google Cloud, acesse a página Instâncias do Cloud SQL.
- Para abrir a página Visão geral de uma instância, clique no nome da instância.
No painel Operações e registros da página Visão geral da instância, clique no link Ver registros de erro do SQL Server.
A página Análise de registros é aberta.
Para ver os registros, faça o seguinte:
- Para listar todos os registros de erro em um projeto, selecione o nome do registro no filtro de registro Nome do registro.
Para mais informações sobre filtros de consulta, confira Consultas avançadas.
- Para filtrar os registros de erro de upgrade de uma única instância, digite a
seguinte consulta na caixa Pesquisar todos os campos depois de substituir
DATABASE_ID
pelo ID do projeto, seguido do nome da instância neste formato:
project_id:instance_name
.resource.type="cloudsql_database" resource.labels.database_id="DATABASE_ID" logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fsqlserver.err"
Por exemplo, para filtrar os registros de erro de upgrade por uma instância chamada
shopping-db
em execução no projetobuylots
, use o seguinte filtro de consulta:resource.type="cloudsql_database" resource.labels.database_id="buylots:shopping-db" logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fsqlserver.err"
Restaurar para a versão principal anterior
Se o sistema de banco de dados atualizado não tiver o desempenho esperado, talvez seja necessário restaurar sua instância para a versão anterior. Para fazer isso, restaure seu backup de pré-upgrade para uma instância de recuperação do Cloud SQL, que é uma nova instância que executa a versão de pré-upgrade.
Para restaurar a versão anterior, siga estas etapas:
Identifique seu backup pré-upgrade.
Consulte Backups automáticos de upgrade.
Crie uma instância de recuperação.
Crie uma nova instância do Cloud SQL usando a versão principal que o Cloud SQL estava executando quando foi feito o backup pré-upgrade. Defina as mesmas flags e configurações de instância usadas pela instância original.
Restaure o backup pré-upgrade.
Restaure o backup de pré-upgrade para a instância de recuperação. Esse comando pode levar alguns minutos para ser concluído.
Adicione suas réplicas de leitura.
Se você estava usando réplicas de leitura, adicione-as individualmente.
Conecte o aplicativo.
Depois de recuperar o sistema de banco de dados, atualize o aplicativo com detalhes sobre a instância de recuperação e as réplicas de leitura. É possível retomar a exibição de tráfego na versão de pré-upgrade do seu banco de dados.
Limitações
Esta seção lista as limitações para o upgrade da versão principal local.
- Não é possível realizar um upgrade de versão principal no local em uma réplica externa.
Perguntas frequentes
As seguintes perguntas podem surgir durante o upgrade da versão principal do banco de dados.
- Sim. Enquanto o Cloud SQL realiza o upgrade, a instância permanece indisponível por um período.
- Quanto tempo leva um upgrade?
O upgrade de uma única instância normalmente leva menos de 10 minutos. Se a configuração da instância usar poucas vCPUs ou memória, o upgrade poderá levar mais tempo.
Se a instância hospedar muitos bancos de dados ou tabelas, ou se os bancos de dados forem muito grandes, o upgrade pode levar horas ou até mesmo expirar porque o tempo do upgrade corresponde ao número de objetos nos bancos de dados. Se você tiver várias instâncias que precisam ser atualizadas, o tempo total do upgrade aumentará proporcionalmente.
- Posso monitorar cada etapa do meu processo de upgrade?
- Embora o Cloud SQL permita monitorar se uma operação de upgrade ainda está em andamento, não é possível rastrear as etapas individuais de cada upgrade.
- Posso cancelar meu upgrade após iniciá-lo?
- Não é possível cancelar um upgrade após o início do processo. Se o upgrade falhar, o Cloud SQL recuperará automaticamente a instância na versão anterior.
- O que acontece com minhas configurações durante um upgrade?
Quando você executa um upgrade de versão principal no local, o Cloud SQL mantém as configurações do banco de dados, incluindo o nome da instância, o endereço IP, os valores de flags configurados explicitamente e os dados do usuário. No entanto, o valor padrão das variáveis do sistema pode mudar.
Para saber mais, consulte Configurar flags do banco de dados. Se uma determinada flag ou um valor não for mais aceito na sua versão de destino, o Cloud SQL removerá automaticamente a flag durante o upgrade.
A seguir
- Saiba mais sobre as opções de conexão com uma instância.
- Saiba mais sobre como importar e exportar dados.
- Saiba mais sobre como configurar sinalizações de banco de dados.