Migração do MySQL para o Cloud SQL

Neste documento, descrevemos como planejar e executar o processo de migração de um banco de dados MySQL 5.7 não particionado (em inglês) para o Cloud SQL, um serviço de banco de dados totalmente gerenciado no Google Cloud. Neste documento, presume-se que você tenha um banco de dados MySQL e esteja familiarizado com os conceitos do MySQL e do Google Cloud.

Os conceitos discutidos neste documento se aplicam a outras versões do MySQL e ao MariaDB (em inglês), um conhecido garfo de código aberto do MySQL. No entanto, para versões diferentes do MySQL 5.7, os processos podem precisar de pequenas modificações. Há muitas ferramentas de terceiros e parceiros do Cloud SQL que podem ser usados para planejar uma migração de banco de dados. Neste documento, discutimos apenas a funcionalidade nativa do MySQL e do Google Cloud e não abordamos outras ferramentas ou parceiros.

Você encontra orientações para um dos processos de migração descritos neste documento no tutorial complementar.

Visão geral

Migrar um banco de dados MySQL para outro ambiente exige que você mova dois elementos:

  • Os dados no banco de dados. Esta é a camada de armazenamento do banco de dados.
  • O sistema de gerenciamento que processa leituras e gravações consistentes na camada de armazenamento. Esta é a camada de gerenciamento.

O desafio é que esses elementos precisam estar constantemente sincronizados para que o banco de dados funcione. Mesmo um pequeno banco de dados pode receber milhares de solicitações por segundo. Qualquer atraso nas transações ou problemas de rede entre as camadas de armazenamento e gerenciamento terão consequências negativas no banco de dados, nos aplicativos dependentes e na satisfação do usuário.

Métodos de migração

O MySQL tem dois recursos que podem ajudar você a migrar para o Cloud SQL. Esses recursos são a base para duas estratégias de migração de bancos de dados MySQL: migração por exportação/importação e migração por promoção da réplica externa.

Migração por exportação/importação

Na estratégia de exportação/importação, exporte todos os dados na camada de armazenamento do banco de dados de origem usando o comando mysqldump do MySQL. Em seguida, importe esses dados diretamente para uma nova camada de gerenciamento de banco de dados. Isso normalmente requer tempo de inatividade do banco de dados durante toda a migração para manter todos os dados sincronizados.

Migração por promoção da réplica externa

Na estratégia de migração por promoção da instância de réplica externa, você cria uma réplica de banco de dados externa e sincroniza os dados atuais com essa réplica. Isso pode acontecer com tempo de inatividade mínimo do banco de dados atual.

Quando você tem um banco de dados de réplica, os dois bancos de dados têm papéis diferentes mencionados neste documento como primário e réplica.

Depois que os dados são sincronizados, você promove a réplica para ser a principal a fim de mover a camada de gerenciamento com impacto mínimo no tempo de atividade do banco de dados.

No Cloud SQL, uma maneira fácil de realizar a promoção da réplica externa é usar o fluxo de trabalho de migração automatizada. Esse processo automatiza muitas das etapas necessárias para esse tipo de migração.

Como preparar qualquer banco de dados MySQL para migração

Antes de executar as etapas de migração, você precisa garantir que o banco de dados esteja preparado para qualquer uma das opções. O MySQL é instalado com algumas configurações padrão e pode ser ajustado e personalizado de acordo com os requisitos do aplicativo. Antes de iniciar uma migração, verifique se o MySQL está configurado conforme descrito nesta seção. Isso ajuda a reduzir o risco de falha na migração e a limitar o tempo de inatividade.

Executar um backup lógico

Com qualquer um dos métodos de migração, você fará alterações no seu banco de dados MySQL. Para proteger os dados no banco de dados, antes de executar qualquer ação de migração, use o comando mysqldump do MySQL para criar uma exportação de dados que você mantém como backup. Esse backup é usado como ponto de partida para os dois métodos de migração.

