Como fazer upgrade de uma instância de primeira geração para a segunda geração

Nesta página, descrevemos como fazer upgrade da sua instância do MySQL de primeira geração para a segunda geração.

Introdução

O Cloud SQL Segunda Geração oferece vantagens significativas em relação à primeira geração. Para instâncias qualificadas, o Cloud SQL aceita o upgrade de uma instância de primeira geração para a segunda geração no local. Se sua instância de primeira geração for qualificada, ela terá um botão Upgrade ao lado do nome na página de listagem de instâncias do console ou na página Detalhes da instância.

O processo de upgrade foi projetado para minimizar o impacto na sua instância e nos seus aplicativos. Por exemplo, a atualização permite que você controle quando ocorre uma transição e preserva o endereço IPv4 da sua instância, para que você não precise fazer alterações imediatas em seu aplicativo. No entanto, como os recursos compatíveis com instâncias de segunda geração do Cloud SQL são diferentes dos da primeira geração, algumas alterações em sua instância ou aplicativo podem ser necessárias.

Antes de começar

Antes de prosseguir com o upgrade de uma instância, é preciso se familiarizar com o processo geral e garantir que você entende como sua instância e seus aplicativos serão afetados por ele.

Requisitos de pré-configuração

As etapas que você precisa executar antes de fazer upgrade para a segunda geração dependem da configuração da sua instância atual e de como seus clientes se conectam.

Se a instância de primeira geração... Você precisa… Mais informações
está configurada com o MySQL 5.5 analisar a lista de diferenças entre o MySQL 5.5 e o 5.6 e seguir as etapas necessárias. Após o upgrade, sua instância usará o MySQL 5.6. Consulte Alterações que afetam upgrades para o MySQL 5.6
tem tabelas que usam o mecanismo de armazenamento MEMORY remover todas as tabelas que usam o mecanismo de armazenamento MEMORY antes de começar o processo de upgrade. Se os dados nessas tabelas forem exigidos pelo seu aplicativo, será necessário movê-los para uma nova tabela que use o mecanismo de armazenamento InnoDB.

Você pode encontrar essas tabelas com o seguinte comando SQL:


SELECT table_schema, table_name, table_type
   FROM information_schema.tables
   WHERE engine = 'MEMORY' AND
   table_schema NOT IN
   ('mysql','information_schema','performance_schema');

O Cloud SQL destaca essas tabelas durante a verificação de configuração anterior ao upgrade.

tem tabelas no banco de dados performance_schema que não usam o mecanismo de armazenamento PERFORMANCE_SCHEMA remover todas as tabelas do banco de dados performance_schema que não usam o mecanismo de armazenamento PERFORMANCE_SCHEMA antes de iniciar o processo de upgrade.

Você pode encontrar essas tabelas com o seguinte comando SQL:


SELECT table_name
   FROM information_schema.tables
   WHERE table_schema='performance_schema'
   AND engine != 'performance_schema';

O Cloud SQL destaca essas tabelas durante a verificação de configuração anterior ao upgrade.

tem dados nas tabelas slow_query_log ou general_log. truncar essas tabelas.

Os dados nessas tabelas não serão trazidos para a instância de segunda geração. Além disso, se essas tabelas tiverem uma grande quantidade de dados, elas poderão causar um tempo de inatividade mais longo (possivelmente horas) durante a alternância.

O Cloud SQL recomenda definir a sinalização log_output como FILE, que envia a saída do registro para o visualizador de registros do console do Google Cloud Platform. Saiba mais.

Se o aplicativo… Entenda que… Mais informações
conecta-se usando o IPv6 e sua instância não tem um endereço IPv4 atribuído é necessário decidir entre alguns minutos extras de inatividade para seus aplicativos e uma atualização extra do aplicativo.

Se alguns minutos de inatividade durante a transição forem aceitáveis, você pode esperar para atualizar seus aplicativos até depois do upgrade, quando o novo endereço IPv4 Público (principal) estiver disponível.

Se você precisa minimizar o tempo de inatividade do aplicativo (sempre haverá algum tempo de inatividade durante a transição), você poderá adicionar um endereço IPv4 à instância de primeira geração e atualizar seus aplicativos para usá-lo antes do início do upgrade. Esse endereço IPv4 persistirá na instância de segunda geração atualizada e será exibido como um endereço IP de primeira geração migrado. No entanto, os endereços IP migrados terão o uso suspenso no futuro, portanto, será necessário atualizar seus aplicativos novamente para usar o novo endereço IPv4 (público).

