Migrar da AWS para o Google Cloud: migrar do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL

Last reviewed 2024-08-16 UTC

O Google Cloud oferece ferramentas, produtos, orientação e serviços profissionais para migrar do Amazon Relational Database Service (RDS) ou do Amazon Aurora para Cloud SQL para MySQL.

Este documento é destinado a administradores de nuvem e de banco de dados que querem planejar, implementar e validar um projeto de migração de banco de dados. Ele também é destinado a tomadores de decisões que estão avaliando a oportunidade de migrar e querem conhecer explorar um exemplo de migração.

Este documento se concentra em uma migração homogênea do banco de dados, que é uma migração em que os bancos de dados de origem e de destino usam a mesma tecnologia. Neste guia de migração, a origem é o Amazon RDS ou o Amazon Aurora para MySQL, e o destino é o Cloud SQL para MySQL.

Este documento faz parte de uma série com várias partes sobre migração da AWS para o Google Cloud que inclui os seguintes documentos:

• Primeiros passos
• Migrar do Amazon EC2 para o Compute Engine
• Migrar do Amazon S3 para o Cloud Storage
• Migrar do Amazon EKS para o GKE
• Migrar do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL (este documento)
• Migrar do Amazon RDS para SQL Server para o Cloud SQL para SQL Server

Para essa migração para o Google Cloud, recomendamos que você siga o framework de migração descrito em Migrar para o Google Cloud: primeiros passos.

No diagrama a seguir, veja o caminho da sua jornada de migração.

É possível migrar do seu ambiente de origem para o Google Cloud em uma série de iterações. Por exemplo, é possível migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral:

1. Avaliar e descobrir suas cargas de trabalho e seus dados.
2. Planejar e criar uma base no Google Cloud.
3. Migrar suas cargas de trabalho e seus dados para o Google Cloud.
4. Otimizar seu ambiente do Google Cloud.

Para mais informações sobre as fases desse framework, consulte Migrar para o Google Cloud: primeiros passos.

Para elaborar um plano de migração eficaz, recomendamos que você valide cada etapa do plano e use uma estratégia de reversão. Para ajudar você a validar o plano de migração, consulte Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração.

Avaliar o ambiente de origem

Na fase de avaliação, você determina os requisitos e as dependências para migrar seu ambiente de origem para o Google Cloud.

A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa saber seu ponto de partida para planejar e executar uma migração do Google Cloud.

A fase de avaliação consiste nas tarefas a seguir:

1. Criar um inventário abrangente das suas cargas de trabalho.
2. Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
3. Treine e instrua suas equipes no Google Cloud.
4. Criar experimentos e provas de conceito no Google Cloud.
5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
6. Escolha a estratégia de migração para suas cargas de trabalho.
7. Escolha as ferramentas de migração.
8. Defina o plano e o cronograma de migração.
9. Valide seu plano de migração.

A fase de avaliação do banco de dados ajuda você a escolher o tamanho e as especificações da instância do banco de dados de destino do Cloud SQL que corresponde à origem com necessidades de desempenho semelhantes. Preste uma atenção especial ao tamanho do disco e à capacidade de processamento, IOPS e número de vCPUs. As migrações podem apresentar dificuldades ou falhar devido a erros de tamanho da instância do banco de dados de destino. O dimensionamento incorreto pode levar um tempo maior de execução da imigração, problemas de desempenho do banco de dados, erros de banco de dados e problemas de de desempenho do aplicativo. Ao decidir sobre a instância do Cloud SQL, o desempenho do disco deve ser baseado no tamanho dele e no número de vCPUs.

As seções a seguir dependem de Migrar para o Google Cloud: avaliar e descobrir suas cargas de trabalho e integram as informações desse documento.

Criar um inventário das suas instâncias do Amazon RDS ou Amazon Aurora

Para definir o escopo da migração, crie um inventário e colete informações sobre suas instâncias do Amazon RDS ou do Amazon Aurora. Recomendamos que você automatize esse processo usando ferramentas especializadas, porque as abordagens manuais são propensas a erros e podem levar a suposições incorretas.

O Amazon RDS ou o Amazon Aurora e o Cloud SQL podem não ter recursos semelhantes, especificações de instâncias ou operações. Algumas funcionalidades podem ser implementadas de maneira diferente ou se tornarem indisponíveis. Áreas de diferença podem incluir infraestrutura, armazenamento, autenticação e segurança, replicação, backup, alta disponibilidade, modelo de capacidade de recursos e recurso específico do mecanismo de banco de dados de integrações e extensões. Dependendo do tipo de mecanismo de banco de dados, a instância o tamanho e a arquitetura, há também diferenças nos valores padrão de configurações de parâmetros do banco de dados.

A comparação pode ajudar você a entender melhor as cargas de trabalho que serão migradas e contribuirão para definir a arquitetura correta para o ambiente de destino da migração. A coleta de informações sobre o desempenho é importante para estimar as necessidades de desempenho do ambiente de destino do Google Cloud. Os conceitos e as ferramentas de comparação estão detalhados na Fase Executar teste e validação do processo de migração, mas também se aplicam à etapa de criação de inventário.

Ferramentas para avaliações

Para uma avaliação geral inicial da infraestrutura atual, recomendamos o Google Cloud Migration Center e outras ferramentas especializadas de avaliação de banco de dados, como migVisor e Database Migration Assessment Tool (DMA).

Com o Migration Center, é possível fazer uma avaliação completa do cenário de aplicativos e bancos de dados, incluindo a adequação técnica para uma migração de bancos de dados para o Google Cloud. Você recebe as recomendações de tamanho e a configuração de todos os bancos de dados de origem e cria um custo total de propriedade (TCO) para servidores e bancos de dados.

Para mais informações sobre como avaliar o ambiente da AWS usando o Migration Center, consulte Importar dados de outros provedores de nuvem.

Além do Migration Center, use a ferramenta especializada migVisor. O migVisor suporta uma variedade de mecanismos de banco de dados e é especialmente adequado para migrações heterogêneas. Para uma introdução ao migVisor, consulte a Visão geral do migVisor.

O migVisor identifica artefatos e recursos do banco de dados reservados e incompatíveis que podem causar problemas para a migração e aponta para soluções alternativas. Ele também recomenda uma solução de destino do Google Cloud, incluindo o dimensionamento inicial e a arquitetura.

A saída da avaliação do banco de dados do migVisor oferece o seguinte:

• Descoberta e análise abrangentes de implantações de banco de dados atuais.
• Um relatório detalhado da complexidade da migração, com base nos recursos reservados usados pelo seu banco de dados.
• Relatório financeiro com detalhes sobre economias de custos pós-migração, custos de migração e um novo orçamento operacional.
• Plano de migração em fases para mover bancos de dados e aplicativos associados com uma interrupção mínima dos negócios.

Para ver alguns exemplos de resultados de avaliação, consulte migVisor: ferramenta de avaliação de migração para a nuvem.

O migVisor aumenta temporariamente a utilização do servidor de banco de dados. Normalmente, essa carga adicional é menor que 3% e pode ser executada fora dos horários de pico.

O resultado da avaliação do migVisor ajuda a criar um inventário completo das instâncias de RDS. O relatório inclui propriedades genéricas (versão do mecanismo de banco de dados e edição, CPUs e tamanho de memória), além de detalhes sobre a topologia do banco de dados, políticas de backup, configurações de parâmetros e personalizações especiais em uso.

Se preferir usar ferramentas de código aberto, use scripts de coletor de dados com (ou no lugar) das ferramentas mencionadas. Esses scripts podem ajudar você a coletar informações de dados detalhadas (cargas de trabalho, recursos, objetos e códigos do banco de dados) e criar o inventário do banco de dados. Além disso, os scripts geralmente fornecem uma avaliação de migração de banco de dados detalhada, incluindo uma estimativa de esforço de migração.

Recomendamos a ferramenta de código aberto DMA, desenvolvida pelos engenheiros do Google. Ela oferece uma avaliação de banco de dados completa e precisa, incluindo recursos em uso, lógica e objetos de banco de dados (como esquemas, tabelas, visualizações, funções, gatilhos e procedimentos armazenados).

Para usar a DMA, faça o download dos scripts de coleta do mecanismo de banco de dados no Repositório Git, e siga as instruções. Envie os arquivos de saída para a análise do Google Cloud. O Google Cloud cria e entrega uma leitura de avaliação de banco de dados e apresenta as próximas etapas da jornada de migração.

Identificar e documentar o escopo da migração e o tempo de inatividade acessível

Nesta fase, você documenta informações essenciais que influenciam a estratégia e as ferramentas de migração. Até agora, você já pode responder às seguintes perguntas:

• Os bancos de dados têm mais de 5 TB?
• Há alguma tabela grande no banco de dados? Elas têm mais de 16 TB?
• Onde estão localizados os bancos de dados (regiões e zonas) e qual é a proximidade deles com os aplicativos?
• Com que frequência os dados mudam?
• Qual é o modelo de consistência de dados?
• Quais são as opções dos bancos de dados de destino?
• Qual é a compatibilidade dos bancos de dados de origem e destino?
• Os dados precisam estar em locais físicos?
• Há dados que podem ser compactados e arquivados ou que não precisam ser migrados?

Para definir o escopo da migração, decida quais dados manter e quais dados migrar. Migrar todos os bancos de dados pode exigir tempo e esforço consideráveis. Alguns dados podem permanecem nos backups do banco de dados de origem. Por exemplo, tabelas de geração de registros antigas ou ou dados de arquivos podem não ser necessários. Também é possível transferir dados após o processo de migração, dependendo de suas estratégias e ferramentas.

Estabeleça os valores de referência de migração de dados para comparar e avaliar os resultados e os impactos. Essas linhas de base são pontos de referência que representam o estado dos dados antes e depois da migração e ajudam a tomar decisões. É importante fazer medições no ambiente de origem para avaliar o sucesso da migração de dados. Essas medições incluem o seguinte:

• O tamanho e a estrutura dos dados.
• A integridade e consistência dos dados.
• A duração e o desempenho das transações comerciais mais importantes e os processos.

Determine quanto tempo de inatividade você pode pagar. Quais são os impactos comerciais do tempo de inatividade? Há períodos de baixa atividade do banco de dados, em que há menos usuários afetados pela inatividade? Em caso afirmativo, qual é a duração desses períodos e quando eles ocorrerem? Considere ter um tempo de inatividade somente para gravação parcial, enquanto as solicitações de somente leitura ainda são atendidas.

