Atualize a versão principal da base de dados no local

Esta página descreve como atualizar a versão principal da base de dados atualizando a instância do Cloud SQL no local, em vez de migrar dados.

Introdução

Os fornecedores de software de base de dados lançam periodicamente novas versões principais que contêm novas funcionalidades, melhorias de desempenho e melhoramentos de segurança. O Cloud SQL aceita novas versões após o respetivo lançamento. Depois de o Cloud SQL oferecer suporte para uma nova versão principal, pode atualizar as suas instâncias para manter a base de dados atualizada.

Pode atualizar a versão da base de dados de uma instância no local ou migrando os dados. As atualizações no local são uma forma mais simples de atualizar a versão principal da sua instância. Não precisa de migrar dados nem alterar strings de ligação de aplicações. Com as atualizações no local, pode manter o nome, o endereço IP e outras definições da sua instância atual após a atualização. As atualizações no local não exigem que mova ficheiros de dados e podem ser concluídas mais rapidamente. Em alguns casos, o tempo de inatividade é inferior ao que a migração dos seus dados implica.

Para o MySQL 8.0.15 e versões anteriores, a operação de atualização no local do MySQL usa o utilitário mysql_upgrade. Para o MySQL 8.0.16 e posterior, a operação de atualização no local do MySQL é processada pelo processo MySQL server. Para mais informações acerca da operação de atualização no local, consulte o artigo O que o processo de atualização do MySQL atualiza

Planeie uma atualização da versão principal

  1. Confirme que tem a função necessária para fazer uma atualização da versão principal: Proprietário do Cloud SQL ou Administrador do Cloud SQL.

  2. Escolha uma versão principal de destino.

    gcloud

    Para informações sobre a instalação e o início da utilização da CLI gcloud, consulte o artigo Instale a CLI gcloud. Para obter informações sobre como iniciar a Cloud Shell, consulte o artigo Use a Cloud Shell.

    Para verificar as versões da base de dados que pode segmentar para uma atualização no local na sua instância, faça o seguinte:

    1. Execute o seguinte comando.
      2. gcloud sql instances describe INSTANCE_NAME

      Substitua INSTANCE_NAME pelo nome da instância.

    2. Na saída do comando, localize a secção com a etiqueta upgradableDatabaseVersions.
    3. Cada subsecção devolve uma versão da base de dados que está disponível para atualização. Em cada subsecção, reveja os seguintes campos.
      • majorVersion: a versão principal que pode segmentar para a atualização no local.
      • name: a string da versão da base de dados que inclui a versão principal. Para o Cloud SQL para MySQL, este campo também inclui a versão secundária da base de dados.
      • displayName: o nome a apresentar da versão da base de dados.

    REST v1

    Para verificar que versões da base de dados de destino estão disponíveis para uma atualização no local de uma versão principal, use o método instances.get da API Cloud SQL Admin.

    Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • INSTANCE_NAME: o nome da instância.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    REST v1beta4

    Para verificar que versões da base de dados de destino estão disponíveis para a atualização no local da versão principal de uma instância, use o método instances.get da API Admin do Cloud SQL.

    Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • INSTANCE_NAME: o nome da instância.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    Para ver a lista completa das versões de bases de dados suportadas pelo Cloud SQL, consulte o artigo Versões de bases de dados e políticas de versões.

  3. Considere as funcionalidades oferecidas em cada versão principal da base de dados e resolva as incompatibilidades.

    As novas versões principais introduzem alterações incompatíveis que podem exigir que modifique o código da aplicação, o esquema ou as definições da base de dados. Antes de poder atualizar a instância da base de dados, reveja as notas de lançamento da versão principal de destino para determinar as incompatibilidades que tem de resolver.

    Após a atualização para uma versão posterior, o valor predefinido de algumas variáveis do sistema pode mudar. Por exemplo, o valor predefinido de character_set_server no MySQL 5.6 e no MySQL 5.7 é utf8. Quando atualiza para o MySQL 8.0, o valor predefinido de character_set_server é alterado para utf8mb4. Para reverter para utf8, tem de alterar manualmente o valor da flag da base de dados para o valor antigo. Consulte o artigo Configure flags da base de dados para mais informações. A maioria das alterações aos valores predefinidos são feitas pela comunidade MySQL (consulte mais informações em Atualize as predefinições do servidor).

  4. Faça a pré-verificação de atualizações.

    • Se estiver a atualizar do MySQL 5.7 para o 8.0, faça uma pré-verificação das atualizações do MySQL 5.7 para o 8.0. Pode usar o utilitário Upgrade Checker na shell do MySQL.

    • Se estiver a atualizar do MySQL 8.0 para o 8.4, faça uma pré-verificação das atualizações do MySQL 8.0 para o 8.4. Pode usar o utilitário Upgrade Checker na shell do MySQL.

      Se forem encontrados problemas durante a pré-verificação, corrija-os antes de avançar para a atualização. O Cloud SQL não suporta a pré-verificação durante uma atualização de versão principal. Uma tentativa de atualizar uma instância que falhou na pré-verificação também pode falhar.

  5. Verifique o espaço em disco e os tipos de máquinas de instância.

    Uma atualização da versão principal requer recursos adicionais, como espaço em disco, para armazenar tabelas atualizadas. Se o espaço em disco não for suficiente, a atualização falha e é revertida. Para uma atualização do MySQL 5.7 para a versão 8.0, é necessária memória adicional para converter os metadados antigos no novo dicionário de dados. Antes de executar uma atualização da versão principal, certifique-se de que tem mais de 100 KB de memória para cada tabela. Pode aumentar temporariamente a memória alterando o tipo de máquina.

  6. Para atualizações do MySQL 5.7 para o MySQL 8.0, verifique se existem alterações de concessão de utilizadores no MySQL 8.0

    O Cloud SQL para MySQL versão 8.0 usa uma flag denominada partial_revokes, que está definida como ON por predefinição. Ao contrário do MySQL 5.7, esta flag remove a capacidade de usar carateres universais em comandos GRANT da base de dados. Para garantir que os utilizadores da base de dados têm acesso aos esquemas de base de dados corretos, modifique os privilégios dos utilizadores da base de dados antes de atualizar para o MySQL 8.0. Atualize os privilégios do utilizador para usar o nome completo dos esquemas de base de dados necessários em vez de usar carateres universais.

    Para mais informações sobre como esta flag funciona no MySQL 8.0, consulte revogações parciais no MySQL 8.0.

  7. Teste a atualização com um teste prévio.

    Faça um teste do processo de atualização ponto a ponto num ambiente de teste antes de atualizar a base de dados de produção. Pode clonar a sua instância para criar uma cópia idêntica dos dados nos quais testar o processo de atualização.

    Além de validar se a atualização é concluída com êxito, execute testes para garantir que a aplicação funciona como esperado na base de dados atualizada.

  8. Decida quando fazer a atualização.

    A atualização requer que a instância fique indisponível durante um período. Planeie a atualização durante um período em que a atividade da base de dados seja baixa.