contém código que não é seguro para GTID. é preciso atualizar seu aplicativo para eliminar as declarações não compatíveis. Você pode fazer essas alterações após o upgrade, se necessário, mas apenas desativando a geração de registros binários após o upgrade. Para melhores resultados, faça as alterações antes do upgrade.
usa o Apps Script e se conecta usando o caminho jdbc original (jdbc:google:rdbms//) é preciso atualizar seu aplicativo para usar o caminho de conexão compatível. Consulte JDBC.

Recomendações pré-configuração

As etapas a seguir não são necessárias, mas utilizá-las pode ajudar a simplificar ou reduzir o processo de upgrade.

Se a instância de primeira geração... Verifique a possibilidade de... Mais informações
é compatível com aplicativos de produção. criar um clone da instância e a realizar o processo de upgrade no clone, inclusive testes dos seus aplicativos no clone atualizado.

Testar o processo de upgrade no clone permite determinar as alterações necessárias (se houver) para sua instância e seus aplicativos antes de tentar o upgrade no seu ambiente de produção.

Para mais informações sobre a clonagem de instâncias, consulte Como clonar instâncias.

não tem backups automáticos ou geração de registros binários ativados ativar ambas as configurações. Você também pode fazer esta etapa durante o processo de upgrade. Esse upgrade requer uma reinicialização da instância.

Configuração e gerenciamento da segunda geração

As instâncias de segunda geração têm requisitos de gerenciamento diferentes das instâncias da primeira geração. Analise a lista de diferenças entre a primeira e a segunda geração e garanta que você entende como essas diferenças afetarão suas práticas de administração do Cloud SQL.

As instâncias de segunda geração oferecem algumas opções de configuração adicionais, como aumento automático de armazenamento, janelas de manutenção configuráveis e backups sob demanda. Consulte Configurações para instâncias de segunda geração para mais informações.

Requisitos de armazenamento e preços

As instâncias da segunda geração reservam mais armazenamento para uso do sistema. Quando você faz upgrade da sua instância para a segunda geração, a quantidade de armazenamento usada aumenta em aproximadamente 0,75 GB.

O preço de armazenamento para a segunda geração é baseado na sua capacidade de armazenamento, e não na quantidade que você está usando. Para saber mais, consulte Preço de armazenamento e rede.

Tipos de máquina

Os tipos de máquinas de segunda geração são diferentes dos níveis de primeira geração e têm preços diferentes. Sua instância de primeira geração receberá um upgrade para uma instância de segunda geração usando o mapeamento mostrado na tabela abaixo. A instância com upgrade fornece pelo menos tantos recursos para a segunda geração quanto os fornecidos para a primeira geração. Você pode alterar o tipo de máquina da sua instância de segunda geração, se necessário, após o upgrade.

Os preços da primeira geração mostrados são do pacote "Sempre ativado".

Nível de primeira geração Tipo de máquina de segunda geração
D0 (0,125 CPU, 128 MB de RAM)
Máximo de conexões: 250
US$ 10,80/mês
db-f1-micro (1 CPU compartilhada, 0,60 GB de RAM)
Máximo de conexões: 250
US$ 10,35/mês
D1 (0,25 CPU, 512 MB de RAM)
Máximo de conexões: 250
US$ 43,80/mês
db-g1-small (1 CPU compartilhada, 1,70 GB de RAM)
Máximo de conexões: 1.000
US$ 28,25/mês
D2 (0,5 CPU, 1 GB de RAM)
Máximo de conexões: 250
US$ 87,90/mês
db-n1-standard-1 (1 CPU, 3,75 GB de RAM)
Máximo de conexões: 4.000
US$ 104,00/mês (incluindo réplica de failover)
D4 (1 CPU, 2 GB de RAM)
Máximo de conexões: 500
US$ 132,00/mês
db-n1-standard-1 (1 CPU, 3,75 GB de RAM)
Máximo de conexões: 4.000
US$ 104,00/mês (incluindo réplica de failover)
D8 (2 CPUs, 4 GB de RAM)
Máximo de conexões: 1.000
US$ 263,40/mês
db-n1-standard-2 (2 CPUs, 7,50 GB de RAM)
Máximo de conexões: 4.000
US$ 210,00/mês (incluindo réplica de failover)
D16 (4 CPUs, 8 GB de RAM)
Máximo de conexões: 2.000
US$ 527,10/mês
db-n1-standard-4 (4 CPUs, 15 GB de RAM)
Máximo de conexões: 4.000
US$ 448,00/mês (incluindo réplica de failover)
D32 (8 CPUs, 16 GB de RAM)
Máximo de conexões: 4.000
US$ 1.053,90/mês
db-n1-standard-8 (8 CPUs, 30 GB de RAM)
Máximo de conexões: 4.000
US$ 996,00/mês (incluindo réplica de failover)

Para mais informações sobre preços de segunda geração, incluindo preços de configuração de amostra, consulte a página de preços.

Política de ativação ON_DEMAND

As instâncias da segunda geração não aceitam a política de ativação ON_DEMAND. Você pode interromper sua instância manualmente, mas ela não responderá a nenhuma solicitação de conexão de entrada até que você a inicie novamente. Saiba mais.

Variáveis e opções do sistema MySQL

Algumas variáveis e opções do sistema MySQL têm valores padrão diferentes para instâncias da segunda geração. Se sua instância tiver variáveis do MySQL definidas para um valor que não seja compatível com a segunda geração, o valor será alterado durante o processo de upgrade. Essas variáveis não são configuráveis.

A tabela a seguir lista as variáveis afetadas e o valor que elas terão após o upgrade:

Variável do sistema Valor da segunda geração
default_time_zone Formato alterado para deslocamento de UTC.
expire_logs_days 0
innodb_log_file_size 512 MB
max_connections Consulte a tabela do tipo de máquina.
sync_binlog ativada

Tempo de inatividade

Seu aplicativo passará por períodos de inatividade durante o upgrade, conforme descrito abaixo:

  1. Se a geração de registros binários não estiver ativada na sua instância de primeira geração, ela será reiniciada para ativar esse recurso, que é necessário para realizar o upgrade.
  2. Sua instância de primeira geração será reiniciada para instalar um certificado SSL/TLS a fim de oferecer suporte à replicação segura entre a instância e a réplica de segunda geração durante o upgrade.
  3. Quando você inicia o processo de alternância e a instância de segunda geração começa a agir como a instância principal, há um intervalo de tempo em que a instância de primeira geração para de responder a solicitações e a instância de segunda geração ainda não está on-line.

    A quantidade de tempo necessária para a alternância é fortemente afetada pela quantidade de atraso da replicação entre a instância e a réplica. Por isso, reduza ou interrompa as operações de gravação antes de alternar.

Considerações sobre aplicativos que se conectam a partir do ambiente padrão do App Engine

Conta de serviço

Para instâncias de primeira geração, você controla o acesso à sua instância por um aplicativo do App Engine autorizando o projeto do aplicativo. Essa autorização é por instância.

Para instâncias de segunda geração, o acesso de um aplicativo do Google App Engine é autorizado por meio de uma conta de serviço, que autoriza o acesso a todas as instâncias do Cloud SQL em um projeto específico.

Quando você faz upgrade de uma instância com um projeto autorizado do App Engine da primeira geração para a segunda geração, o Cloud SQL cria uma conta de serviço especial que fornece o mesmo acesso que o projeto autorizado do App Engine forneceu antes do upgrade. Como essa conta de serviço autoriza o acesso a apenas uma instância específica, em vez de todo o projeto, ela não está visível na página da conta de serviço do IAM, e não é possível atualizá-la ou excluí-la.

Latência de conexão

Em geral, a latência de conexão é diminuída para instâncias de segunda geração em comparação com instâncias de primeira geração. No entanto, para aplicativos que se conectam do ambiente padrão do App Engine, a latência é aumentada em aproximadamente 0,3 ms.

Mudanças na conta do usuário MySQL predefinida

O nome do host para a conta de usuário do MySQL predefinida usada para se conectar do App Engine muda de root@localhost para root@cloudsqlproxy~%.

Se você tem outros usuários do MySQL que usam localhost como host, eles são alterados de maneira similar. O nome do host é atualizado automaticamente nas tabelas grant e user do MySQL durante o processo de migração e, geralmente, não é preciso atualizar o aplicativo do App Engine para contabilizar essa alteração.

No entanto, se o aplicativo ou outras ferramentas que você usa modificarem as tabelas de usuários e as concessões diretamente no MySQL, será preciso atualizá-las para usar cloudsqlproxy~% como o host após a conclusão do upgrade. Não modifique tabelas ou concessões de usuários durante o upgrade.

Essa alteração não afeta o desempenho da conexão que usa essa conta.

Biblioteca de conexões rdbms

Se os aplicativos estiverem usando a biblioteca de conexões rdbms obsoleta, será necessário atualizá-los para usar um método de conexão compatível. A biblioteca rdbms não funcionará com uma instância de segunda geração com upgrade.

Como realizar o upgrade

Depois de concluir as etapas de preparação, será possível prosseguir com o upgrade.

  1. Acesse a página "Instâncias" do Cloud SQL no Console do Google Cloud Platform.
    Acessar a página "Instâncias" do Cloud SQL
  2. Encontre a instância em que você quer fazer upgrade e clique no botão Upgrade ao lado do nome dela.
  3. No painel Upgrade para a segunda geração, clique em Verificar configuração.
  4. Caso a instância precise de atualizações antes do início do upgrade, clique em Executar alterações e siga as instruções fornecidas.
  5. Clique em Continuar para iniciar o processo de upgrade.

    Seus dados são encaminhados para uma réplica, enquanto a instância original permanece ativa. Observação: durante o tempo em que sua instância original e a réplica existem, você é cobrado pelas duas instâncias. Para minimizar as cobranças extras, mude para a nova instância assim que essa etapa for concluída.

  6. Opcional, mas recomendado: crie um clone da sua instância de primeira geração.

    Ter um clone permite reverter para o estado atual se você tiver problemas com o upgrade.

  7. Opcional, mas recomendado: quando a criação da réplica for concluída, encerre seus aplicativos.

    Eles não poderão acessar a instância durante a transição. Isso é particularmente importante se o aplicativo mantém as transações em aberto.

  8. Quando a criação da réplica for concluída, clique em Alternar.

    Isso faz com que a réplica seja promovida e assuma a veiculação de dados. Sua instância deixa de aceitar novas conexões e incorre em 5 a 10 minutos de inatividade. A alternância é exibida como uma operação de failover no painel "Operações".

  9. Após a conclusão da alternância, clique em Concluir para finalizar o processo de upgrade e prossiga para as etapas pós-upgrade.

Confirmar e concluir o upgrade

A lista de verificação a seguir ajuda a confirmar se tudo está funcionando corretamente após a conclusão do processo de upgrade e garante que sua instância de segunda geração esteja configurada corretamente.

Se for preciso reverter o upgrade, consulte Reverter o upgrade.

  • Confirme se seus clientes e aplicativos estão se conectando e operando corretamente.

    As instâncias de segunda geração aceitam GTID. Se ainda for preciso atualizar seus aplicativos para lidar com essa alteração corretamente, será possível desativar temporariamente a geração de registros binários, o que também desativa a verificação de GTID. No entanto, quando você desativa a geração de registros binários, a replicação e a recuperação pontual também são desativadas. Por isso, atualize seus aplicativos para serem seguros para GTID e reative a geração de registros binários assim que possível.

  • Se necessário, configure sua instância para alta disponibilidade.

    Se sua instância veicular dados de produção, essa etapa é altamente recomendada para maior durabilidade e disponibilidade dos dados.

  • Recrie todas as réplicas de leitura necessárias.

    Não é possível reutilizar os nomes das suas réplicas ao recriá-las. Escolha nomes diferentes.

  • Se os aplicativos estiverem se conectando usando IPv6 ou um endereço IPv4 criado antes do upgrade, atualize-os para usar o novo endereço Público (principal) que foi atribuído durante o upgrade.

    Um endereço IPv4 criado antes do upgrade é exibido como um endereço IP da primeira geração migrado. Os endereços IP migrados se tornarão obsoletos no futuro.

  • Avalie a possibilidade de atualizar seus outros caminhos de conexão.

    Mesmo que, na maioria dos casos, você possa continuar a usar os mesmos caminhos de conexão que usava antes do upgrade, há algumas novas opções disponíveis:

  • Se os aplicativos estiverem se conectando usando o nome da conexão da instância de primeira geração:

    <project_id>:<instance_id>

    atualize-os para usar o nome da conexão da instância de segunda geração:

    <project_id>:<region>:<instance_id>.

  • Se os bancos de dados tiverem alguma tabela MyISAM (diferente das tabelas de sistema), considere convertê-los para usar o mecanismo de armazenamento InnoDB.

    Você pode continuar a usar tabelas MyISAM. No entanto, para maior durabilidade dos dados, o Cloud SQL recomenda essa conversão. Para mais informações, consulte Como converter tabelas do MyISAM para o InnoDB.

Reverter o upgrade

Se você encontrar problemas com sua instância de segunda geração atualizada, poderá criar uma nova instância com o mesmo estado que a instância de primeira geração tinha antes de iniciar o processo de upgrade.

  1. Se você criou um clone durante o processo de upgrade, atualize seus aplicativos para apontarem para ele.
  2. Caso contrário, conclua as seguintes etapas:

    1. Crie uma nova instância de primeira geração com o mesmo nível da sua instância original.
    2. Abra a página Backups da instância com upgrade e encontre o backup feito no momento em que o processo de upgrade foi iniciado.
    3. Restaure o backup para a nova instância de primeira geração que você acabou de criar.

      Para mais informações, consulte Como restaurar para uma instância diferente.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Cloud SQL para MySQL