Avaliar seu processo de implantação e administração

Depois de criar os inventários, avalie o desempenho de processos do banco de dados para determinar como eles precisam ser adaptados para facilitar a migração. Esses processos são fundamentais para a maneira como você se prepara e mantém o ambiente de produção.

Considere como concluir as seguintes tarefas:

• Definir e aplicar políticas de segurança para as instâncias: por exemplo, talvez seja necessário substituir o Amazon Security Groups. É possível usar os papéis do Google IAM, regras de firewall de VPC e o VPC Service Controls para controlar o acesso às instâncias do Cloud SQL e restringir dados em uma VPC.

• Corrigir e configurar as instâncias: ferramentas de implantação atuais que talvez precisem ser atualizadas. Por exemplo, talvez você esteja usando a configuração personalizada em grupos de parâmetros ou grupos de opções da Amazon. Talvez seja necessário adaptar as ferramentas de provisionamento para usar o Google Cloud Storage ou o Secret Manager para ler essas listas de configuração personalizadas.

• Gerenciar a infraestrutura de monitoramento e alertas: as categorias de métricas das instâncias do banco de dados de origem da Amazon oferecem observabilidade durante o processo de migração. As categorias de métricas podem incluir o Amazon CloudWatch, insights de desempenho, monitoramento avançado e listas de processos de SO.

Concluir a avaliação

Depois de criar os inventários do ambiente do Amazon RDS ou Amazon Aurora, conclua o restante das atividades da fase de avaliação, conforme descrito em Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho.

Planejar e criar sua base

Na fase de planejamento e criação, você provisiona e configura a infraestrutura para fazer o seguinte:

• Oferecer suporte às cargas de trabalho no ambiente do Google Cloud.
• Conectar os ambientes de origem e do Google Cloud para concluir a migração.

A fase de criação e planejamento é composta pelas seguintes tarefas:

1. Criar uma hierarquia de recursos.
2. Configurar o Identity and Access Management (IAM) do Google Cloud.
3. configurar o faturamento
4. Configurar a conectividade de rede.
5. Aumentar sua segurança.
6. Configurar a geração de registros, o monitoramento e os alertas.

Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: planeje e crie sua base.

Se você planeja usar o Database Migration Service para migração, consulte Métodos de rede para MySQL para entender as configurações de rede disponíveis nos cenários de migração.

Monitoramento e alertas

Usar o Google Cloud Monitoring que inclui painéis predefinidos para vários produtos do Google Cloud, como um painel de monitoramento do Cloud SQL. Também é possível usar soluções de monitoramento de terceiros integradas ao Google Cloud, como o Datadog e o Splunk. Para mais informações, consulte Sobre a observabilidade do banco de dados

Migrar instâncias do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL

Para migrar as instâncias, faça o seguinte:

1. Escolha a estratégia de migração: replicação contínua ou programada de manutenção.

2. Escolha as ferramentas de migração, dependendo da estratégia e ou requisitos.

3. Defina o plano de migração e o cronograma para cada migração de banco de dados incluindo tarefas de preparação e execução.

4. Defina as tarefas de preparação que precisam ser realizadas para garantir o funcionamento correto da migração.

5. Defina as tarefas de execução, incluindo as atividades de trabalho que implementam a migração.

6. Defina cenários substitutos para cada tarefa de execução.

7. Realize testes e validações que podem ser feitos em um ambiente de teste separado.

8. Execute a migração.

9. Execute a transferência da produção.

10. Limpe o ambiente de origem e configure a instância de destino.

11. Realize ajustes e a otimização.

Cada fase é descrita nas seções a seguir.

Escolher sua estratégia de migração

Nesta etapa, você tem informações suficientes para avaliar e selecionar uma das estratégias de migração que melhor se adapta ao caso de uso de cada banco de dados:

• Manutenção programada (também chamada de migração única): essa abordagem é ideal se você puder passar um tempo de inatividade. Essa opção é relativamente menor em custo e em complexidade, porque as cargas de trabalho e os serviços não vão exigir muita refatoração. No entanto, se a migração falhar antes da conclusão, você vai precisar reiniciar o processo, o que prolonga o tempo de inatividade.

• Replicação contínua (também chamada de migração de truque): para bancos de dados fundamentais, essa opção oferece um risco menor de perda de dados e quase zero tempo de inatividade. Os esforços são divididos em vários blocos, então, se ocorrer uma falha, a reversão e a repetição levam menos tempo. No entanto, a configuração é mais complexa e requer mais planejamento e tempo. Também é possível refatorar os aplicativos que se conectam ao banco de dados do Compute Engine. Considere uma das seguintes variações:

  • Use a abordagem em Y (gravação e leitura), que é uma forma de migração paralela, duplicando os dados nas duas origens e as instâncias de destino durante a migração.
  • Use um microsserviço de acesso a dados, que reduz o esforço de refatoração exigido pela abordagem em Y (gravação e leitura).

Para mais informações sobre estratégias de migração de dados, consulte Avaliação de abordagens de migração de dados.

O diagrama a seguir mostra um fluxograma com base em exemplos de perguntas que podem surgir ao decidir a estratégia de migração para um único banco de dados:

O fluxograma anterior mostra os seguintes pontos de decisão:

• Você pode ter um período de inatividade?

  • Se a resposta for não, adote a estratégia de migração de replicação contínua.
  • Em caso afirmativo, prossiga para o próximo ponto de decisão.

• É possível arcar com o tempo de inatividade representado por uma janela de transferência durante a migração dos dados? A janela de transferência representa a quantidade de tempo para fazer o backup do banco de dados, transferi-lo para o Cloud SQL, restaurá-lo e, em seguida, migrar os aplicativos.

  • Se a resposta for não, adote a estratégia de migração de replicação contínua.
  • Em caso afirmativo, adote a estratégia de migração de manutenção programada.

As estratégias podem variar para diferentes bancos de dados, mesmo quando estão localizadas na mesma instância. Uma combinação de estratégias pode produzir os melhores resultados. Por exemplo, migrar bancos de dados pequenos e pouco utilizados utilizando a abordagem de manutenção programada, mas a replicação contínua é necessária para bancos de dados fundamentais, em que o tempo de inatividade é caro.

Normalmente, uma migração é considerada concluída quando ocorre a mudança entre a instância de origem inicial e instância de destino. Qualquer replicação (se usada) é interrompida, e todas as leituras e gravações são feitas na instância de destino. Alternar quando as duas instâncias estão sincronizadas significa que não há perda de dados e o tempo de inatividade é mínimo.

Para mais informações sobre estratégias e implantações de migração de dados, consulte Classificação de migrações de banco de dados e Estratégias de implantação.

Minimizar o tempo de inatividade e os impactos relacionados à migração

As configurações de migração que não geram um tempo de inatividade do aplicativo exigem uma configuração complicada. Encontre o equilíbrio certo entre a complexidade da configuração e o tempo de inatividade programado durante os horários de funcionamento de baixo tráfego.

Todas as estratégias de migração têm vantagens e impactos associados ao processo de migração. Por exemplo, os processos de replicação envolvem uma carga adicional nas instâncias de origem e os aplicativos podem ser afetados pelos atrasos da replicação. Os aplicativos (e os clientes) podem ter que aguardar durante o tempo de inatividade do aplicativo, pelo menos enquanto o atraso da replicação durar antes de usar o novo banco de dados. Na prática, os fatores a seguir podem aumentar o tempo inatividade:

• As consultas de banco de dados podem levar alguns segundos para serem concluídas. No momento da migração, as consultas em andamento podem ser canceladas.
• O cache pode levar algum tempo para ser preenchido se o banco de dados for grande ou tem uma memória de buffer substancial.
• Aplicativos interrompidos na origem e reiniciados no Google Cloud podem ter um pequeno atraso até que a conexão com a instância do banco de dados do Google Cloud seja estabelecida.
• As rotas de rede para os aplicativos precisam ser redirecionadas. Dependendo de como as entradas DNS estão configuradas, isso pode levar algum tempo. Ao atualizar os registros DNS, reduza o TTL antes da migração.

As práticas comuns a seguir podem ajudar a minimizar a inatividade e o impacto:

• Encontre um período em que o tempo de inatividade tenha um impacto mínimo nas cargas de trabalho. Por exemplo, fora do horário de funcionamento normal, durante fins de semana ou e outras janelas de manutenção programadas.
• Identifique as partes das cargas de trabalho que podem passar pela migração e pela transferência de produção em diferentes estágios. Os aplicativos podem ter componentes diferentes que podem ser isolados, adaptados e migrados sem impacto. Por exemplo, front-ends, módulos de CRM, serviços de back-end e plataformas de geração de relatórios. Esses módulos podem ter bancos de dados, que podem ser programado para migração mais cedo ou mais tarde durante o processo.
• Se for possível ter um pouco de latência no banco de dados de destino, implemente uma migração gradual. Use transferências de dados incrementais e em lote e adapte parte das cargas de trabalho para trabalhar com dados desatualizados na instância de destino.
• Refatore os aplicativos para oferecer suporte a qualquer impacto mínimo da migração. Por exemplo, adapte os aplicativos para salvar nos bancos de dados de origem e de destino e, portanto, implemente uma replicação no nível do aplicativo.

Escolher as ferramentas de migração

O fator mais importante para uma migração bem-sucedida é escolher o caminho da ferramenta de migração. Depois que a estratégia de migração for decidida, reflita e escolha a ferramenta de migração.

Há muitas ferramentas disponíveis, cada uma otimizada para determinados casos de uso de migração. Os casos de uso podem incluir:

• Estratégia de migração (manutenção programada ou replicação contínua).
• Mecanismos de banco de dados de origem e destino e versões do mecanismo.
• Ambientes em que as instâncias de origem e de destino estão localizadas.
• Tamanho do banco de dados. Quanto maior o banco de dados, mais tempo leva para migrar o backup inicial.
• Frequência das mudanças no banco de dados.
• Disponibilidade para usar serviços gerenciados na migração.

Para garantir a migração e a transferência perfeitas, use os padrões de implantação de aplicativos, a orquestração de infraestrutura e os aplicativos de migração personalizados. No entanto, ferramentas especializadas, chamadas de serviços de migração gerenciados, podem facilitar o processo de migração de dados, aplicativos ou até mesmo infraestruturas inteiras de um ambiente para outro. Elas executam a extração de dados dos bancos de dados de origem, transportam dados com segurança para os bancos de dados de destino e podem modificar os dados durante o trânsito. Com esses recursos, elas encapsulam a lógica complexa da migração e oferecem recursos de monitoramento da migração.