Prepare-se para uma atualização da versão principal

Antes de fazer a atualização, conclua os seguintes passos:

  1. APENAS para atualizações do MySQL 5.7 para 8.0: verifique e corrija problemas incompatíveis encontrados durante o processo de pré-verificação. Os problemas comuns encontrados podem incluir:

    1. Adição de novas palavras-chave reservadas, como RANKS, GROUPS e FUNCTION, em procedimentos armazenados, acionadores e outros objetos da base de dados. Consulte o artigo Palavras-chave e palavras reservadas para mais informações.
    2. Carateres UTF inválidos nas definições de tabelas.
    3. Transições XA não comprometidas que têm de ser comprometidas (com a declaração XA COMMIT) ou revertidas (com a declaração XA ROLLBACK).
    4. Restrição de chave externa em nomes com mais de 64 carateres.
    5. Tipo de dados espaciais no índice misto de colunas. Para mais informações, consulte o artigo Tipo de dados espaciais.

    Para obter ajuda na resolução de problemas de erros e problemas conhecidos durante a pré-verificação, consulte o artigo Problemas conhecidos com a atualização no local para o MySQL 8.0. Para mais informações sobre problemas comuns do MySQL, consulte os artigos Prepare a sua instalação para a atualização e Vai atualizar para o MySQL 8.0?.

    APENAS para atualizações do MySQL 8.0 para o MySQL 8.4: verifique e corrija os problemas incompatíveis encontrados durante o processo de pré-verificação. Um problema comum pode incluir:

    • Terminologia de replicação desatualizada. Os termos MASTER e SLAVE são completamente removidos do MySQL 8.4. Se ainda usar comandos ou configurações com estes termos, tem de os substituir ou remover. Para mais informações sobre a remoção e a substituição destes termos, consulte Novidades no MySQL 8.4 desde o MySQL 8.0.
    • Atualize o plug-in de autenticação das suas contas de utilizador existentes para usar o plug-in de autenticação caching_sha2_password em vez do plug-in mysql_native_password descontinuado.

      Para alterar as contas de utilizador da base de dados existentes para usar o plug-in de autenticação caching_sha2_password, use o seguinte comando: 
           ALTER USER 'username'@'%'
     IDENTIFIED WITH caching_sha2_password BY 'user_password';
      Substitua username e user_password pelos valores da conta de utilizador que está a atualizar.

  2. Verifique o espaço em disco e o tipo de máquina da instância

    As atualizações de versões principais requerem espaço em disco e memória adicionais para armazenar as tabelas atualizadas e o novo dicionário de dados. O espaço em disco insuficiente faz com que a atualização falhe e seja revertida para a versão original. O Cloud SQL recomenda que tenha, no mínimo, 100 KB de memória para cada tabela.

    Nota: pode aumentar temporariamente a memória alterando o tipo de máquina antes de executar a atualização da versão principal. Para saber mais, consulte o artigo sobre como alterar o tipo de máquina.