O comando mysqldump tira um snapshot de todos os dados no banco de dados. Dependendo do tamanho do banco de dados, esse processo pode levar de menos de um segundo a várias horas. Se forem feitas alterações nos dados depois que o snapshot for capturado, essas alterações não serão capturadas no snapshot final. Se você estiver usando o processo de migração por promoção da réplica externa, isso não será uma preocupação. No entanto, para o processo de migração por exportação/importação, isso pode causar inconsistências e perda de dados.

Armazene o backup completo em um local seguro. As opções incluem o Cloud Storage, um sistema de armazenamento de objetos local, e backups externos.

Realizar um comparativo de mercado das métricas de desempenho do banco de dados

Antes de iniciar qualquer migração, você precisa ter uma coleção completa de comparativos de mercado referentes ao desempenho do aplicativo e do banco de dados atuais. Isso permite que você entenda o comportamento esperado e as métricas de desempenho atuais.

Verifique se as referências que você tem representam os casos de uso dos seus apps e do seu banco de dados. Posteriormente, quando você usar os comparativos de mercado para comparar o desempenho do banco de dados migrado, faça comparações significativas entre as implantações de banco de dados antigas e novas.

Determinar suas opções de conectividade

Os requisitos de conectividade de rede são diferentes para cada estratégia de migração. A pergunta mais importante para ajudar você a decidir qual método usar é se seu banco de dados pode ser acessado usando um endereço IPv4 público.

Quando você executa uma migração por promoção da réplica externa usando o fluxo de trabalho de migração automatizada do Cloud SQL, o banco de dados atual precisa estar acessível publicamente usando um endereço IPv4. O banco de dados de destino no Cloud SQL requer uma conexão de rede permanente durante todo o processo de promoção ou migração. Dependendo do tamanho do banco de dados, esse processo pode ser longo.

Considere também as opções de conectividade no banco de dados de destino. O Cloud SQL pode usar endereços IP particulares. Também é possível configurá-lo para usar a conectividade de IP público.

Determinar sua senha raiz

Durante a migração, você executa muitos comandos e tarefas do MySQL com privilégios. Portanto, você precisa ter acesso ao usuário root do MySQL ou a uma conta com os privilégios SUPER e GRANT. Se você não souber o nome de usuário e a senha de uma dessas contas com privilégios, consulte os administradores do banco de dados ou siga os procedimentos de redefinição de senha (em inglês) do MySQL.

Executar uma migração de teste e criar um runbook

Antes de realizar uma migração de produção, faça migrações de teste. Isso permite que você verifique suas etapas, ganhe confiança nos métodos e preveja o tempo necessário para a migração. É possível usar as lições aprendidas com essa experiência para gerar um runbook (em inglês) que atenda à sua migração. Use o runbook como um documento de trabalho para respaldar a coordenação, solução de problemas e execução da migração.

Este documento pode servir como base para a criação do seu runbook de migração de banco de dados.

Como preparar o aplicativo para uma migração de banco de dados

A última etapa é preparar seu aplicativo para a migração. A discussão de todos os métodos de conexão do aplicativo com o banco de dados não está no escopo deste documento. No entanto, é importante entender como os endereços IP e a conectividade do Sistema de Nome de Domínio (DNS, na sigla em inglês) afetam seu aplicativo.

O uso de DNS público ou interno é um método comum para acessar um banco de dados. O uso do DNS permite que o endereço IP subjacente do banco de dados de destino seja alterado sem uma atualização no código do aplicativo. Se seu aplicativo depende de registros DNS para conectividade de banco de dados, normalmente você reduz os valores de time-to-live (TTL) do DNS desses registros para a migração.

Os valores de TTL do DNS são medidos em segundos e representam a validade de um registro DNS armazenado em um cliente ou host. Esse tempo também é conhecido como uma janela de cache DNS. Os valores de TTL do DNS padrão são diferentes para cada provedor de DNS. Por exemplo, o Cloud DNS define o TTL por padrão como 5 minutos (300 segundos). Como as entradas DNS do banco de dados raramente mudam, o administrador do DNS pode ter definido isso como um valor muito maior.