Os serviços de migração gerenciados oferecem as seguintes vantagens:

• Minimizar o tempo de inatividade: os serviços usam os recursos de replicação integrados dos mecanismos de banco de dados quando disponíveis e realizam a promoção de réplicas.

• Garantir a integridade e a segurança de dados: os dados são seguros e transferidos de maneira confiável do banco de dados de origem para o destino.

• Oferecer uma experiência de migração consistente: diferentes técnicas e padrões de migração podem ser consolidados em uma interface comum e consistente usando executáveis de migração de banco de dados, que você pode gerenciar e monitorar.

• Oferecer modelos de migração resilientes e comprovados: migrações de banco de dados são eventos pouco frequentes, mas fundamentais. Para evitar erros banais e problemas com as soluções atuais, use ferramentas de especialistas, em vez de criar uma solução personalizada.

• Otimizar custos: os serviços de migração gerenciados podem ter um custo mais eficaz do que provisionar mais servidores e recursos para as soluções de migração personalizadas.

As próximas seções descrevem as recomendações da ferramenta de migração, de acordo com a estratégia de migração escolhida.

Ferramentas para migrações de manutenção programadas

O diagrama a seguir mostra um fluxograma com perguntas que podem ajudar você a escolher a ferramenta de migração de um único banco de dados, ao usar uma estratégia de migração de manutenção programada:

O fluxograma anterior mostra os seguintes pontos de decisão:

• Você prefere serviços de migração gerenciados?
  • Em caso afirmativo, recomendamos o uso do Database Migration Service.
  • Caso contrário, recomendamos a migração usando os backups integrados do mecanismo de banco de dados.

O uso do serviço de migração gerenciado tem algumas vantagens, que são discutidas na seção Escolher as ferramentas de migração deste documento.

As subseções a seguir descrevem as ferramentas que podem ser usadas para migrações individuais, além de suas limitações e práticas recomendadas.

Database Migration Service para migração de manutenção programada

O Database Migration Service gerencia a sincronização inicial e a replicação contínua de captura de dados alterados (CDC) e fornece o status da operação de migração.

Ao usar o Database Migration Service, é possível criar jobs de migração que podem ser gerenciados e verificados. Recomendamos que você use o Database Migration Service porque ele oferece suporte a migrações para Cloud SQL para MySQL por meio de jobs de migração únicos. Para bancos de dados grandes, use o paralelismo de despejo de dados no Database Migration Service.

Para mais informações sobre a arquitetura de migração de bancos de dados e o Database Migration Service, consulte Migrar um banco de dados para o Cloud SQL para MySQL usando o Database Migration Service e Fidelidade da migração para o MySQL.

Para mais informações sobre as limitações e os pré-requisitos do Database Migration Service, consulte o seguinte:

• Limitações conhecidas no Database Migration Service.
• Cotas e limites no Database Migration Service.
• Configure a origem no Database Migration Service.

Backups de mecanismo de banco de dados integrados

Quando um tempo de inatividade significativo é aceitável e seus bancos de dados de origem estão relativamente estáticos, é possível usar o recurso de despejo e carregamento integrados do mecanismo do banco de dados (também chamados de backup e restauração).

A configuração e a sincronização podem levar algum tempo, especialmente para um grande número de bancos de dados, mas os backups do mecanismo de banco de dados geralmente estão disponíveis e são fáceis de usar.

Os backups do mecanismo de banco de dados têm as seguintes limitações gerais:

• Os backups podem estar propensos a erros, especialmente se forem feitos manualmente.
• Os dados não estarão protegidos se os backups não forem gerenciados adequadamente.
• Os backups não têm recursos de monitoramento adequados.
• É necessário esforço para escalonar se muitos bancos de dados estiverem sendo migrados usando essa ferramenta.

Se você escolher essa abordagem, considere as seguintes limitações e práticas recomendadas:

• Se o banco de dados for relativamente pequeno (menos de 10 GB), recomendamos o uso de mysqldump. Não há um limite fixo, mas o tamanho ideal do banco de dados para mysqldump geralmente é menor que 10 GB.

• Se você importar bancos de dados com mais de 10 GB, talvez seja necessário usar outras estratégias para minimizar o tempo de inatividade do banco de dados. Algumas dessas estratégias são as seguintes:

  • Exporte o esquema e os dados em subseções, sem chaves secundárias.
  • Aproveite os carimbos de data/hora. Se alguma das tabelas usar colunas de carimbo de data/hora, você pode usar um recurso do comando mysqldump que permite especificar uma cláusula WHERE para filtrar por uma coluna de carimbo de data/hora.
  • Considere outras abordagens, como o uso das ferramentas mydumper e myloader.

Os despejos e os backups do banco de dados geralmente não incluem contas de usuário do MySQL. Ao se preparar para migrar, revise todas as contas de usuário na instância de origem. Por exemplo, é possível executar o comando SHOW GRANTS para que cada usuário revise o conjunto atual de privilégios e veja se há algum que seja restrito no Cloud SQL Da mesma forma, a ferramenta pt-show-grants do Percona também pode listar concessões.

As restrições nos privilégios de usuário no Cloud SQL podem afetar as migrações ao migrar objetos de banco de dados que têm um atributo DEFINER. Por exemplo, um procedimento armazenado pode ter um definidor muito privilegiado para executar comandos SQL, como alterar uma variável global que não é permitida no Cloud SQL. Para casos como esse, pode ser necessário reescrever o código de procedimento armazenado ou migrar objetos que não sejam de tabela (como procedimentos armazenados, como uma etapa de migração separada). Para mais informações, consulte Práticas recomendadas para importação e exportação de dados.

Para mais informações sobre limitações e práticas recomendadas, consulte as páginas a seguir:

• Cloud SQL para MySQL sobre usuários.
• Práticas recomendadas para importar e exportar dados com o Cloud SQL para MySQL.
• Problemas conhecidos do Cloud SQL para MySQL.

Outras abordagens para a migração com manutenção programada

Como parte do uso de uma importação gerenciada para configurar a replicação de um banco de dados MySQL externo, há um carregamento inicial de dados do banco de dados externo para a instância do Cloud SQL. Essa abordagem usa um serviço que extrai dados do servidor externo (a instância do RDS neste caso) e a importa para a instância do Cloud SQL diretamente.

Para bancos de dados grandes (vários TB), uma maneira mais rápida é usar uma carga inicial de importação personalizada que usa as ferramentas mydumper e myloader.

Você pode exportar as tabelas do seu banco de dados MySQL para arquivos CSV, que podem ser importados para o Cloud SQL para MySQL. Para exportar dados da sua instância do RDS, use o AWS Database Migration Service (AWS DMS) e um bucket do S3 como destino.

Para informações e etapas detalhadas, consulte Usar uma importação gerenciada para configurar a replicação de bancos de dados externos.

Ferramentas para migrações de replicação contínuas

O diagrama a seguir mostra um fluxograma com perguntas que podem ajudar você a escolher a ferramenta de migração de um banco de dados, ao usar uma replicação contínua da estratégia de migração:

O fluxograma anterior mostra os seguintes pontos de decisão:

• Você prefere usar serviços de migração gerenciados?

  • Se sim, você pode ter alguns segundos de inatividade de gravação, dependendo do número de tabelas no banco de dados?

    • Em caso afirmativo, use o Database Migration Service.
    • Em caso negativo, veja outras opções de migração.

  • Caso contrário, avalie se a replicação integrada do mecanismo de banco de dados é compatível:

    • Em caso afirmativo, recomendamos o uso da replicação integrada.
    • Se a resposta for não, recomendamos outras opções de migração.

As seções a seguir descrevem as ferramentas que podem ser usadas para migrações contínuas, junto com as limitações e as práticas recomendadas.

Database Migration Service para migração de replicação contínua

O Database Migration Service oferece suporte contínuo para migrações contínuas usando o uso de jobs contínuos de migração. Somente jobs contínuos de migração podem ser promovidos, o que sinaliza para que a replicação seja interrompida.

Se escolher essa ferramenta, considere as seguintes restrições e práticas recomendadas:

• Evite transações de longa duração durante a migração. Nesses casos, recomendamos a migração de uma réplica de leitura se você não estiver migrando do AWS Aurora.
• Para acessar uma lista completa de limitações, consulte Limitações conhecidas.

Replicação integrada do mecanismo de banco de dados

A replicação integrada do mecanismo de banco de dados é uma opção alternativa ao Database Migration Service para uma migração contínua.

A replicação do banco de dados representa o processo de copiar e distribuir dados de um banco de dados chamado de banco de dados primário para outros bancos de dados chamados réplicas. O objetivo é aumentar a acessibilidade dos dados e melhorar a tolerância a falhas e a confiabilidade de um sistema de banco de dados. Embora a migração de banco de dados não seja o objetivo principal da replicação de banco de dados, ela pode ser usada como uma ferramenta para alcançar essa meta. A replicação do banco de dados é geralmente um processo contínuo que ocorre em tempo real à medida que os dados são inseridos, atualizados ou excluídos do banco de dados principal. Isso pode ser feito como uma operação única ou uma sequência de operações em lote.

A maioria dos mecanismos modernos de banco de dados implementa maneiras diferentes de acessar a replicação de bancos de dados. Um tipo de replicação pode ser alcançado copiando e enviando o registro prévio de escrita ou registro de transações do primário para as réplicas. Essa abordagem é chamada de replicação física ou binária. Outros tipos de replicação funcionam distribuindo as instruções SQL brutas que um banco de dados principal recebe, em vez de replicar as mudanças no nível do sistema de arquivos.

O Cloud SQL oferece suporte à replicação para MySQL. No entanto, existem alguns pré-requisitos e limitações.

Pré-requisitos:

• Verifique se você está usando MySQL 5.5, 5.6, 5.7 ou 8.0 no Amazon RDS ou Amazon Aurora.
• Verifique se os registros binários estão ativados.
• Para acelerar a fase inicial de despejo completo, escolha uma máquina grande o suficiente da perspectiva do tamanho da CPU e da memória.
• Se você precisar acelerar a fase CDC, tente configurar a replicação paralela e ativar limpeza de alto desempenho.
• Se a réplica do Cloud SQL estiver ativada com endereços IP internos porque o endereço IP de saída não é estático, configure o firewall do servidor Amazon RDS ou Amazon Aurora para permitir o intervalo de IP interno alocado para o acesso a serviços particulares da rede VPC que a réplica do Cloud SQL usa como rede particular. Para mais informações, consulte Sobre a replicação de um servidor externo e Configurar o acesso a serviços particulares.