Faça a atualização da versão principal

Pode atualizar a versão principal de uma única instância do Cloud SQL ou atualizar a versão principal de uma instância principal e incluir todas as respetivas réplicas na atualização, incluindo réplicas em cascata e réplicas entre regiões.

Atualize a versão principal de uma única instância

Quando inicia uma operação de atualização para uma única instância, o Cloud SQL faz o seguinte:

  1. Verifica a configuração da sua instância para garantir que a instância é compatível com uma atualização.
  2. Depois de o Cloud SQL validar a configuração, o Cloud SQL torna a instância indisponível.
  3. Faz uma cópia de segurança antes da atualização.
  4. Realiza a atualização na instância.
  5. Disponibiliza a sua instância.
  6. Faz uma cópia de segurança após a atualização.
Quando atualiza para o MySQL 8.0, o Cloud SQL aprovisiona automaticamente a sua instância na versão secundária predefinida.

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Edit.
  4. Na secção Informações da instância, clique no botão Atualizar e confirme que quer aceder à página de atualização.
  5. Na página Escolha uma versão da base de dados, clique na lista Versão principal da base de dados para atualização e selecione uma das versões principais da base de dados disponíveis.
  6. Clique em Continuar.
  7. Na caixa ID da instância, introduza o nome da instância e, de seguida, clique no botão Iniciar atualização.
A operação demora vários minutos a ser concluída.

Verifique se a versão principal da base de dados atualizada é apresentada abaixo do nome da instância na página Vista geral da instância.

gcloud

  1. Inicie a atualização.

    Use o comando gcloud sql instances patch com a flag --database-version.

    Antes de executar o comando, substitua o seguinte:

    • INSTANCE_NAME: o nome da instância.
    • DATABASE_VERSION: a enumeração para a versão principal da base de dados, que tem de ser posterior à versão atual. Especifique uma versão da base de dados para uma versão principal que esteja disponível como destino de atualização para a instância. Pode obter esta enumeração como o primeiro passo do Plan for upgrade. Se precisar de uma lista completa de enumerações de versões de bases de dados, consulte SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    As atualizações de versões principais demoram vários minutos a serem concluídas. Pode ver uma mensagem a indicar que a operação está a demorar mais do que o esperado. Pode ignorar esta mensagem ou executar o comando gcloud sql operations wait para ignorar a mensagem.

  2. Obtenha o nome da operação de atualização.

    Use o comando gcloud sql operations list com a flag --instance.

    Antes de executar o comando, substitua a variável INSTANCE_NAME pelo nome da instância. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitorize o estado da atualização.

    Use o comando gcloud sql operations describe.

    Antes de executar o comando, substitua a variável OPERATION pelo nome da operação de atualização obtido no passo anterior. 

    gcloud sql operations describe OPERATION