Quando você migra o banco de dados, se os TTLs do DNS estiverem altos, isso poderá prolongar a inatividade do banco de dados se os clientes tiverem um valor de DNS armazenado em cache. Ao reduzir o valor do TTL, você força os clientes a verificar com mais frequência os registros atualizados. Essa ação ajuda a reduzir o tempo de inatividade do banco de dados.

Antes de fazer alterações nos registros DNS do banco de dados, defina esse número com o menor valor configurável possível. Se seu provedor de DNS for baseado em SaaS, isso poderá aumentar os custos. Verifique com seu provedor ou administrador antes de fazer essa alteração.

Migração por exportação/importação

A estratégia de migração por exportação/importação depende do comando mysqldump do MySQL para exportar um snapshot lógico do banco de dados do ambiente de origem. Em seguida, importe o snapshot para o banco de dados do ambiente de destino.

A simplicidade desse método é compensada pelo fato de que o banco de dados apresenta inatividade durante a migração. Como as transações ocorrem continuamente em grandes bancos de dados, os administradores geralmente fazem o seguinte:

  1. Desativam a capacidade do banco de dados de origem de gravar novos dados.
  2. Criam o snapshot com base no banco de dados de origem.
  3. Importam o snapshot para o banco de dados de destino.
  4. Atualizam a configuração do aplicativo para apontar para o novo banco de dados.
  5. Verificam o desempenho no novo banco de dados.

No diagrama a seguir, ilustramos essa sequência:

Sequência de migração de um banco de dados MySQL local para uma exportação de arquivos para o Cloud Storage, para o MySQL em execução no Cloud SQL

Essa sequência garante que nenhuma alteração seja feita nos dados entre o momento em que você interrompe as gravações no banco de dados de origem e o momento em que inicia as gravações no novo banco de dados. Dependendo do tamanho dos dados, esse processo pode resultar em tempo de inatividade prolongado para o aplicativo. Isso geralmente é inaceitável para muitas empresas e aplicativos.

Quando você usa a estratégia de migração por exportação/importação, o banco de dados não precisa de conectividade externa com o Cloud SQL. No entanto, você precisa exportar os arquivos mysqldump para um local acessível pelo Cloud SQL. Dependendo do tamanho do arquivo mysqldump, esse processo de importação/exportação de dados pode levar muito tempo e pode exigir técnicas complexas de cópia e verificação de arquivos para garantir que todas as linhas de dados e todas as informações da transação sejam copiadas corretamente.

Além disso, as regras de classificação de dados da sua organização podem afetar a capacidade de armazenar os arquivos mysqldump em outros locais. Consulte essas regras antes de escolher qualquer método de armazenamento de dados.

Passo a passo da migração por exportação/importação

Nas seções a seguir, apresentamos detalhes sobre cada uma das etapas da sequência geral.

Desativar gravações

O administrador configura o banco de dados para evitar operações de gravação. Isso também é chamado de bloqueio ou congelamento do banco de dados. Depois disso, qualquer transação de gravação enviada ao banco de dados falhará. No entanto, todas as transações de leitura no banco de dados ou nas réplicas continuam funcionando normalmente. Execute algumas consultas de teste para verificar esse comportamento antes de avançar para as outras etapas.

Entenda quais aplicativos podem ser afetados pelo bloqueio do banco de dados. Talvez seja necessário notificar usuários, clientes, administradores e outros departamentos que dependem do banco de dados para evitar uma falha maior do sistema.

Exportar dados

Depois que o banco de dados for bloqueado, execute o comando mysqldump no banco de dados antigo para produzir uma exportação completa dos dados. Quando o processo de exportação é concluído, esse arquivo precisa ser movido para um local onde possa ser acessado pelo novo banco de dados.

Envie arquivos de backup para uma unidade física separada da que contém o banco de dados de produção. Essa separação reduz a contenção de E/S do disco e pode aumentar a velocidade do backup. Remover a carga de gravação da unidade principal diminui o efeito nas operações do banco de dados de produção. Essa separação também reduz a chance de ficar sem espaço no disco que contém o banco de dados de produção.