Limitações:

• Se você tem tabelas grandes únicas e muitos índices secundários no seu banco de dados, o despejo completo inicial pode demorar mais.
• Se o servidor externo tiver cláusulas DEFINER (visualizações, eventos, gatilhos ou procedimentos armazenados), dependendo da ordem de quando essas instruções são executadas, a replicação poderá falhar. Saiba mais sobre o uso de DEFINER e as possíveis soluções alternativas no Cloud SQL.
• O InnoDB é o único mecanismo de banco de dados suportado no Cloud SQL. A migração do MyISAM pode causar inconsistência nos dados e exigir validação de dados. Consulte Como converter tabelas do MyISAM para o InnoDB.

Outras abordagens para migração de replicação contínua

Outras abordagens para migração de replicação contínua incluem:

• Refatorar os aplicativos para executar Y (gravação e leitura) ou usar um microsserviço de acesso a dados.

  • A replicação contínua é realizada pelos seus aplicativos.
  • O esforço de migração tem como foco a refatoração ou o desenvolvimento de ferramentas que se conectam às instâncias do banco de dados.
  • Os aplicativos leitores são gradualmente refatorados e implantados para usar a instância de destino.

• Use o Datastream para replicar mudanças quase em tempo real da sua instância do MySQL.

  • O Datastream é um serviço de replicação e CDC sem servidor que pode ser usado com o Amazon RDS ou o Amazon Aurora para replicar e sincronizar dados.
  • Use o Datastream para replicar alterações da sua instância do MySQL para BigQuery ou Cloud Storage e depois usar o Dataflow ou Dataproc para colocar os dados na sua instância do Cloud SQL.

Para mais informações sobre a replicação com o Datastream, consulte:

• Configurar um banco de dados do Amazon RDS para MySQL no Datastream
• Configurar um banco de dados MySQL do Amazon Aurora no Datastream
• Transmitir alterações nos dados em tempo real com o Datastream

Ferramentas de terceiros para migração de replicação contínuas

Em alguns casos, pode ser melhor usar uma ferramenta de terceiros para a maioria dos mecanismos de bancos de dados Esses casos podem ocorrer se você preferir usar um serviço de migração gerenciado e precisar garantir que o banco de dados de destino esteja sempre em sincronização quase em tempo real com a origem ou se precisar de transformações mais complexas, como limpeza, reestruturação e adaptação de dados durante o processo de migração.

Se decidir usar uma ferramenta de terceiros, escolha uma das seguintes opções recomendadas que podem ser usadas para a maioria dos mecanismos de banco de dados.

O Striim é uma plataforma completa na memória, para coletar, filtrar, transformar, enriquecer, agregar, analisar e entregar dados em tempo real:

• Vantagens:

  • Processamento de grandes volumes de dados e migrações complexas.
  • Captura de dados alterados integrada do SQL Server.
  • Modelos de conexão pré-configurados e pipelines sem código.
  • Capacidade de lidar com grandes bancos de dados essenciais que operam sob uma grande carga transacional.
  • Entrega exatamente uma vez.

• Desvantagens:

  • Não é código aberto.
  • Pode se tornar caro, principalmente para migrações longas.
  • Algumas limitações na propagação de operações de linguagem de definição de dados (DDL, na sigla em inglês). Para mais informações, consulte Operações DDL compatíveis e Observações e limitações da evolução do esquema.

Para saber mais sobre o Striim, consulte Como executar o Striim no Google Cloud.

Debezium é uma plataforma distribuída de código aberto para CDC que transmite alterações de dados para assinantes externos:

• Vantagens:

  • Código aberto.
  • Forte suporte da comunidade.
  • Econômico.
  • Controle refinado de linhas, tabelas ou bancos de dados.
  • Especializado na captura de alterações em tempo real de logs de transações de banco de dados.

• Desvantagens:

  • Exige experiência específica com Kafka e ZooKeeper.
  • Entrega de alterações de dados pelo menos uma vez, o que significa que você precisa lidar com duplicatas.
  • Configuração de monitoramento manual usando Grafana e Prometheus.
  • Não há suporte para replicação incremental em lote.

Para saber mais sobre as migrações do Debezium, consulte Replicação de dados quase em tempo real usando o Debezium.

O Fivetran é uma plataforma automatizada de movimentação de dados para transferir dados para fora e entre plataformas de dados em nuvem.

• Vantagens:

  • Modelos de conexão pré-configurados e pipelines sem código.
  • Propague todas as mudanças de esquema da origem para o banco de dados de destino.
  • Entrega de alterações de dados exatamente uma vez, o que significa que você não precisa lidar com duplicatas.

• Desvantagens:

  • Não é código aberto.
  • O suporte a transformações complexas de dados é limitado.

Definir o plano e o cronograma de migração

Para uma migração bem-sucedida do banco de dados e uma transferência da produção, recomendamos a preparação de um plano de migração abrangente e bem definido. Para reduzir o impacto nos seus negócios, recomendamos criar uma lista com todos os itens de trabalho necessários.

Definir o escopo da migração revela as tarefas de trabalho que precisam ser realizadas antecipadamente, durante e após o processo de migração do banco de dados. Por exemplo, se decidir não migrar determinadas tabelas de um banco de dados, pode ser necessário uma pré-migração ou tarefas pós-migração para implementar essa filtragem. Você também garante que a migração do banco de dados não afeta o contrato de nível de serviço (SLA) e o plano de continuidade de negócios.

Recomendamos que a documentação de planejamento da migração inclua os seguintes documentos:

• Documento de projeto técnico (TDD)
• Matriz RACI
• Cronograma (como um plano T-minus)

As migrações de banco de dados são um processo iterativo, e as primeiras migrações costumam ser mais lentas do que as posteriores. Normalmente, migrações bem planejadas ocorrem sem problemas, mas problemas não planejados ainda podem surgir. Recomendamos que você sempre tenha um plano de reversão. Como prática recomendada, siga as orientações de Migrar para práticas recomendadas do Google Cloud para validar um plano de migração.

TDD

O TDD documenta todas as decisões técnicas a serem tomadas para o projeto. Inclua o seguinte no TDD:

• Requisitos e importância dos negócios
• Objetivo do tempo de recuperação (RTO)
• Objetivo do ponto de recuperação (RPO)
• Detalhes da migração do banco de dados
• Estimativas do esforço de migração
• Recomendações de validação da migração

Matriz RACI

Alguns projetos de migração exigem uma matriz RACI, que é um documento comum de gerenciamento de projetos que define quais indivíduos ou grupos são responsáveis por tarefas e entregas no projeto de migração.

Cronograma

Prepare um cronograma para cada banco de dados que precisa ser migrado. Inclua todas as tarefas de trabalho que devem ser realizadas e defina datas de início e término estimadas.

Para cada ambiente de migração, recomendamos que você crie um plano T-minus. Um plano T-minus é estruturado como uma programação de contagem regressiva e lista todas as tarefas necessárias para concluir o projeto de migração, junto com os grupos responsáveis e a duração estimada.

O cronograma precisa considerar não apenas a execução de tarefas de preparação para a pré-migração, assim como tarefas de validação, auditoria ou teste que ocorrem após uma transferência de dados.

A duração das tarefas de migração normalmente depende do tamanho do banco de dados, mas há outros aspectos que devem ser considerados, como complexidade da lógica de negócios, uso e disponibilidade da equipe.

Um plano T-Minus pode ser:

Data	Fase	Categoria	Tarefas	Papel	T-minus	Status
11/1/2023	Pré-migração	Avaliação	Criar relatório de avaliação	Equipe de descoberta	-21	Concluído
11/7/2023	Pré-migração	Preparação do destino	Projetar o ambiente de destino conforme descrito pelo documento de projeto	Equipe de migração	-14	Concluído
11/15/2023	Pré-migração	Governança da empresa	Data da migração e aprovação T-minus	Liderança	-6	Concluído
11/18/2023	Migração	Configurar o DMS	Criar perfis de conexão	Engenheiro de migração para a nuvem	-3	Concluído
11/19/2023	Migração	Configurar o DMS	Criar e iniciar jobs de migração	Engenheiro de migração para a nuvem	-2	Não iniciado
11/19/2023	Migração	Monitorar DMS	Monitorar jobs do DMS e alterações de DDL na instância de origem	Engenheiro de migração para a nuvem	-2	Não iniciado
11/21/2023	Migração	Substituir DMS	Promover réplica do DMS	Engenheiro de migração para a nuvem	0	Não iniciado
11/21/2023	Migração	Validação da migração	Validação da migração de bancos de dados	Equipe de migração	0	Não iniciado
11/21/2023	Migração	Teste de aplicativo	Executar testes de recursos e desempenho	Equipe de migração	0	Não iniciado
22/11/2023	Migração	Governança da empresa	Validação da migração IR ou NÃO IR	Equipe de migração	1	Não iniciado
11/23/2023	Pós-migração	Validar o monitoramento	Configurar o monitoramento	Equipe de infraestrutura	2	Não iniciado
11/25/2023	Pós-migração	Segurança	Remover conta de usuário do DMS	Equipe de segurança	4	Não iniciado

Várias migrações de banco de dados

Para migrar vários bancos de dados, o plano de migração deve conter as tarefas de todas as migrações.

Inicie o processo migrando um bucket menor, um banco de dados não essencial. Essa abordagem pode ajudar você a criar conhecimento e confiança no processo e nas ferramentas de migração. Você também pode detectar falhas no processo nas etapas iniciais do cronograma geral de migração.

Se quiser migrar vários bancos de dados, os cronogramas poderão ser carregados em paralelo. Por exemplo, para acelerar o processo de migração, migre um grupo de bancos de dados pequenos, estáticos ou menos importantes ao mesmo tempo, conforme mostrado no diagrama a seguir.

No exemplo mostrado no diagrama, os bancos de dados 1-4 são um grupo de pequenos bancos de dados migrados ao mesmo tempo.

Definir as tarefas de preparação

As tarefas de preparação são todas as atividades que você precisa fazer para atender aos pré-requisitos de migração. Sem as tarefas de preparação, a migração pode não ocorrer ou os resultados da migração no banco de dados migrado pode se tornar inutilizável.