REST v1

  1. Inicie a atualização no local.

    Use um pedido PATCH com o método instances:patch.

    Antes de usar qualquer um dos dados do pedido, substitua estas variáveis:

    • PROJECT_ID: o ID do projeto.
    • INSTANCE_NAME: o nome da instância.

    Método HTTP e URL: 

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

    Corpo JSON do pedido: 

    {
  "databaseVersion": DATABASE_VERSION
}

    Substitua DATABASE_VERSION pela enumeração da versão principal da base de dados, que tem de ser posterior à versão atual. Especifique uma versão da base de dados para uma versão principal que esteja disponível como destino de atualização para a instância. Pode obter esta enumeração como o primeiro passo do Plan for upgrade. Se precisar de uma lista completa de enumerações de versões da base de dados, consulte SqlDatabaseVersion.

  2. Obtenha o nome da operação de atualização.

    Use um pedido GET com o método operations.list depois de substituir PROJECT_ID pelo ID do projeto.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitorize o estado da atualização.

    Use um pedido GET com o método operations.get depois de substituir as seguintes variáveis:

    • PROJECT_ID: o ID do projeto.
    • OPERATION_NAME: o nome da operação de atualização obtido no passo anterior.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Para atualizar a versão da base de dados, use um recurso do Terraform e o fornecedor do Terraform para Google Cloud, versão 4.34.0 ou posterior.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Aplique as alterações

Para aplicar a configuração do Terraform num Google Cloud projeto, conclua os passos nas secções seguintes.

Prepare o Cloud Shell

  1. Inicie o Cloud Shell.

  2. Defina o Google Cloud projeto predefinido onde quer aplicar as suas configurações do Terraform.

    Só tem de executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    As variáveis de ambiente são substituídas se definir valores explícitos no ficheiro de configuração do Terraform.

Prepare o diretório

Cada ficheiro de configuração do Terraform tem de ter o seu próprio diretório (também denominado módulo raiz).

  1. No Cloud Shell, crie um diretório e um novo ficheiro nesse diretório. O nome do ficheiro tem de ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o ficheiro é denominado main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Se estiver a seguir um tutorial, pode copiar o código de exemplo em cada secção ou passo.

    Copie o exemplo de código para o ficheiro main.tf criado recentemente.

    Opcionalmente, copie o código do GitHub. Isto é recomendado quando o fragmento do Terraform faz parte de uma solução completa.

  3. Reveja e modifique os parâmetros de exemplo para aplicar ao seu ambiente.
  4. Guarde as alterações.
  5. Inicialize o Terraform. Só tem de fazer isto uma vez por diretório. 
    terraform init

    Opcionalmente, para usar a versão mais recente do fornecedor Google, inclua a opção -upgrade: 

    terraform init -upgrade

Aplique as alterações

  1. Reveja a configuração e verifique se os recursos que o Terraform vai criar ou atualizar correspondem às suas expetativas: 
    terraform plan

    Faça as correções necessárias à configuração.

  2. Aplique a configuração do Terraform executando o seguinte comando e introduzindo yes no comando: 
    terraform apply

    Aguarde até que o Terraform apresente a mensagem "Apply complete!" (Aplicação concluída!).

  3. Abra o seu Google Cloud projeto para ver os resultados. Na Google Cloud consola, navegue para os seus recursos na IU para se certificar de que o Terraform os criou ou atualizou.

Eliminar as alterações

Para eliminar as alterações, faça o seguinte:

  1. Para desativar a proteção contra eliminação, no ficheiro de configuração do Terraform, defina o argumento deletion_protection como false. 
    deletion_protection =  "false"
  2. Aplique a configuração do Terraform atualizada executando o seguinte comando e introduzindo yes no comando: 
    terraform apply

  1. Remova os recursos aplicados anteriormente com a sua configuração do Terraform executando o seguinte comando e introduzindo yes no comando:

    terraform destroy

Quando envia um pedido de atualização no local, o Cloud SQL executa primeiro uma verificação pré-atualização. Se o Cloud SQL determinar que a sua instância não está preparada para uma atualização, o pedido de atualização falha com uma mensagem que sugere como pode resolver o problema. Consulte também o artigo Resolva problemas de uma atualização de versão principal.

Inclua réplicas na atualização da versão principal