A compactação da saída do comando mysqldump também pode ajudar a reduzir o número total de gravações necessárias para o backup. A compactação pode exigir recursos de CPU maiores. Portanto, verifique como isso pode afetar o desempenho da camada de gerenciamento do banco de dados.

Para mais informações, consulte Como exportar dados para importação no Cloud SQL.

Importar dados

O novo banco de dados precisa importar o arquivo dump do banco de dados antigo. O processo de importação recria as tabelas do banco de dados e todas as linhas do banco de dados antigo. O tempo necessário para uma importação é comparável ao tempo necessário para a exportação, considerando recursos semelhantes do sistema. Se você estiver fazendo upgrade dos recursos do sistema como parte da migração, o processo de importação poderá ser mais rápido do que a exportação.

Para mais informações, consulte Como importar dados para o Cloud SQL.

Depois que os dados forem importados, revise as informações de desempenho do comparativo de mercado que você recebeu ao testar o banco de dados de origem. Em seguida, execute consultas de produção baseadas em leitura no novo banco de dados para garantir que ele atenda às necessidades de desempenho dos aplicativos.

Atualizar aplicativos

Quando estiver pronto para começar a usar o novo banco de dados, você precisará atualizar seus aplicativos para oferecer suporte ao novo banco de dados. Há alguns métodos para realizar essa tarefa:

  • Se o aplicativo tiver o endpoint do banco de dados ou o endereço IP definido diretamente no código-fonte, atualize o código e implante essa atualização em todos os aplicativos que precisam acessar o banco de dados.
  • Se o aplicativo apontar para um registro DNS para acessar o banco de dados, atualize o registro DNS por meio do provedor de DNS para refletir o novo endereço de endpoint do banco de dados.
  • Se o aplicativo apontar para um balanceador de carga para acessar o banco de dados, registre o novo endpoint do banco de dados com o balanceador de carga.

Quando você transfere seus aplicativos para usar o Cloud SQL, convém aquecer o pool do buffer (em inglês). Isso ajuda a minimizar a latência de consulta que seus aplicativos podem ter antes que o banco de dados armazene dados na memória. É possível usar o registro de consulta lenta (em inglês) do MySQL do banco de dados de produção de origem para criar um script a fim de executar todas as instruções SELECT que preencherão o cache na nova instância. Faça isso antes de ativar as gravações.

Há muitas ferramentas de terceiros e parceiros que podem ajudar a aquecer o pool do buffer.

Ativar gravações

Depois de verificar se o código do aplicativo atualizado pode se comunicar com o novo banco de dados, você precisa remover o bloqueio somente leitura no novo banco de dados. Após essa etapa, é possível verificar a função correta do banco de dados por meio do aplicativo. Execute também outra rodada de testes de comparativo de mercado para garantir que o desempenho do banco de dados ainda atenda às necessidades do aplicativo.

Ao concluir a verificação e determinar que todos os dados são consistentes entre os dois bancos de dados, é possível concluir algumas tarefas de limpeza:

  • Notifique os usuários de que o tempo de inatividade acabou.
  • Atualize as páginas de status e remova todas as mensagens de status do aplicativo.
  • Reverta todos os TTLs de DNS modificados aos valores originais.

Práticas sugeridas para otimizar o tempo de importação para migrações por exportação/importação

Há várias coisas que podem ser feitas para ajudar a acelerar a importação de um arquivo mysqldump. Isso, por sua vez, reduz o tempo total que um servidor precisa permanecer em um estado somente leitura.

  • Otimize seu esquema. Estruture seus dados para evitar chaves estrangeiras. Se possível, exporte os dados na ordem de chave primária.
  • Otimize seus recursos. Se possível, inicie o novo banco de dados com RAM suficiente para atender a todo o conjunto de dados. Além disso, o uso de SSDs para o armazenamento do banco de dados pode aumentar muito a capacidade dos dados. Os SSDs permitem mais operações de entrada/saída por segundo (IOPS, na sigla em inglês) do que os discos físicos. Os SSDs do Google Cloud também aumentam as IOPS à medida que o tamanho do disco aumenta. Isso significa que pode valer a pena o custo extra e o espaço provisionado em excesso de um disco maior para ter mais IOPS.
  • Otimize o monitoramento. Ter uma solução de monitoramento robusta para detectar problemas com o banco de dados antigo ou novo pode ser extremamente útil em uma migração. Por exemplo, é possível usar o Cloud Monitoring e o plug-in MySQL. O Monitoring permite detectar problemas antecipadamente, identificar o comportamento normal do banco de dados e comparar o novo banco de dados com o valor de referência anterior.