As tarefas de preparação podem ser categorizadas da seguinte maneira:

• Preparações e pré-requisitos de instâncias do Amazon RDS ou do Amazon Aurora
• Preparação e pré-requisitos do banco de dados de origem
• Configuração do Cloud SQL
• Configuração específica da migração

Preparação e pré-requisitos de instâncias do Amazon RDS ou do Amazon Aurora

Considere as seguintes tarefas comuns de configuração e pré-requisito:

• Dependendo do caminho de migração, talvez seja necessário permitir conexões remotas nas instâncias de RDS. Caso a instância de RDS esteja configurada para ser particular na VPC, a conectividade da RFC 1918 particular entre a Amazon e o Google Cloud precisa existir.

• Talvez seja necessário configurar um novo grupo de segurança para permitir o acesso remoto nas portas necessárias.

  • Por padrão, na AWS, o acesso à rede é ativado para instâncias de banco de dados.
  • É possível especificar regras em um grupo de segurança que permitam o acesso a um intervalo de endereços IP, uma porta ou um grupo de segurança. As mesmas regras se aplicam a todas as instâncias do banco de dados associadas a esse grupo de segurança.

• Verifique se você tem espaço livre em disco suficiente para armazenar em buffer os registros de WAL durante toda a duração da operação de carregamento total na instância do Amazon RDS.

• Para resultados de migração ideais, considere migrar de uma réplica de leitura, a menos que você esteja migrando do Amazon Aurora. Além disso, recomendamos que você inicie o processo de migração durante um período de redução da atividade do banco de dados.

• O MySQL limita o nome do host a 60 caracteres. Os nomes de host do banco de dados do Amazon RDS geralmente têm mais de 60 caracteres. Se esse for o caso do banco de dados que está migrando, configure um redirecionamento de DNS para criar um registro CNAME que associa seu nome de domínio ao nome de domínio da instância do banco de dados do RDS.

• Se você estiver usando a replicação integrada, será necessário configurar a instância do Amazon RDS ou do Amazon Aurora para a replicação. Replicação integrada, ou as ferramentas que a utilizam, precisa da geração de registros binários para MySQL definidos como ROW.

• Se estiver usando ferramentas de terceiros, configurações iniciais geralmente são necessárias antes de usar a ferramenta. Confira a documentação na ferramenta de terceiros.

Para mais informações sobre a preparação da instância e os pré-requisitos, consulte Configure o servidor externo para replicação do MySQL.

Preparação e pré-requisitos do banco de dados de origem

• Se você usar o Database Migration Service, precisará configurar sua origem no banco de dados antes de se conectar a ele. Analisar os jobs de migração antes de implementar os jobs. Para mais informações, consulte Configurar a origem para MySQL.
• Dependendo do mecanismo de banco de dados, talvez seja necessário mudar alguns recursos. Por exemplo, o Cloud SQL para MySQL oferece suporte apenas ao mecanismo de banco de dados InnoDB. Você precisa alterar as tabelas MyISAM para o InnoDB.
• Algumas ferramentas de migração de terceiros exigem que todas as colunas LOB sejam anuláveis. Todas as colunas LOB que são NOT NULL precisam ter essa restrição removida durante a migração.

• Fazer medições de valor de referência no ambiente de origem em uso na produção. Considere o seguinte:

  • Meça o tamanho dos dados e o desempenho da carga de trabalho. Quanto tempo levam em média as consultas ou transações importantes? Quanto tempo elas levam durante os horários de pico?
  • Documente as medidas de valor de referência para comparar posteriormente e determinar se a fidelidade da migração do banco de dados é satisfatória. Decida se é possível migrar as cargas de trabalho de produção e desativar o ambiente de origem ou se você ainda precisa dele para fins de substituição.

Configuração do Cloud SQL

Escolha com cuidado o tamanho e as especificações da instância do banco de dados de do Cloud SQL para MySQL de destino para corresponder à fonte com necessidades de desempenho semelhantes. Preste uma atenção especial ao tamanho do disco e à capacidade de processamento, IOPS e número de vCPUs. O dimensionamento incorreto pode levar a um tempo maior de execução da imigração, problemas de desempenho do banco de dados, erros de banco de dados e problemas de de desempenho do aplicativo.

Confirme as propriedades e os requisitos a seguir antes de criar as instâncias do Cloud SQL, porque elas não podem ser alteradas posteriormente sem recriá-las.

• Escolha o projeto e a região das instâncias de destino do Cloud SQL com cuidado. As instâncias do Cloud SQL não podem ser migradas entre projetos e regiões do Google Cloud sem a transferência de dados.
• Migrar para uma versão principal correspondente no Cloud SQL. Por exemplo, se a origem usa o MySQL 8.0.34 no Amazon RDS ou Amazon Aurora, migre para o Cloud SQL para MySQL versão 8.0.34.
• Replique as informações dos usuários separadamente se você estiver usando o mecanismo de banco de dados integrado ou o Database Migration Service. O Cloud SQL gerencia usuários com serviços do IAM. Para mais detalhes, consulte as limitações na seção Backups do mecanismo de banco de dados integrado.
• Analise as flags de configuração do mecanismo de banco de dados e compare os valores das instâncias de origem e de destino. Entenda os impactos e se eles precisam ser iguais ou não. Por exemplo, recomendamos executar o comando SHOW VARIABLES no seu banco de dados de origem antes da migração e, em seguida, executá-lo novamente no banco de dados do Cloud SQL. Atualize as configurações de flag conforme necessário no no banco de dados do Cloud SQL para replicar as configurações de origem. Nem todas as flags do MySQL são permitidas em uma instância do Cloud SQL.

Para mais informações sobre as configurações do Cloud SQL, consulte:

• Práticas recomendadas gerais para MySQL
• Opções de configuração de instância para MySQL
• Considerações importantes antes da migração do Aurora para o Cloud SQL para MySQL

Configuração específica da migração

Se você importar arquivos dump SQL para o Cloud SQL, talvez seja necessário criar um bucket do Cloud Storage. O bucket armazena o despejo do banco de dados.

Se usar a replicação, a réplica do Cloud SQL deve ter acesso ao banco de dados primário. Esse acesso pode ser feito pelas opções de conectividade documentadas.

Dependendo do cenário e da importância, talvez seja necessário implementar um cenário de fallback, que geralmente inclui a reversão da direção da replicação Nesse caso, um mecanismo de replicação adicional do Cloud SQL de reversão para a instância de origem do Amazon é necessário.

Para a maioria das ferramentas de terceiros, é necessário provisionar recursos específicos de migração. Por exemplo, no caso do Striim, use o Google Cloud Marketplace para começar. Para configurar o ambiente de migração no Striim, use o Flow Designer para criar e alterar aplicativos. Também é possível selecionar um modelo existente. Os aplicativos também podem ser codificados com o uso da linguagem de programação de linguagem de consulta de tungstênio (TQL). Usando um painel de validação de dados, tenha uma representação dos dados processados pelo aplicativo Striim.

É possível desativar os recursos que conectam o ambiente do Google Cloud após a conclusão e a validação da migração.

Para ver mais informações, consulte os seguintes tópicos:

• Gerenciar jobs de migração no Database Migration Service
• Práticas recomendadas para importação e exportação de dados
• Conectividade para MySQL

Definir as tarefas de execução

As tarefas de execução implementam o trabalho de migração. As tarefas dependem da ferramenta de migração escolhida, conforme descrito nas subseções a seguir.

Backups de mecanismo de banco de dados integrados

Para realizar uma migração única, use o utilitário mysqldump para criar um backup, que copia os dados do Amazon RDS para o computador cliente local. Para instruções, consulte Importe um arquivo dump SQL para o Cloud SQL para MySQL.

Você pode verificar o status das operações de importação e exportação para sua instância do Cloud SQL.

Jobs de migração do Database Migration Service

Defina e configure jobs de migração no Database Migration Service para migrar dados de uma instância de origem para o banco de dados de destino. Os jobs de migração se conectam à instância do banco de dados de origem usando perfis de conexão definidos pelo usuário.

Teste todos os pré-requisitos para garantir que o job seja executado corretamente. Escolha quando as cargas de trabalho podem lidar com um pequeno período de inatividade para a migração e a transferência da produção.

No Database Migration Service, a migração começa com o backup e o carregamento completos iniciais, seguido por um fluxo contínuo de mudanças da origem para a instância de banco de dados de destino.

O Database Migration Service requer alguns segundos para conseguir o bloqueio de leitura em todas as tabelas na sua instância de origem do Amazon RDS ou Amazon Aurora que ele precisa para executar o despejo completo inicial de maneira consistente. Para conseguir o bloqueio de leitura, pode ser necessário um tempo de inatividade de gravação de 1 a 49 segundos. A inatividade depende do número de tabelas no banco de dados, sendo que 1 segundo corresponde a 100 tabelas e 9 segundos correspondem a 10 mil tabelas.

O processo de migração com o Database Migration Service termina com a operação de promoção. Promover uma instância de banco de dados desconecta o banco de dados de destino do fluxo de alterações provenientes do banco de dados de origem e, por fim, a instância de destino independente é promovida a instância principal. Essa abordagem também pode ser chamada de switch de produção.

Para mais informações sobre jobs de migração no Database Migration Service, consulte:

• Verificar um job de migração
• Gerenciar jobs de migração
• Promover uma migração

Para acessar um processo detalhado de configuração da migração, consulte Migrar um banco de dados para o Cloud SQL para MySQL usando o Database Migration Service. No Database Migration Service, a migração é realizada iniciando e executando um job de migração.

Replicação integrada do mecanismo de banco de dados

É possível usar a replicação integrada do Amazon RDS para uma instância externa do Cloud SQL para MySQL.

No MySQL, primeiro você precisa começar com um dump inicial que pode ser armazenado em um bucket do Cloud Storage e, em seguida, importar os dados para o Cloud SQL para MySQL. Depois, inicie o processo de replicação.

Monitore a replicação e interrompa as gravações na instância de origem no momento adequado. Verifique o status de replicação novamente para garantir que todas as alterações foram replicadas e, em seguida, promover a réplica do Cloud SQL para MySQL a instância independente para concluir a migração.

Para instruções detalhadas sobre como configurar a replicação integrada de um servidor externo como Amazon RDS ou Amazon Aurora para MySQL, consulte Sobre a replicação a partir de um servidor externo e Configurar o Cloud SQL e o servidor externo para replicação.