Se a sua instância principal tiver réplicas, pode incluir todas as réplicas na atualização. O Cloud SQL pode atualizar todas as réplicas da instância principal, incluindo réplicas entre regiões e réplicas em cascata.

Quando inclui réplicas numa atualização da versão principal, o Cloud SQL faz o seguinte:

  1. Verifica a configuração da instância principal e das réplicas para garantir que a instância e as réplicas são compatíveis para uma atualização.
  2. Torna a sua instância principal indisponível.
  3. Cria uma cópia de segurança pré-atualização da instância principal.
  4. Interrompe a replicação para todas as réplicas.
  5. Realiza a atualização na instância principal.
  6. Se a atualização na instância principal for bem-sucedida, a instância principal fica novamente disponível e reinicia a replicação.
  7. O Cloud SQL faz uma cópia de segurança pós-atualização da instância principal.
  8. O Cloud SQL prossegue com a atualização de todas as réplicas.

Mesmo que a atualização da versão principal de uma réplica falhe, a instância principal continua disponível.

Para incluir réplicas numa atualização de versão principal, não pode usar aGoogle Cloud consola nem o Terraform. Só pode usar a CLI gcloud ou a API Admin do Cloud SQL.

gcloud

  1. Inicie a atualização.

    Use o comando gcloud sql instances patch com as flags --database-version e --include-replicas-for-major-version-upgrade.

    Antes de executar o comando, substitua o seguinte:

    • INSTANCE_NAME: o nome da instância principal.
    • DATABASE_VERSION: a enumeração para a versão principal da base de dados, que tem de ser posterior à versão atual. Especifique uma versão da base de dados para uma versão principal que esteja disponível como destino de atualização para a instância. Pode obter esta enumeração como o primeiro passo do Plan for upgrade. Se precisar de uma lista completa de enumerações de versões de bases de dados, consulte SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --include-replicas-for-major-version-upgrade

    As atualizações de versões principais demoram vários minutos a serem concluídas. Pode ver uma mensagem a indicar que a operação está a demorar mais do que o esperado. Pode ignorar esta mensagem ou executar o comando gcloud sql operations wait para ignorar a mensagem. A atualização de réplicas pode demorar vários minutos a ser concluída. Para verificar o estado da atualização, faça o seguinte:

  2. Obtenha o nome da operação de atualização.

    Use o comando gcloud sql operations list com a flag --instance.

    Antes de executar o comando, substitua a variável INSTANCE_NAME pelo nome da instância. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitorize o estado da atualização.

    Use o comando gcloud sql operations describe.

    Antes de executar o comando, substitua a variável OPERATION pelo nome da operação de atualização obtido no passo anterior. 

    gcloud sql operations describe OPERATION

REST

  1. Inicie a atualização no local.

    Use um pedido PATCH com o método instances:patch.

    Antes de usar qualquer um dos dados do pedido, substitua estas variáveis:

    • PROJECT_ID: o ID do projeto.
    • INSTANCE_NAME: o nome da instância.

    Método HTTP e URL: 

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

    Corpo JSON do pedido: 

    {
  "databaseVersion": DATABASE_VERSION
  "includeReplicasForMajorVersionUpgrade": true
}

    • Substitua DATABASE_VERSION pela enumeração da versão principal da base de dados, que tem de ser posterior à versão atual. Especifique uma versão da base de dados para uma versão principal que esteja disponível como destino de atualização para a instância. Pode obter esta enumeração como o primeiro passo do Plan for upgrade. Se precisar de uma lista completa de enumerações de versões da base de dados, consulte SqlDatabaseVersion.
    • No campo includeReplicasForMajorVersionUpgrade, especifique true.

  2. Obtenha o nome da operação de atualização.

    Use um pedido GET com o método operations.list depois de substituir PROJECT_ID pelo ID do projeto.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitorize o estado da atualização.

    Use um pedido GET com o método operations.get depois de substituir as seguintes variáveis:

    • PROJECT_ID: o ID do projeto.
    • OPERATION_NAME: o nome da operação de atualização obtido no passo anterior.

    Método HTTP e URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Cópias de segurança de atualizações automáticas