Como exportar e importar bancos de dados grandes

O processo mysqldump funciona rapidamente em bancos de dados com menos de 10 GB. Importar bancos de dados com mais de 10 GB pode exigir que você use estratégias avançadas para minimizar a quantidade de inatividade do banco de dados durante a transição final.

Exportar o esquema e os dados em subseções

Uma estratégia é exportar o esquema e os dados do banco de dados em seções, sem chaves secundárias. Isso permite que você adicione as chaves secundárias usando instruções ALTER TABLE no final da migração. Usando essa abordagem, você exporta diferentes conjuntos de tabelas para arquivos distintos com base nas relações de chave. Em seguida, execute os processos de importação do MySQL em paralelo de uma instância do Compute Engine. Uma maneira de exportar dados para importação paralela é editar manualmente os próprios arquivos de exportação. No entanto, isso pode ser demorado e propenso a erros.

Aproveitar os carimbos de data/hora

Se qualquer uma das tabelas usar colunas de carimbo de data/hora, use um recurso do comando mysqldump que permite especificar uma cláusula WHERE (em inglês). Isso permite que você carregue dados com carimbo de data/hora no Cloud SQL em várias importações.

Quando estiver pronto para a transição final da migração, use essa técnica para exportar somente as linhas no banco de dados de origem que foram alteradas desde a última exportação. Se você não tiver tabelas com carimbo de data/hora e quiser inserir uma coluna de carimbo de data/hora no banco de dados de origem, adicione um gatilho MySQL a cada tabela de origem para definir o carimbo de data/hora sempre que uma linha for alterada.

Uma preocupação com esse método é rastrear linhas excluídas. A coluna de carimbo de data/hora rastreia apenas as linhas que foram alteradas por meio das instruções INSERT ou UPDATE. As linhas excluídas são removidas da tabela. Portanto, o uso de um carimbo de data/hora para encontrar linhas que foram excluídas após a migração inicial só funcionará se o aplicativo e o banco de dados tiverem sido criados para usar um mecanismo de exclusão reversível. Nesta técnica, em vez de emitir uma instrução DELETE, você define uma coluna is_deleted como verdadeira para indicar que uma linha foi excluída. Como alternativa, é possível criar uma tabela para rastrear linhas excluídas de cada uma de suas tabelas reais e um gatilho on_delete correspondente que insere linhas excluídas na tabela de rastreamento de exclusão. Durante a fase final da migração, é possível criar as instruções DELETE necessárias para remover essas linhas da instância do Cloud SQL.

Como validar seus arquivos de exportação

Sempre que você modificar seus arquivos de exportação manualmente ou exportar tabelas diferentes, verifique se os dados foram exportados com acurácia.

Comparação de arquivos de exportação

Uma maneira de validar os dados exportados é implementar um banco de dados de teste inativo. Crie um banco de dados de teste inativo restaurando um backup de produção recente para uma nova instância de banco de dados independente. Em seguida, você restaura o arquivo mysqldump para o novo banco de dados de teste inativo. Em seguida, é possível testar o procedimento mysqldump em várias fases e restaurá-lo em paralelo a outro banco de dados de teste inativo. Isso fornecerá duas cópias idênticas do banco de dados. Para verificar os dados, execute o comando mysqldump nos dois bancos de dados de teste inativos e compare os três usando um comando diff ou uma ferramenta de comparação de arquivos.

No diagrama a seguir, ilustra essa sequência e mostramos os artefatos criados durante o processo.

Sequência e artefatos para validar arquivos de exportação

Promoção de réplica externa