Para mais informações e orientações, consulte:

• Exportar seu banco de dados para um bucket do Cloud Storage
• Usar uma importação gerenciada para configurar a replicação de bancos de dados externos
• Iniciar replicação no servidor externo

Ferramentas de terceiros

Defina todas as tarefas de execução para a ferramenta de terceiros escolhida.

Esta seção se concentra no Striim como exemplo. O Striim usa aplicativos que coletam dados de várias fontes, processam os dados e os entregam a outros aplicativos ou destinos.

Aplicativos podem ser criados graficamente usando o cliente da Web. Elescontêm origens, destinos e outros componentes lógicos organizados em um ou mais fluxos.

Para configurar seu ambiente de migração no Striim, use o Designer de fluxo para criar e alterar aplicativos, ou selecione entre vários modelos preexistentes. Os aplicativos também podem ser codificados usando a linguagem de programação TQL.

Você pode ter uma representação visual dos dados processados pelo seu aplicativo Striim usando um painel de validação de dados.

Para começar rapidamente com o Striim no Google Cloud, consulte Como executar o Striim no Google Cloud. Para saber mais sobre os conceitos básicos do Striim, consulte Conceitos do Striim. Leia também o guia de práticas recomendadas Como mudar de uma carga inicial para a replicação contínua.

Considere as seguintes práticas recomendadas para a migração de dados:

• Informe as equipes envolvidas sempre que cada uma das etapas do plano começar e terminar.
• Se alguma das etapas demorar mais do que o esperado, compare o tempo decorrido com a quantidade máxima de tempo alocada para cada etapa. Faça atualizações intermediárias regulares com as equipes envolvidas se isso acontecer.
• Se o período for maior que a quantidade máxima de tempo reservada para cada etapa do plano, considere a reversão.
• Escolha realizar ou não cada etapa da migração e o plano de transferência.
• Considere ações de reversão ou cenários alternativos para cada uma das etapas.

Definir cenários de fallback

Defina ações necessárias de fallback para cada tarefa de execução de migração para se proteger contra imprevistos que podem ocorrer durante o processo de migração. As tarefas de fallback geralmente dependem da estratégia de migração e das ferramentas usadas.

A substituição pode exigir um esforço significativo. A prática recomendada é não realizar a transferência até que os resultados do teste sejam satisfatórios. A migração do banco de dados e o cenário de fallback devem ser testados adequadamente para evitar uma interrupção grave do serviço.

Defina os critérios de sucesso e o tempo de todas as tarefas de execução de migração. Fazer uma simulação da migração ajuda a coletar informações sobre os tempos esperados para cada tarefa. Por exemplo, para uma migração de manutenção programada, é possível obter o tempo de inatividade representado pela janela de transferência. No entanto, é importante planejar sua próxima ação caso o job de migração única ou a restauração do backup falhe no meio do caminho. Dependendo do tempo decorrido do tempo de inatividade planejado, talvez seja necessário adiar a migração se a tarefa de migração não for concluída no tempo esperado.

Um plano de fallback geralmente reverte a migração depois de executar a transferência da produção se houver problemas na instância de destino. Se você implementar um plano de fallback, ele deve ser tratado como uma migração de banco de dados completa, incluindo planejamento e teste.

Se você optar por não ter um plano de fallback, entenda as possíveis consequências. Não ter um plano de fallback pode gerar um esforço imprevisto e causar interrupções evitáveis no processo de migração.

Embora um plano substituto seja um último recurso e a maioria das migrações de banco de dados acabe não usando-o, recomendamos sempre ter uma estratégia de fallback.

Fallback simples

Nessa estratégia de fallback, retorne os aplicativos à instância do banco de dados de origem. Adote essa estratégia se você puder arcar com o tempo de inatividade quando fizer o fallback ou se não precisar que as transações sejam confirmadas no novo sistema de destino.

Se precisar de todos os dados gravados no banco de dados de destino e puder ficar inativo por algum tempo, considere interromper as gravações na instância do banco de dados de destino, fazer backups integrados e restaurá-los na instância de origem e, por fim, reconectar os aplicativos à instância inicial do banco de dados de origem. Dependendo da natureza da carga de trabalho e da quantidade de dados gravados na instância do banco de dados de destino, você pode trazê-los para o sistema de banco de dados de origem inicial posteriormente, especialmente se as cargas de trabalho não dependerem de nenhum horário específico de criação registrado ou de nenhuma restrição de ordenação de tempo.

Replicação reversa

Nessa estratégia, você replica as gravações que ocorrem no novo destino do banco de dados após a transferência da produção retornar ao banco de dados de origem inicial. Dessa maneira, você mantém a fonte original sincronizada com o novo banco de dados de destino e fica com as gravações na nova instância do banco de dados de destino. A principal desvantagem é que não é possível testar o fluxo de replicação até depois de fazer a transferência para a instância do banco de dados de destino. Portanto, não é possível realizar testes completos e você fica um pequeno período sem fallback.

Escolha essa abordagem quando for possível manter a instância de origem por algum tempo e usar a migração de replicação contínua.

Replicação direta

Essa estratégia é uma variação da replicação reversa. Você replica a gravação no novo banco de dados de destino em uma terceira instância do banco de dados de sua escolha. É possível apontar os aplicativos para esse terceiro banco de dados, que se conecta ao servidor e executa consultas somente leitura enquanto o servidor não está disponível. É possível usar qualquer mecanismo de replicação, dependendo das suas necessidades. A vantagem dessa abordagem é que ela pode ser totalmente testada.

Adote essa abordagem para a cobertura de fallback em todos os momentos ou para descartar o banco de dados de origem inicial logo após a operação de transferência.

Escritas duplicadas

Se escolher uma migração de microsserviço de acesso aos dados ou Y (gravação e leitura), essa estratégia já estará definida. Essa estratégia é mais complicada, porque você precisa refatorar os aplicativos ou desenvolver ferramentas que se conectam às instâncias do bancos de dados.

os aplicativos gravam nas instâncias de banco de dados iniciais e de destino; que permitem fazer uma transferência gradual da produção até usar apenas as instâncias do banco de dados de destino. Se ocorrer um erro, conecte os aplicativos de volta à origem assim que perceber. Só descarte a fonte inicial e o mecanismo de gravação duplicado quando considerar que a migração foi realizada sem problemas.

Recomendamos essa abordagem quando for necessário não ter tempo de inatividade na migração, ter um substituto confiável e tiver tempo e recursos para a refatoração dos aplicativos.

Realizar testes e validações

Os objetivos desta etapa são testar e validar:

• A migração dos dados no banco de dados que foi concluída.
• A integração com aplicativos existentes após a mudança para a nova instância de destino.

Defina os principais fatores de sucesso, que estão relacionados à sua migração. Exemplos de fatores subjetivos:

• Quais dados migrar. Para algumas cargas de trabalho, pode não ser necessário migrar todos os dados. Talvez você não queira migrar os dados que já estão agregados, redundantes, arquivados ou são antigos. É possível arquivar esses dados em um bucket do Google Cloud Storage, como um backup.
• Uma porcentagem aceitável de perda de dados. Isso se aplica particularmente aos dados usados para cargas de trabalho analíticas, em que a perda de parte dos dados não afeta as tendências gerais ou o desempenho das cargas de trabalho.
• Critérios de qualidade e quantidade de dados, que podem ser aplicados ao ambiente de origem e comparados com o ambiente de destino após a migração.
• Critérios de desempenho. Algumas transações de negócios podem ser mais lentas no ambiente de destino, mas o tempo de processamento ainda está dentro das expectativas definidas.

As configurações de armazenamento no ambiente de origem podem não ser mapeadas diretamente nos destinos do ambiente do Google Cloud. Por exemplo, as configurações de Volumes SSD de uso geral (gp2 e gp3) com desempenho de burst de IOPS ou SSD de IOPS provisionado. Para comparar e dimensionar corretamente as instâncias de destino, compare as instâncias de origem nas fases de avaliação e validação.

No processo de comparativo de mercado, aplique as sequências de operações semelhantes à produção às instâncias do banco de dados. Durante esse período, capture e processe as métricas para mensurar e comparar o desempenho relativo dos sistemas de origem e de destino.

Para configurações convencionais com base no servidor, use medidas relevantes observadas durante os picos de carga. Para modelos de capacidade de recursos flexíveis, como o Aurora sem servidor, considere analisar dados históricos de métricas para observar o escalonamento necessário.

As seguintes ferramentas podem ser usadas para teste, validação e comparativo de mercado do banco de dados:

• HammerDB: ferramenta de comparativo de mercado e teste de carga de banco de dados de código aberto. Ele é compatível com cargas de trabalho transacionais e analíticas complexas, com base em padrões do setor, em diferentes mecanismos de banco de dados (TPROC-C e TPROC-H). O HammerDB tem uma documentação detalhada e uma grande comunidade de usuários. Ele compartilha e compara resultados de diferentes mecanismos de banco de dados e configurações de armazenamento. Para mais informações, consulte Teste de carga do SQL Server usando o HammerDB e Comparativo de mercado de desempenho do Amazon RDS SQL Server usando o HammerDB.
• Ferramenta de comparativo de mercado do DBT2: comparativo de mercado especializado em MySQL. Um conjunto de kits de carga de trabalho de banco de dados imita um aplicativo para uma empresa que possui armazéns e envolve uma combinação de leitura e gravação de transações. Use essa ferramenta se quiser utilizar um modelo de processamento de transações on-line (OLTP, na sigla em inglês).
• DbUnit: ferramenta de teste de unidade de código aberto usada para testar interações de bancos de dados relacionais no Java. A configuração e o uso são simples e oferecem suporte a diferentes mecanismos de banco de dados (MySQL, PostgreSQL, SQL Server e outros). No entanto, a execução do teste pode às vezes ser lenta, dependendo do tamanho e da complexidade do banco de dados. Recomendamos essa ferramenta quando a simplicidade for muito importante.
• DbFit: framework de testes de banco de dados de código aberto compatível com o código orientado por testes de desenvolvimento e testes automatizados. Ele usa uma sintaxe básica para criar casos de teste e apresenta testes orientados a dados, controle de versões e relatórios de resultados de teste. No entanto, o suporte a consultas e transações complexas é limitado e não tem um grande suporte da comunidade nem uma documentação extensa, em comparação com outras ferramentas. Recomendamos essa ferramenta se as consultas não forem complexas e para realizar testes automatizados e integrá-los ao processo de integração e entrega contínuas.