Quando faz uma atualização da versão principal, o Cloud SQL faz automaticamente duas cópias de segurança a pedido, denominadas cópias de segurança de atualização:

  • A primeira cópia de segurança da atualização é a cópia de segurança pré-atualização, que é feita imediatamente antes de iniciar a atualização. Pode usar esta cópia de segurança para restaurar a instância da base de dados para o estado em que se encontrava na versão anterior.
  • A segunda cópia de segurança da atualização é a cópia de segurança pós-atualização, que é feita imediatamente após serem permitidas novas gravações na instância da base de dados atualizada.

Quando vê a sua lista de cópias de segurança, as cópias de segurança de atualização são apresentadas com o tipo On-demand. As atualizações das cópias de segurança são etiquetadas para que as possa identificar rapidamente. Por exemplo, se estiver a atualizar do MySQL 5.7 para o MySQL 8.0, a cópia de segurança anterior à atualização é etiquetada como Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. e a cópia de segurança posterior à atualização é etiquetada como Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. Se estiver a atualizar do MySQL 8.0 para o MySQL 8.4, a cópia de segurança anterior à atualização é etiquetada como Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. e a cópia de segurança posterior à atualização é etiquetada como Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0..

Tal como acontece com outras cópias de segurança a pedido, as cópias de segurança de atualização persistem até as eliminar ou eliminar a instância. Se tiver a PITR ativada, não pode eliminar as cópias de segurança de atualização enquanto estiverem no período de retenção. Se precisar de eliminar as cópias de segurança da atualização, tem de desativar a PITR ou aguardar até que as cópias de segurança da atualização deixem de estar no período de retenção.

Conclua a atualização da versão principal

Depois de concluir a atualização da instância principal, siga os passos seguintes para concluir a atualização:

  1. Realize testes de aceitação.

    Execute testes para confirmar que o sistema atualizado está a ter o desempenho esperado.

  2. Opcional: atualize os privilégios do utilizador.

    Se atualizou para o MySQL 8.0, tenha em atenção que o MySQL alterou os sistemas de segurança e gestão de contas. Para mais informações, consulte o artigo O que há de novo no MySQL 8.0.

    Isto pode fazer com que os utilizadores criados na versão 5.7 do MySQL da instância não tenham os mesmos privilégios que os utilizadores criados diretamente no MySQL 8.0. Por exemplo, um utilizador atualizado a partir do MySQL 5.7 pode não ter privilégios CREATE ROLE e DROP ROLE porque estes privilégios não existiam no MySQL 5.7. O Cloud SQL recomenda que reponha os privilégios do utilizador após a atualização das versões para corrigir quaisquer problemas relacionados com os privilégios do utilizador.

    Se atualizou do MySQL 8.0 para o MySQL 8.4, existem alterações adicionais aos privilégios do utilizador, incluindo a adição de privilégios introduzidos no MySQL 8.4 e a remoção de privilégios que existiam no MySQL 8.0. Para mais informações, consulte Privilégios do utilizador do MySQL 8.4 (cloudsqlsuperuser).

    Pode atualizar os privilégios do utilizador no MySQL 8.0 ou no MySQL 8.4 fazendo o seguinte:

    1. Crie um utilizador com a função cloudsqlsuperuser concedida.

    2. Use o utilizador criado para revogar todos os privilégios anteriores de um utilizador atualizado com:

      REVOKE ALL PRIVILEGES ON *.* FROM user@host
    3. Conceda os privilégios esperados ao utilizador atualizado.

  3. Opcional: crie uma cópia de segurança.

    Embora o Cloud SQL crie automaticamente uma cópia de segurança após a atualização da instância principal, o Cloud SQL recomenda que crie uma cópia de segurança por si para poder recuperar a base de dados, se necessário.

  4. Opcional: se atualizou para o Cloud SQL para MySQL 8.4, também deve atualizar todos os conetores, clientes e shells do MySQL para o MySQL 8.4.

Resolva problemas com uma atualização da versão principal

O Cloud SQL devolve uma mensagem de erro se tentar executar um comando de atualização inválido, por exemplo, se a sua instância contiver flags de base de dados inválidas para a nova versão.

Se o seu pedido de atualização falhar, verifique a sintaxe do pedido de atualização. Se o pedido tiver uma estrutura válida, experimente as seguintes sugestões.

Veja registos de erros