A segunda opção para migrar seu banco de dados MySQL é usar uma promoção de réplica externa. Nesta estratégia, você cria um banco de dados de réplica e define o banco de dados atual como principal. Aguarde até que os dois bancos de dados estejam sincronizados e promova o banco de dados de réplica do MySQL para principal. Esse processo minimiza o tempo de inatividade do banco de dados relacionado à migração do banco de dados.

Pré-requisitos

O uso do método de migração por promoção da réplica externa requer dois pré-requisitos extras: criar um usuário de replicação e ativar a replicação GTID.

Estabelecer um usuário de replicação

Certas versões do MySQL, incluindo a versão 5.7 (usada para os exemplos neste documento), armazenam o nome de usuário e a senha de qualquer conta de usuário usada para replicação em texto simples nos registros do banco de dados principal. Se você usa sua conta de usuário do root para executar a replicação, está armazenando a senha do root nos registros de texto simples. Portanto, o uso do usuário root para replicação representa um risco de segurança.

Para ajudar a limitar a possibilidade de comprometer outros aspectos do banco de dados, crie uma conta completamente separada para executar a replicação. A nova conta precisa ter apenas os privilégios necessários (em inglês) para o processo de replicação. Essa conta também precisa ser limitada para permitir a replicação somente do endereço IP do banco de dados principal.

Configurar o GTID

Seu banco de dados de origem precisa ter a replicação GTID ativada (em inglês) para realizar uma migração por promoção da réplica externa. Se você não tiver configurado a replicação no banco de dados de origem, talvez a replicação GTID não esteja ativada.

Um identificador de transação global (GTID, na sigla em inglês) (em inglês) é um identificador exclusivo associado a cada transação confirmada no servidor de banco de dados principal. Esses identificadores são usados para criar o processo de replicação entre uma réplica e um banco de dados principal.

Novas instâncias do Cloud SQL para MySQL usam a replicação GTID por padrão. Não é possível desativar esse recurso e, portanto, determinadas instruções e operações SQL não são permitidas. Para mais informações, leia as Diferenças entre o Cloud SQL e a funcionalidade do MySQL padrão e as restrições do MySQL na replicação com GTIDs (em inglês).

Visão geral da migração por promoção da réplica externa

Em comparação com uma migração por exportação/importação, a migração por promoção da réplica externa pode ser significativamente mais fácil. O Cloud SQL pode ajudar a automatizar esse processo se você tiver concluído todos os pré-requisitos descritos anteriormente. O fluxo de trabalho de migração automatizada ainda requer um processo de exportação/importação, mas abstrai algumas das etapas manuais como parte da automação.

O fluxo de trabalho de migração automatizada é compatível com os seguintes cenários:

  • Migração do local para o Cloud SQL
  • Migração de outro provedor de nuvem para o Cloud SQL
  • Migração de um projeto do Google Cloud para outro

Durante o fluxo de trabalho de migração automatizada, faça o seguinte:

  1. Forneça detalhes sobre sua fonte de dados.
  2. Crie uma réplica de leitura do Cloud SQL.
  3. Sincronize a réplica de leitura com a origem.
  4. Promova a réplica de leitura do Cloud SQL para ser a instância principal.

Fornecer detalhes sobre sua fonte de dados

Ao executar o fluxo de trabalho de migração automatizada com o Cloud SQL, você fornece um nome de referência para a fonte de dados. Esse nome é usado para se referir aos dados na migração e não precisa corresponder ao nome real da sua origem.

Você também fornece o endereço IP público e a porta do banco de dados de origem. Você precisa garantir que o banco de dados do Cloud SQL tenha conectividade direta com o banco de dados de origem usando um endereço IPv4. Também é necessário garantir que todos os firewalls ou dispositivos de segurança que protegem o banco de dados de origem estejam configurados para permitir a conectividade do novo endereço IP do banco de dados do Cloud SQL.

Você também precisa fornecer o fluxo de trabalho de migração automatizada com suas credenciais de usuário de replicação do MySQL e com a versão do MySQL que você quer migrar. Isso é necessário para autenticação com o servidor e para oferecer suporte a uma transferência segura na próxima etapa. Também é possível configurar as opções de SSL/TLS conforme necessário.