Para executar um teste completo, incluindo o teste do plano de migração, faça sempre um exercício de simulação de migração. Uma simulação executa a migração do banco de dados de escopo completo sem mudar qualquer carga de trabalho e oferece as seguintes vantagens:

• A migração correta de todos os objetos e configurações.
• Ajuda a definir e executar os casos de teste de migração.
• Oferece insights sobre o tempo necessário para a migração, para que você possa calibrar a linha do tempo.
• Representa uma ocasião para testar, validar e adaptar o plano de migração. Às vezes, não é possível planejar tudo com antecedência, então isso ajuda você a detectar lacunas.

O teste de dados pode ser realizado em um pequeno conjunto de bancos de dados a serem migrados ou de todo o conjunto. Dependendo do número total de bancos de dados e das ferramentas usadas para implementar a migração, você pode decidir adotar uma abordagem baseada em riscos. Com essa abordagem, você realiza a validação de dados em um subconjunto de bancos de dados migrados com a mesma ferramenta, principalmente se for um serviço de migração gerenciado.

Para testes, você deve ter acesso aos bancos de dados de origem e de destino e concluir as seguintes tarefas:

• Comparar esquemas de origem e de destino. Verificar se todas as tabelas e executáveis existem. Verificar contagens de linhas e comparar dados no nível do banco de dados.
• Executar scripts de validação de dados personalizados.
• Testar se os dados migrados também estão visíveis nos aplicativos que migraram para o banco de dados de destino (os dados migrados são lidos pelo aplicativo).
• Realize testes de integração entre os aplicativos migrados e o banco de dados de destino testando vários casos de uso. Esse teste inclui a leitura e a gravação dos dados nos bancos de dados de destino pelo aplicativos. Dessa maneira, as cargas de trabalho aceitam totalmente os dados migrados com os dados recém-criados.
• Teste o desempenho das consultas de banco de dados mais usadas para observar se houve uma degradação devido a configurações incorretas ou dimensionamento incorreto.

O ideal é que todos esses cenários de teste de migração sejam automatizados e repetíveis em qualquer sistema de origem. O pacote de casos de teste automatizados é adaptado para ter um bom desempenho em relação aos aplicativos migrados.

Se estiver usando o Database Migration Service como ferramenta de migração, consulte Verificar uma migração

Ferramenta de validação de dados

Para realizar a validação de dados, recomendamos o uso da Ferramenta de validação de dados (DVT, na sigla em inglês): A DVT é uma ferramenta de CLI Python de código aberto, com o suporte do Google, que fornece uma solução automatizada e repetível para a validação em ambientes diferentes.

A DVT simplifica o processo de validação de dados oferecendo funções de validação multinível para comparar as tabelas de origem e destino em tabelas, colunas e linhas. Também é possível adicionar regras de validação.

A DVT abrange muitas fontes de dados do Google Cloud, como AlloyDB para PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON e CSV no Cloud Storage. Ela também pode ser integrada às funções do Cloud Run e ao Cloud Run para acionamento e orquestração com base em eventos.

A DVT é compatível com os seguintes tipos de validações:

• Comparações no nível do esquema
• Coluna (incluindo "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
• Linha (incluindo hash e correspondência exata em comparações de campo)
• Comparação dos resultados da consulta personalizada

Para mais informações sobre a DVT, consulte o Repositório Git e a Validação de dados facilitada com a ferramenta de validação de dados do Google Cloud.

Faça a migração

As tarefas de migração incluem as atividades para realizar a transferência de um sistema para outro.

Considere as seguintes práticas recomendadas para a migração de dados:

• Informe as equipes envolvidas sempre que uma etapa do plano começar e terminar.
• Se alguma das etapas demorar mais do que o esperado, compare o tempo decorrido com a quantidade máxima de tempo alocada para essa etapa. Faça atualizações intermediárias regulares com as equipes envolvidas se isso acontecer.
• Se o período for maior que a quantidade máxima de tempo reservada para cada etapa do plano, considere a reversão.
• Escolha realizar ou não cada etapa da migração e o plano de transferência.
• Considere ações de reversão ou cenários alternativos para cada uma das etapas.

Faça a migração seguindo as tarefas de execução definidas e consulte a documentação da ferramenta de migração selecionada.

Executar a transferência da produção

O processo de transferência da produção em alto nível pode variar, dependendo estratégia de migração. Se houver inatividade nas cargas de trabalho, a transferência da migração começa com a interrupção das gravações no banco de dados de origem.

Para migrações de replicação contínua, cumpra as seguintes etapas de alto nível no processo de transferência:

• Interrompa a gravação no banco de dados de origem.
• Drene a origem.
• Interrompa o processo de replicação.
• Implante os aplicativos que apontam para o novo banco de dados de destino.

Após migrar os dados com a ferramenta de migração escolhida, valide os dados no banco de dados de destino. Confirme que o banco de dados de origem e os bancos de dados de destino estejam sincronizados e os dados na instância de destino estejam de acordo com os padrões de sucesso da migração escolhidos.

Depois que a validação de dados for aprovada de acordo com seus critérios, é possível realizar a transferência de nível do aplicativo. Implante as cargas de trabalho refatoradas para usar a nova instância de destino. Implante as versões dos aplicativos que apontam para o nova instância do banco de dados de destino. As implantações podem ser realizadas por atualizações graduais, lançamentos em fase de testes ou usando um padrão de implantação azul-verde. Às vezes pode ocorrer a inatividade do aplicativo.

Siga as práticas recomendadas para a transferência da produção:

• Monitore os aplicativos que funcionam com o banco de dados de destino após a transferência.
• Defina um período de monitoramento para avaliar se você precisa implementar o plano de fallback.
• A instância do Cloud SQL ou AlloyDB para PostgreSQL pode precisar reiniciar algumas flags do banco de dados forem alteradas.
• O esforço de reverter a migração pode ser maior do que corrigir os problemas que aparecem no ambiente de destino.

Limpar o ambiente de origem e configurar a instância do Cloud SQL ou AlloyDB para PostgreSQL

Depois que a transferência for concluída, você poderá excluir os bancos de dados de origem. Recomendamos as seguintes ações importantes antes da limpeza da instância de origem:

• Crie um backup final de todos os bancos de dados de origem. Esses backups apresentam o estado final dos bancos de dados de origem. Os backups também podem ser necessários em alguns casos de conformidade com regulamentos de dados.

• Colete as configurações de parâmetros do banco de dados da instância de origem. Outra opção é verificar se elas correspondem aos que você reuniu na fase de criação de inventário. Ajuste os parâmetros da instância de destino para que correspondam à instância de origem.

• Colete as estatísticas do banco de dados na instância de origem e compare-as as estatísticas na instância de destino. Se as estatísticas forem diferentes, é difícil comparar o desempenho das instâncias de origem e de destino.

Em um cenário de fallback, convém implementar a replicação da gravação na instância do Cloud SQL de volta ao banco de dados de origem. A configuração é semelhante ao processo de migração, mas seria executada ao contrário: o banco de dados de origem se tornaria o novo destino.

Como prática recomendada para manter as instâncias de origem atualizadas após a transferência, replique as gravações realizadas nas instâncias do Cloud SQL de destino novamente no banco de dados de origem. Se você precisar reverter, poderá voltar às instâncias de origem antigas com o mínimo de perda de dados.

Além da limpeza do ambiente de origem, é preciso fazer as seguintes configurações críticas para as instâncias do Cloud SQL:

• Configure uma janela de manutenção para a instância principal para controlar quando as atualizações disruptivas podem ser realizadas.
• Configure o armazenamento na instância para ter um espaço de no mínimo 20% disponível para acomodar operações importantes de manutenção do banco de dados que o Cloud SQL possa executar. Para receber um alerta se o espaço disponível em disco ficar abaixo de 20%, crie uma política de alertas com base em métricas para a métrica de utilização do disco.

Não inicie uma operação administrativa antes que a operação anterior seja concluída.

Para mais informações sobre manutenção e práticas recomendadas, consulte Sobre a manutenção em instâncias do Cloud SQL.

Otimizar o ambiente após a migração

A otimização é a última fase da migração. Nesta fase, você repete as tarefas de otimização até que o ambiente de destino atenda aos requisitos de otimização. As etapas de cada iteração são as seguintes:

1. Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
2. Estabeleça suas metas e requisitos de otimização.
3. Otimize o ambiente e as equipes.
4. Ajustar o loop de otimização.

Repita essa sequência até alcançar suas metas de otimização.

Para mais informações sobre como otimizar o ambiente do Google Cloud, consulte Migrar para o Google Cloud: otimizar o ambiente e Processo de otimização de performance.

Estabelecer seus requisitos de otimização

Analise os requisitos de otimização a seguir para o ambiente do Google Cloud e escolha os requisitos que melhor se adaptam às suas cargas de trabalho:

Aumentar a confiabilidade e a disponibilidade do banco de dados

Com o Cloud SQL, é possível implementar uma abordagem de alta disponibilidade e estratégia de recuperação de desastres que se alinham com o objetivo do tempo de recuperação (RTO, na sigla em inglês) e o objetivo do ponto de recuperação (RPO, na sigla em inglês). Para aumentar a confiabilidade e a disponibilidade, considere o seguinte:

• Para cargas de trabalho com muita leitura, adicione réplicas de leitura para descarregar o tráfego da instância principal.
• Para cargas de trabalho essenciais, use a configuração de alta disponibilidade, réplicas de failover regional e uma configuração robusta de recuperação de desastres.
• Para cargas de trabalho menos críticas, criar backups automatizados e sob demanda pode ser suficiente.
• Para evitar a remoção acidental de instâncias, use a proteção de exclusão de instâncias.
• Considere usar o Cloud SQL Enterprise Plus para aproveitar os benefícios do aumento da disponibilidade, da retenção e da manutenção planejada com tempo de inatividade próximo a zero. Para mais informações sobre o Cloud SQL Enterprise Plus, consulte Introdução às edições do Cloud SQL e Manutenção planejada com tempo de inatividade próximo a zero.

Para mais informações sobre como aumentar a confiabilidade e a disponibilidade do seu banco de dados, consulte:

• Promover réplicas para migração regional ou recuperação de desastres
• Recuperação de desastres do banco de dados do Cloud SQL
• Sobre os backups do Cloud SQL
• Documentação sobre como impedir a exclusão de uma instância

Aumentar o custo-benefício da infraestrutura do banco de dados

Para ter um impacto econômico positivo, as cargas de trabalho precisam usar recursos e serviços com eficiência. Considere as seguintes opções:

• Forneça ao banco de dados a capacidade de armazenamento mínima necessária ao:

  • Para escalonar a capacidade de armazenamento automaticamente à medida que os dados aumentam, ative os aumentos automáticos de armazenamento. No entanto, não se esqueça de configurar que as instâncias tenham buffer em cargas de trabalho de pico. As cargas de trabalho do banco de dados as cargas de trabalho costumam a aumentar com o tempo.

• Identifique possíveis recursos superestimados:

  • O redimensionamento das instâncias do Cloud SQL pode reduzir os custos de infraestrutura sem adicionar riscos à capacidade de gerenciamento de projetos.
  • O Cloud Monitoring tem painéis predefinidos que ajudam a identificar a integridade e a utilização da capacidade de muitos componentes do Google Cloud, incluindo o Cloud SQL. Para mais detalhes, consulte Criar e gerenciar painéis personalizados.

• Identifique instâncias que não exigem alta disponibilidade ou configurações de recuperação de desastres e remova-as da infraestrutura.

• Remova tabelas e objetos que não são mais necessários. É possível armazená-los em um backup completo ou em um bucket de arquivamento do Cloud Storage.

• Avalie o tipo de armazenamento mais econômico (SSD ou HDD) para seu caso de uso.

  • Na maioria dos casos de uso, o SSD é mais eficiente e a opção mais econômica.
  • Se os conjuntos de dados forem grandes (10 TB ou mais), não sensíveis à latência ou acessados com pouca frequência, o HDD pode ser mais apropriado.
  • Para mais detalhes, consulte Escolher entre armazenamento SSD e HDD.

• Compre descontos por compromisso de uso para cargas de trabalho com necessidades previsíveis de recursos.

• Use o Active Assist para receber insights e recomendações de custo.

Para mais informações e opções, consulte Faça mais com menos: conheça as recomendações de otimização de custos do Cloud SQL com o Active Assist.

Aumentar o desempenho da infraestrutura do banco de dados

Pequenos problemas de desempenho relacionados ao banco de dados frequentemente podem afetar toda a operação. Para manter e aumentar a performance da instância do Cloud SQL, considere as seguintes diretrizes:

• Se houver um grande número de tabelas do banco de dados, elas podem afetar o desempenho e a disponibilidade das instâncias, além de fazer com que a instância perca a cobertura do SLA.

• Verifique se a instância não está limitada por memória ou CPU.

  • Para cargas de trabalho que exigem alto desempenho, verifique se a instância tem pelo menos 60 GB de memória.
  • Para inserções, atualizações ou exclusões demoradas de banco de dados, verifique os locais do gravador e do banco de dados. O envio de dados por uma longa distância gera latência.

• Melhore o desempenho da consulta usando painéis do Query Insights predefinidos no Cloud Monitoring (ou um mecanismo de banco de dados similar de recursos integrados). Identifique os comandos mais caros e tente otimizá-los.

• Evite o crescimento desnecessário do banco de dados. Defina autogrow em MBs em vez de porcentagem, usando incrementos adequados para o requisito.

• Verifique o local do leitor e do banco de dados. A latência afeta o desempenho de leitura mais do que desempenho de gravação.

• Considere usar a edição Cloud SQL Enterprise Plus para aproveitar os limites de configuração de máquina e o cache de dados maiores. Para mais informações, consulte Introdução às edições do Cloud SQL.

Para mais informações sobre como aumentar o desempenho, consulte Desempenho em "Diagnosticar problemas".

Aumentar os recursos de observabilidade do banco de dados

Diagnosticar e solucionar problemas em aplicativos que se conectam ao banco de dados instâncias pode ser desafiador e demorado. Por isso, um sistema centralizado local em que todos os membros da equipe podem ver o que está acontecendo no banco de dados e na instância é essencial. É possível monitorar instâncias do Cloud SQL das seguintes maneiras:

• O Cloud SQL usa agentes personalizados de memória integrada para coletar a telemetria de consultas.

  • Use o Cloud Monitoring para coletar medidas do seu serviço e do Google Cloud de recursos que você usa.
    • O Cloud Monitoring inclui painéis predefinidos para vários produtos do Google Cloud, como um painel de monitoramento do Cloud SQL.
  • É possível criar painéis personalizados para monitorar métrica. e configurar políticas de alertas para receber notificações oportunas.
  • Também é possível usar soluções de monitoramento de terceiros integradas ao Google Cloud, como o Datadog e o Splunk.

• O Cloud Logging coleta dados de registro de componentes comuns do aplicativo.

• O Cloud Trace coleta dados de latência e planos de consulta executados em aplicativos para ajudar a rastrear como as solicitações se propagam pelo aplicativo.

• Central de banco de dados: fornece uma visão geral da frota do banco de dados centralizado e assistido por IA. É possível monitorar a integridade dos bancos de dados, a configuração de disponibilidade, a proteção de dados, a segurança e a compliance do setor.

Práticas recomendadas e diretrizes operacionais gerais do Cloud SQL

Aplique as práticas recomendadas do Cloud SQL para configurar e ajustar o banco de dados.

Essas são algumas recomendações gerais importantes do Cloud SQL:

• Se você tiver instâncias grandes, recomendamos dividi-las em instâncias menores, quando for possível.
• Configure o armazenamento para acomodar a manutenção crítica do banco de dados. Tenha no mínimo 20% de espaço disponível para acomodar quaisquer operações importantes de manutenção de banco de dados que o Cloud SQL possa executar.
• Ter muitas tabelas de banco de dados pode afetar o tempo de upgrade do banco de dados. O ideal é ter menos de 10 mil tabelas por instância.
• Escolha o tamanho apropriado para as instâncias para contabilizar a retenção de log de transações (binário), especialmente para instâncias com alta atividade de gravação.

Para conseguir lidar com eficiência com qualquer problema de desempenho do banco de dados que você possa encontrar, use as seguintes diretrizes até que o problema seja resolvido:

Ampliar a infraestrutura: aumente os recursos, como a capacidade de processamento do disco, a vCPU e e RAM. Dependendo da urgência, da disponibilidade e da experiência da sua equipe, o escalonamento vertical da instância pode resolver a maioria dos problemas de desempenho. Mais tarde, você pode investigar a causa raiz do problema em um ambiente de teste e considerar opções para eliminá-lo.

Executar e programar operações de manutenção do banco de dados: desfragmentação de índices, atualizações de estatísticas, análise de vácuo e reindexação de tabelas extremamente atualizadas. Verifique se e quando essas operações de manutenção foram realizadas pela última vez, especialmente nos objetos afetados (tabelas e índices). Descubra se houve uma alteração das atividades normais do banco de dados. Por exemplo, adicionar recentemente uma nova coluna ou ter muitas atualizações em uma tabela.

Executar o ajuste e a otimização do banco de dados: as tabelas no banco de dados estão bem estruturadas? As colunas têm os tipos de dados corretos? Esse é o modelo de dados ideal para o tipo de carga de trabalho? Investigue as consultas lentas e os planos de execução. Eles estão usando os índices disponíveis? Verifique se há varreduras de índice, bloqueios e esperas em outros recursos. Considere adicionar índices para oferecer suporte às consultas importantes. Elimine índices não importantes e chaves externas. Considere reescrever consultas e junções complexas. O tempo que leva para resolver o problema depende da experiência e da disponibilidade da equipe e pode variar de horas a dias.

Fazer o escalonamento horizontal das leituras considere ter réplicas de leitura. Quando o dimensionamento vertical não for suficiente para suas necessidades e as medidas de ajuste e otimização do banco de dados não estiverem ajudando, considere o dimensionamento horizontal. Rotear consultas de leitura dos aplicativos para uma réplica de leitura melhora o desempenho geral da carga de trabalho do banco de dados. No entanto, pode ser necessário mais esforço para que os aplicativos se conectem à réplica de leitura.

Rearquitetura do banco de dados: considere particionar e indexar o banco de dados. Essa operação requer significativamente mais esforço do que o ajuste e a otimização do banco de dados e pode envolver a migração de dados, mas pode ser uma solução de longo prazo. Às vezes, um projeto ruim do modelo de dados pode levar a problemas de desempenho, o que pode ser parcialmente compensado pelo escalonamento vertical. No entanto, um modelo de dados adequado é uma solução de longo prazo. Particione as tabelas. Se possível, arquive dados desnecessário. Normalize a estrutura do banco de dados, mas lembre-se: desnormalizar também pode melhorar o desempenho.

Fragmentação do banco de dados: escalone horizontalmente as gravações fragmentando o banco de dados. A fragmentação é uma operação complicada e envolve a rearquitetura do banco de dados e aplicativos de uma forma específica e a execução da migração de dados. Você deve dividir os de banco de dados em várias instâncias menores usando uma regra específica de particionamento. Os critérios podem ser baseados no cliente ou no assunto. Essa opção permite escalonar horizontalmente as gravações e as leituras. No entanto, isso aumenta a complexidade dos bancos de dados e cargas de trabalho. Isso também pode levar a fragmentos desequilibrados, chamados pontos de acesso, que superariam o benefício da fragmentação. - Especificamente para o Cloud SQL para MySQL, verifique se as tabelas têm uma chave primária ou exclusiva. O Cloud SQL usa replicação baseada em linha, que funciona melhor em tabelas com chaves primárias ou exclusivas.

Para mais detalhes, consulte Práticas recomendadas gerais e Diretrizes operacionais do Cloud SQL para MySQL.

A seguir

• Leia sobre outras jornadas de migração da AWS para o Google Cloud.
• Saiba como comparar os serviços da AWS e do Azure com o Google Cloud.
• Saiba quando buscar ajuda para suas migrações.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.

Colaboradores

Autores:

• Alex Cârciu | Arquiteto de soluções
• Marco Ferrari | Arquiteto de soluções de nuvem

Outros colaboradores:

• Derek Downey | Engenheiro de relações com desenvolvedores
• Paweł Krentowski | Redator técnico
• Matthew Smith | Engenheiro de nuvem estratégico
• Paul de Somdyuti | Especialista em gerenciamento de dados
• Zach Seils | Especialista em rede