Se ocorrerem problemas com um pedido de atualização válido, o Cloud SQL publica registos de erros em projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Cada entrada do registo contém uma etiqueta com o identificador da instância para ajudar a identificar a instância com o erro de atualização. Procure esses erros de atualização e resolva-os.

Para ver os registos de erros, use a Google Cloud consola::

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.

  3. No painel Operações e registos da página Vista geral da instância, clique no link Ver registos de erros do MySQL.

    É apresentada a página Explorador de registos.

  4. Veja os registos da seguinte forma:

    • Para listar todos os registos de erros num projeto, selecione o nome do registo no filtro de registo Nome do registo.

    Para mais informações sobre filtros de consultas, consulte o artigo Consultas avançadas.

    • Para filtrar os registos de erros de atualização de uma única instância, introduza a seguinte consulta na caixa Pesquisar todos os campos, depois de substituir DATABASE_ID

    com o 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%2Fmysql.err"

    Por exemplo, para filtrar os registos de erros de atualização por uma instância denominada shopping-db em execução no projeto buylots, use o seguinte filtro de consulta:

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

    Pode rever todos os registos comunicados num determinado período ou filtrar os registos por gravidade. Uma opção comum para a resolução de problemas pode incluir a seleção dos seguintes filtros:

    • Emergência
    • Alerta
    • Crítico
    • Erro

    Pode encontrar alguns problemas conhecidos durante a pré-verificação e a atualização da versão 5.7 para a 8.0 do MySQL. Para obter ajuda na resolução destes problemas, consulte o artigo Problemas conhecidos com a atualização no local para o MySQL 8.0.

Restaure a instância principal para a versão principal anterior

Se o sistema de base de dados atualizado não tiver o desempenho esperado, pode ter de restaurar a instância principal para a versão anterior. Para tal, restaure a cópia de segurança anterior à atualização para uma instância de recuperação do Cloud SQL, que é uma nova instância que executa a versão anterior à atualização.

Para restaurar uma instância principal para a versão anterior, siga estes passos:

  1. Identifique a cópia de segurança anterior à atualização.

    Consulte o artigo Cópias de segurança de atualizações automáticas.

  2. Crie uma instância de recuperação.

    Crie uma nova instância do Cloud SQLcom a versão principal que o Cloud SQL estava a executar quando foi feita a cópia de segurança pré-atualização. Defina as mesmas sinalizações e definições de instância que a instância original usa.

  3. Restaure a cópia de segurança anterior à atualização.

    Restaure a cópia de segurança anterior à atualização na instância de recuperação. Este processo pode demorar alguns minutos.

  4. Adicione as réplicas de leitura.

    Se estiver a usar réplicas de leitura, adicione-as individualmente.

  5. Associe a sua aplicação.

    Depois de recuperar o sistema de base de dados, atualize a aplicação com detalhes sobre a instância de recuperação e as respetivas réplicas de leitura. Pode retomar a publicação de tráfego na versão anterior à atualização da sua base de dados.

Limitações

Esta secção apresenta as limitações de uma atualização da versão principal no local.

  • Não é possível fazer uma atualização da versão principal no local numa réplica externa.
  • A atualização de instâncias do MySQL 5.7 para 8.0 com mais de 512 000 tabelas pode demorar muito tempo e atingir o limite de tempo.
  • A atualização de instâncias do MySQL 8.0 para 8.4 com mais de 512 000 tabelas pode demorar muito tempo e atingir o limite de tempo.

  • Quando atualiza do MySQL 8.0 para o 8.4, se tiver atualizado uma réplica para o MySQL 8.4, mas não a instância principal, é possível criar uma nova conta de utilizador numa instância principal não atualizada com o plug-in de autenticação mysql_native_password obsoleto. Para evitar esta situação, certifique-se de que atualiza a instância principal imediatamente após atualizar as réplicas ou cria novas contas de utilizador apenas na instância principal através do seguinte comando.

    CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

    Substitua USERNAME e PASSWORD por valores adequados.

Perguntas frequentes

As seguintes perguntas podem surgir quando atualizar a versão principal da base de dados.

A minha instância fica indisponível durante uma atualização?
Sim. A sua instância permanece indisponível durante um período enquanto o Cloud SQL realiza a atualização.
Quanto tempo demora uma atualização?