Criar uma réplica de leitura do Cloud SQL

Ao executar o fluxo de trabalho de migração automatizada, você define opções para criar a nova instância do Cloud SQL no Google Cloud. Isso requer algumas etapas:

  • Definição de um ID de instância de banco de dados.
  • Escolha de uma região e zona do Google Cloud.
  • Seleção de um tipo de instância.
  • Seleção do tipo de armazenamento em disco.
  • Escolha da capacidade total de armazenamento. Recomendamos ativar os aumentos automáticos de armazenamento. Essa opção permite que o banco de dados aumente conforme necessário e reduz o risco de ficar sem espaço em disco.

Por fim, você fornece um link para o snapshot armazenado no Cloud Storage. Verifique se você tem os arquivos de exportação mais recentes em um bucket do Cloud Storage que esteja no mesmo projeto que a instância do Cloud SQL.

Sincronizar a réplica de leitura com a origem

Depois de iniciar o processo de migração, a nova VM do Cloud SQL é iniciada e começa a replicar da origem. Quando a sincronização for concluída, será possível comparar os dados no banco de dados para confirmar que a replicação foi concluída. Também é possível iniciar um comparativo de mercado para testar o desempenho do banco de dados do Cloud SQL em relação aos requisitos do aplicativo e ao desempenho do banco de dados de origem com o valor de referência medido anteriormente.

Promover a réplica de leitura para ser a instância principal

Quando os dados são replicados, você coloca o banco de dados antigo no modo somente leitura. Isso evita gravações no banco de dados e garante que os dados não sejam alterados durante o processo de promoção. Em seguida, atualize o código do aplicativo ou as entradas DNS para oferecer suporte ao novo endpoint no Cloud SQL, conforme descrito anteriormente.

Quando o banco de dados de origem estiver no modo somente leitura e o aplicativo tiver sido atualizado com o novo endereço de endpoint do Cloud SQL, acesse a nova instância de banco de dados no Cloud SQL e promova a réplica para ser o servidor principal. Esse processo de promoção reativa automaticamente as gravações no servidor principal do Cloud SQL recém-promovido.

Depois que você promover a réplica para ser o servidor principal, o banco de dados poderá sofrer vários minutos de inatividade, seja qual for o tamanho do banco de dados. Esse é o tempo necessário para que o Cloud SQL realize todas as tarefas e o trabalho de configuração envolvidos na promoção do banco de dados.

Quando a promoção é concluída, o banco de dados principal é executado no Cloud SQL e a migração é concluída. Este é um bom momento para executar outro conjunto de testes de desempenho em relação aos requisitos do aplicativo e ao desempenho do valor de referência do banco de dados de origem. Quando você tem o novo conjunto de comparativos de mercado de desempenho do Cloud SQL, pode planejar outras otimizações de banco de dados.

Como otimizar após a migração

Quando a migração for concluída, seja qual for o método de migração, será possível otimizar o banco de dados do Cloud SQL das seguintes maneiras:

  • Dimensione a VM corretamente. Ao analisar os dados de monitoramento, é possível ver se precisa escolher uma VM de tamanho diferente para o banco de dados. Talvez seja possível reduzir custos usando uma instância menor. Por outro lado, seu banco de dados pode ter um desempenho melhor em uma VM maior com mais recursos.
  • Adicione outros índices. Se o banco de dados puder se beneficiar de outros índices ou de outras otimizações (em inglês), será possível adicioná-los depois de concluir a migração.
  • Ative a geração de registros extras transacionais. Se você explorar o nível de geração de registros do servidor (em inglês), poderá avaliar os benefícios de ativar a geração de registros binários ou outras opções de geração de registros avançadas.
  • Para o método de migração por promoção da réplica externa, reative a geração de registros binários e aproveite os backups automáticos. Após a migração de promoção de réplica, os backups automáticos do Cloud SQL serão desativados porque a geração de registros binários está desativada.

A seguir