Normalmente, a atualização de uma única instância demora menos de 10 minutos. Se a configuração da instância tiver um número reduzido de vCPUs ou memória, a atualização pode demorar mais tempo.

Se a sua instância alojar demasiadas bases de dados ou tabelas, ou se as suas bases de dados forem muito grandes, a atualização pode demorar horas ou até expirar, uma vez que o tempo total de atualização corresponde ao número de objetos nas suas bases de dados. Se tiver várias instâncias que precisam de ser atualizadas, o tempo de atualização aumenta proporcionalmente. Se incluir réplicas na atualização, a operação de atualização pode demorar até uma hora a ser concluída, consoante o número de réplicas que a instância principal tem.

Posso monitorizar cada passo no meu processo de atualização?
Embora o Cloud SQL lhe permita monitorizar se uma operação de atualização ainda está em curso, não pode acompanhar os passos individuais em cada atualização.
Posso cancelar a atualização depois de a iniciar?
Não, não pode cancelar uma atualização depois de esta ter começado. Se a atualização falhar, o Cloud SQL recupera automaticamente a sua instância na versão anterior.
O que acontece às minhas definições durante uma atualização?

Quando faz uma atualização da versão principal no local, o Cloud SQL retém as definições da base de dados, incluindo o nome da instância, o endereço IP, os valores de flags configurados explicitamente e os dados do utilizador. No entanto, o valor predefinido das variáveis do sistema pode mudar. Por exemplo, o valor predefinido da flag character_set_server no MySQL 5.7 é utf8. Quando atualiza para o MySQL 8.0, o valor predefinido da flag é alterado para utf8mb4. Para reverter para utf8, defina o valor da flag novamente para o valor anterior.

Para saber mais, consulte o artigo Configure flags da base de dados. Se uma determinada flag ou valor deixar de ser suportado na versão de destino, o Cloud SQL remove automaticamente a flag durante a atualização.

O que posso fazer se a replicação falhar depois de atualizar uma réplica?

Se a replicação for interrompida após a atualização de uma réplica, o Cloud SQL reverte a réplica para a versão principal do MySQL da instância principal. Pode atualizar novamente a réplica, mas se o problema persistir, a replicação pode falhar novamente. Por este motivo, recomendamos que inclua as suas réplicas quando fizer uma atualização da versão principal, em vez de atualizar cada réplica separadamente.

Se a réplica não for revertida para a mesma versão principal que a instância principal, tem duas opções:

  1. Elimine a réplica danificada, crie uma nova réplica e atualize a nova réplica.

    Se a atualização falhar novamente, é provável que seja causada por alterações incompatíveis adicionadas à instância principal quando foi atualizada. Resolva os problemas da atualização para localizar o problema, corrija a instância principal e tente atualizar a réplica. Para mais informações, consulte a secção resolução de problemas.

  2. Atualize a instância principal

    Se a replicação não estiver a funcionar, a operação de atualização na instância principal recria as réplicas.

Por que motivo a minha réplica atualizada reverteu para a versão principal anterior?

Se uma atualização não for bem-sucedida, a réplica é revertida para a versão da instância principal. Pode atualizar novamente a réplica, mas, se o problema persistir, pode verificar o registo mysql.err na réplica para encontrar a origem. Pesquise palavras-chave como [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Se a mensagem de erro contiver Access denied for AuthId.... com alterações de privilégios do utilizador, é provável que esteja a ser executada uma consulta com privilégios do utilizador do MySQL 5.7 nos esquemas mysql e sys, e pode falhar devido às alterações aos sistemas de segurança e gestão de contas no MySQL 8.0. Para resolver este problema, tem de parar as consultas na instância principal antes de atualizar a instância principal para a nova versão e, em seguida, tentar novamente a atualização da réplica. O Cloud SQL recomenda que pare temporariamente todas essas consultas na instância principal também antes de atualizar para a nova versão, uma vez que podem originar um problema semelhante.

Se não vir o motivo da falha, como Access denied for AuthID.... nos registos do MySQL, é provável que o problema seja causado por novos dados incompatíveis que podem ter sido adicionados à instância principal após a atualização da réplica. Consulte o artigo Prepare-se para uma atualização de versão principal para saber como corrigir problemas de incompatibilidade antes de voltar a fazer a atualização.

O que se segue?