Migre da AWS para o Google Cloud: migre do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL

Last reviewed 2024-08-16 UTC

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

Este documento destina-se a administradores de bases de dados e da nuvem que querem planear, implementar e validar um projeto de migração de bases de dados. Também se destina aos decisores que estão a avaliar a oportunidade de migrar e querem um exemplo de como pode ser uma migração.

Este documento centra-se numa migração de base de dados homogénea, que é uma migração em que as bases de dados de origem e de destino usam a mesma tecnologia de base de dados. 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 de vários artigos sobre a migração da AWS para a Google Cloud , que inclui os seguintes documentos:

• Comece a usar
• Migre do Amazon EC2 para o Compute Engine
• Migre do Amazon S3 para o Cloud Storage
• Migre do Amazon EKS para o GKE
• Migre do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL (este documento)
• Migre do Amazon RDS e do Amazon Aurora para PostgreSQL para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL
• Migre do Amazon RDS para SQL Server para o Cloud SQL para SQL Server
• Migre do AWS Lambda para o Cloud Run

Para esta migração para Google Cloud, recomendamos que siga a estrutura de migração descrita no artigo Migrar para Google Cloud: introdução.

O diagrama seguinte ilustra o caminho do seu percurso de migração.

Pode migrar do ambiente de origem para o ambiente de destino Google Cloud numa série de iterações. Por exemplo, pode migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, segue as fases da estrutura de migração geral:

1. Avalie e descubra as suas cargas de trabalho e dados.
2. Planeie e crie uma base em Google Cloud.
3. Migre as suas cargas de trabalho e dados para o Google Cloud.
4. Otimize o seu Google Cloud ambiente.

Para mais informações sobre as fases desta estrutura, consulte o artigo Migre para Google Cloud: comece.

Para criar um plano de migração eficaz, recomendamos que valide cada passo do plano e se certifique de que tem uma estratégia de reversão. Para ajudar a validar o seu plano de migração, consulte o artigo Migre para Google Cloud: práticas recomendadas para validar um plano de migração.

Avalie o ambiente de origem

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

A fase de avaliação é fundamental para o sucesso da sua migração. Tem de adquirir conhecimentos profundos sobre as cargas de trabalho que quer migrar, os respetivos requisitos, as respetivas dependências e o seu ambiente atual. Tem de compreender o seu ponto de partida para planear e executar com êxito uma Google Cloud migração.

A fase de avaliação consiste nas seguintes tarefas:

1. Crie um inventário abrangente das suas cargas de trabalho.
2. Catalogue as suas cargas de trabalho de acordo com as respetivas propriedades e dependências.
3. Forme e eduque as suas equipas sobre Google Cloud.
4. Crie experiências e provas de conceito em Google Cloud.
5. Calcular o custo total de propriedade (TCO) do ambiente de destino.
6. Escolha a estratégia de migração para as suas cargas de trabalho.
7. Escolha as ferramentas de migração.
8. Defina o plano de migração e a linha cronológica.
9. Valide o seu plano de migração.

A fase de avaliação da base de dados ajuda a escolher o tamanho e as especificações da instância da base de dados do Cloud SQL de destino que correspondem à origem para necessidades de desempenho semelhantes. Preste especial atenção ao tamanho e ao débito do disco, aos IOPS e ao número de vCPUs. As migrações podem ter dificuldades ou falhar devido ao dimensionamento incorreto da instância da base de dados de destino. O dimensionamento incorreto pode levar a tempos de migração longos, problemas de desempenho da base de dados, erros da base de dados e problemas de desempenho da aplicação. Ao decidir sobre a instância do Cloud SQL, tenha em atenção que o desempenho do disco baseia-se no tamanho do disco e no número de vCPUs.

As secções seguintes baseiam-se no artigo Migrar para Google Cloud: avalie e descubra as suas cargas de trabalho, e integre as informações nesse documento.

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

Para definir o âmbito da migração, crie um inventário e recolha informações sobre as suas instâncias do Amazon RDS ou Amazon Aurora. Recomendamos que automatize este processo através de ferramentas especializadas, uma vez que as abordagens manuais são propensas a erros e podem levar a pressupostos incorretos.

O Amazon RDS ou o Amazon Aurora e o Cloud SQL podem não ter funcionalidades, especificações de instâncias ou operações semelhantes. Algumas funcionalidades podem ser implementadas de forma diferente ou estar indisponíveis. As áreas de diferenças podem incluir infraestrutura, armazenamento, autenticação e segurança, replicação, cópia de segurança, elevada disponibilidade, modelo de capacidade de recursos e integrações de funcionalidades específicas do motor de base de dados e extensões. Consoante o tipo de motor da base de dados, o tamanho da instância e a arquitetura, também podem existir diferenças nos valores predefinidos das definições dos parâmetros da base de dados.

Os testes de referência podem ajudar a compreender melhor as cargas de trabalho a migrar e contribuem para definir a arquitetura certa do ambiente de destino da migração. A recolha de informações sobre o desempenho é importante para ajudar a estimar as necessidades de desempenho do ambiente de destino. Google Cloud Os conceitos e as ferramentas de testes de referência são detalhados na fase Realize testes e validação do processo de migração, mas também se aplicam à fase de criação do inventário.

Ferramentas para avaliações

Para uma avaliação inicial da sua infraestrutura atual, recomendamos que use o Migration Center do Google Cloud, juntamente com outras ferramentas de avaliação de bases de dados especializadas, como o migVisor e a Database Migration Assessment Tool (DMA).

Com o centro de migração, pode fazer uma avaliação completa da sua aplicação e panorama de bases de dados, incluindo a adequação técnica para uma migração de base de dados para o Google Cloud. Recebe recomendações de tamanho e configuração para cada base de dados de origem e cria um relatório do custo total de propriedade (TCO) para servidores e bases de dados.

Para mais informações sobre a avaliação do seu ambiente da AWS através do Migration Center, consulte o artigo Importe dados de outros fornecedores de nuvem.

Além do centro de migração, pode usar a ferramenta especializada migVisor. O migVisor suporta uma variedade de motores de base de dados e é particularmente adequado para migrações heterogéneas. Para uma introdução ao migVisor, consulte a vista geral do migVisor.

O migVisor pode identificar artefactos e funcionalidades de base de dados proprietárias incompatíveis que podem causar a predefinição da migração e indicar soluções alternativas. O migVisor também pode recomendar uma solução Google Cloud de destino, incluindo o dimensionamento inicial e a arquitetura.

O resultado da avaliação da base de dados do migVisor fornece o seguinte:

• Descoberta e análise abrangentes das implementações atuais de bases de dados.
• Relatório detalhado da complexidade da migração, com base nas funcionalidades exclusivas usadas pela sua base de dados.
• Relatório financeiro com detalhes sobre a poupança de custos após a migração, os custos de migração e o novo orçamento operacional.
• Plano de migração faseado para mover bases de dados e aplicações associadas com interrupção mínima para a empresa.

Para ver alguns exemplos de resultados da avaliação, consulte o artigo migVisor – Ferramenta de avaliação da migração para a nuvem.

Tenha em atenção que o migVisor aumenta temporariamente a utilização do servidor de base de dados. Normalmente, esta carga adicional é inferior a 3% e pode ser executada durante as horas fora de ponta.

O resultado da avaliação do migVisor ajuda a criar um inventário completo das suas instâncias do RDS. O relatório inclui propriedades genéricas (versão e edição do motor da base de dados, CPUs e tamanho da memória), bem como detalhes sobre a topologia da base de dados, as políticas de cópia de segurança, as definições de parâmetros e as personalizações especiais em utilização.

Se preferir usar ferramentas de código aberto, pode usar scripts de recolha de dados com (ou em vez de) as ferramentas mencionadas. Estes scripts podem ajudar a recolher informações detalhadas (acerca de cargas de trabalho, funcionalidades, objetos de base de dados e código de base de dados) e criar o seu inventário de bases de dados. Além disso, os scripts costumam fornecer uma avaliação detalhada da migração da base de dados, incluindo uma estimativa do esforço de migração.

Recomendamos a ferramenta de código aberto DMA, que foi criada por engenheiros da Google. Oferece uma avaliação completa e precisa da base de dados, incluindo as funcionalidades em utilização, a lógica da base de dados e os objetos da base de dados (incluindo esquemas, tabelas, vistas, funções, acionadores e procedimentos armazenados).

Para usar a DMA, transfira os scripts de recolha para o seu motor de base de dados a partir do repositório Git e siga as instruções. Envie os ficheiros de saída para a Google Cloud análise Google Cloud .O Google Cloud Google Cloud cria e envia uma leitura da avaliação da base de dados e indica os passos seguintes no percurso de migração.

Identifique e documente o âmbito da migração e o tempo de inatividade acessível

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

• As suas bases de dados têm mais de 5 TB?
• Existem tabelas grandes na sua base de dados? Têm mais de 16 TB?
• Onde estão localizadas as bases de dados (regiões e zonas) e qual é a respetiva proximidade com as aplicações?
• Com que frequência é que os dados mudam?
• Qual é o seu modelo de consistência de dados?
• Quais são as opções de bases de dados de destino?
• Qual é a compatibilidade entre as bases de dados de origem e de destino?
• Os dados têm de residir em algumas localizações físicas?
• Existem dados que podem ser comprimidos e arquivados ou dados que não precisam de migração?

Para definir o âmbito da migração, decida que dados quer manter e que dados quer migrar. A migração de todas as suas bases de dados pode exigir um tempo e um esforço consideráveis. Alguns dados podem permanecer nas cópias de segurança da base de dados de origem. Por exemplo, as tabelas de registo antigas ou os dados de arquivo podem não ser necessários. Em alternativa, pode decidir mover os dados após o processo de migração, consoante a sua estratégia e ferramentas.

Estabeleça bases de referência de migração de dados que ajudem a comparar e avaliar os seus resultados e impactos. Estas bases representam pontos de referência que representam o estado dos seus dados antes e depois da migração e ajudam a tomar decisões. É importante fazer medições no ambiente de origem que podem ajudar a avaliar o sucesso da migração de dados. Essas medições incluem o seguinte:

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

Determine o tempo de inatividade que pode tolerar. Quais são os impactos empresariais do tempo de inatividade? Existem períodos de baixa atividade da base de dados, durante os quais há menos utilizadores afetados pelo tempo de inatividade? Em caso afirmativo, qual é a duração desses períodos e quando ocorrem? Considere ter um tempo de inatividade parcial apenas de escrita, enquanto os pedidos apenas de leitura continuam a ser processados.

Avalie o processo de implementação e administração

Depois de criar os inventários, avalie os processos operacionais e de implementação da sua base de dados para determinar como os tem de adaptar de modo a facilitar a migração. Estes processos são fundamentais para a forma como prepara e mantém o seu ambiente de produção.

Considere como conclui as seguintes tarefas:

• Defina e aplique políticas de segurança às suas instâncias: por exemplo, pode ter de substituir os grupos de segurança da Amazon. Pode usar funções do IAM da Google, regras de firewall da VPC e VPC Service Controls para controlar o acesso às suas instâncias do Cloud SQL e restringir os dados numa VPC.

• Aplique patches e configure as suas instâncias: pode ter de atualizar as suas ferramentas de implementação existentes. Por exemplo, pode estar a usar definições de configuração personalizadas em grupos de parâmetros ou grupos de opções da Amazon. As suas ferramentas de aprovisionamento podem ter de ser adaptadas para usar o Google Cloud Storage ou o Secret Manager para ler essas listas de configuração personalizadas.

• Faça a gestão da infraestrutura de monitorização e alertas: as categorias de métricas para as instâncias de base de dados de origem da Amazon oferecem observabilidade durante o processo de migração. As categorias de métricas podem incluir o Amazon CloudWatch, o Performance Insights, a monitorização melhorada e as listas de processos do SO.

Conclua a avaliação

Depois de criar os inventários a partir do seu ambiente do Amazon RDS ou Amazon Aurora, conclua as restantes atividades da fase de avaliação, conforme descrito em Migrar para Google Cloud: avalie e descubra as suas cargas de trabalho.

Planeie e crie a sua base

Na fase de planeamento e criação, aprovisiona e configura a infraestrutura para fazer o seguinte:

• Suporte as suas cargas de trabalho no seu Google Cloud ambiente.
• Ligue o ambiente de origem e o ambiente Google Cloud para concluir a migração.

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

1. Crie uma hierarquia de recursos.
2. Configure Google Cloud's Identity and Access Management (IAM).
3. Configure a faturação
4. Configure a conetividade de rede.
5. Reforce a sua segurança.
6. Configure o registo, a monitorização e os alertas.

Para mais informações sobre cada uma destas tarefas, consulte o artigo Migre para o Google Cloud: planeie e crie a sua base.

Se planeia usar o serviço de migração de base de dados para a migração, consulte os métodos de rede para o MySQL para compreender as configurações de rede disponíveis para cenários de migração.

Monitorização e alertas

Use o Google Cloud Monitoring, que inclui painéis de controlo predefinidos para vários Google Cloud produtos, incluindo um painel de controlo de monitorização do Cloud SQL. Em alternativa, pode ponderar usar soluções de monitorização de terceiros integradas com Google Cloud, como o Datadog e o Splunk. Para mais informações, consulte o artigo Acerca da observabilidade da base de dados.

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

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

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

2. Escolha as ferramentas de migração, consoante a estratégia e os requisitos escolhidos.

3. Defina o plano de migração e a linha cronológica para cada migração de base de dados, incluindo tarefas de preparação e execução.

4. Defina as tarefas de preparação que têm de ser realizadas para garantir que a ferramenta de migração funciona corretamente.

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

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

7. Realize testes e validação, que podem ser feitos num ambiente de preparação separado.

8. Faça a migração.

9. Faça a mudança para produção.

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

11. Realize o ajuste e a otimização.

Cada fase é descrita nas secções seguintes.

Escolha a sua estratégia de migração

Neste passo, tem informações suficientes para avaliar e selecionar uma das seguintes estratégias de migração que melhor se adequa ao seu exemplo de utilização para cada base de dados:

• Manutenção agendada (também denominada migração única ou migração big bang): Esta abordagem é ideal se puder tolerar o tempo de inatividade. Esta opção tem um custo e uma complexidade relativamente mais baixos, porque as suas cargas de trabalho e serviços não requerem muita refatoração. No entanto, se a migração falhar antes da conclusão, tem de reiniciar o processo, o que prolonga o tempo de inatividade.

• Replicação contínua (também denominada migração online ou migração gradual): para bases de dados de serviço crítico, esta opção oferece um risco menor de perda de dados e um tempo de inatividade quase nulo. Os esforços são divididos em vários blocos, pelo que, se ocorrer uma falha, a reversão e a repetição demoram menos tempo. No entanto, a configuração é mais complexa e requer mais planeamento e tempo. Também é necessário esforço adicional para refatorar as aplicações que se ligam às instâncias da base de dados. Considere uma das seguintes variações:

  • Usando a abordagem Y (escrita e leitura), que é uma forma de migração paralela, duplicando dados nas instâncias de origem e de destino durante a migração.
  • Usar um microsserviço de acesso a dados, que reduz o esforço de refatoração exigido pela abordagem Y (escrita e leitura).

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

O diagrama seguinte mostra um fluxograma baseado em perguntas de exemplo que pode ter ao decidir a estratégia de migração para uma única base de dados:

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

• Pode permitir qualquer tempo de inatividade?

  • Caso contrário, adote a estratégia de migração de replicação contínua.
  • Em caso afirmativo, continue para o ponto de decisão seguinte.

• Consegue suportar o tempo de inatividade representado pela janela de transição durante a migração de dados? A janela de transição representa a quantidade de tempo necessária para fazer uma cópia de segurança da base de dados, transferi-la para o Cloud SQL, restaurá-la e, em seguida, mudar as suas aplicações.

  • Caso contrário, 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 agendada.

As estratégias podem variar para diferentes bases de dados, mesmo quando estão localizadas na mesma instância. Uma combinação de estratégias pode produzir resultados ideais. Por exemplo, pode migrar bases de dados pequenas e usadas com pouca frequência através da abordagem de manutenção agendada, mas usar a replicação contínua para bases de dados de serviço crítico em que ter tempo de inatividade é dispendioso.

Normalmente, uma migração é considerada concluída quando ocorre a mudança entre a instância de origem inicial e a instância de destino. Qualquer replicação (se usada) é interrompida e todas as leituras e escritas são feitas na instância de destino. A mudança quando ambas as 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 as estratégias e as implementações de migração de dados, consulte o artigo Classificação das migrações de bases de dados.

Minimize o tempo de inatividade e os impactos relacionados com a migração

As configurações de migração que não provocam tempo de inatividade da aplicação requerem uma configuração mais complexa. Encontre o equilíbrio certo entre a complexidade da configuração e o tempo de inatividade agendado durante o horário de funcionamento com pouco tráfego.

Cada estratégia de migração tem uma compensação e algum impacto associado ao processo de migração. Por exemplo, os processos de replicação envolvem alguma carga adicional nas instâncias de origem, e as suas aplicações podem ser afetadas pelo atraso na replicação. As aplicações (e os clientes) podem ter de esperar durante o tempo de inatividade da aplicação, pelo menos, durante o tempo de atraso da replicação antes de usar a nova base de dados. Na prática, os seguintes fatores podem aumentar o tempo de inatividade:

• As consultas da base de dados podem demorar alguns segundos a concluir. No momento da migração, as consultas em curso podem ser anuladas.
• A cache pode demorar algum tempo a ficar cheia se a base de dados for grande ou tiver uma memória de buffer substancial.
• As aplicações paradas na origem e reiniciadas em Google Cloud podem ter um pequeno atraso até ser estabelecida a ligação à instância da base de dados Google Cloud.
• As rotas de rede para as aplicações têm de ser reencaminhadas. Dependendo da forma como as entradas DNS estão configuradas, este processo pode demorar algum tempo. Quando atualizar os registos DNS, reduza o TTL antes da migração.

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

• Encontre um período em que o tempo de inatividade tenha um impacto mínimo nos seus volumes de trabalho. Por exemplo, fora do horário de funcionamento normal, durante os fins de semana ou outros períodos de manutenção agendados.
• Identifique partes das suas cargas de trabalho que podem ser migradas e transferidas para produção em diferentes fases. As suas aplicações 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 relatórios. Estes módulos podem ter as suas próprias bases de dados que podem ser agendadas para migração mais cedo ou mais tarde no processo.
• Se puder tolerar alguma latência na base de dados de destino, considere implementar uma migração gradual. Use transferências de dados incrementais em lote e adapte parte das suas cargas de trabalho para funcionar com os dados desatualizados na instância de destino.
• Considere refatorar as suas aplicações para suportar um impacto mínimo da migração. Por exemplo, adapte as suas aplicações para escrever nas bases de dados de origem e de destino e, por conseguinte, implemente uma replicação ao nível da aplicação.

Escolha as ferramentas de migração

O fator mais importante para uma migração bem-sucedida é escolher a ferramenta de migração certa. Depois de decidir a estratégia de migração, reveja e decida qual ferramenta de migração usar.

Existem muitas ferramentas disponíveis, cada uma otimizada para determinados exemplos de utilização de migração. Os exemplos de utilização podem incluir o seguinte:

• Estratégia de migração (manutenção agendada ou replicação contínua).
• Motores de base de dados e versões do motor de origem e destino.
• Ambientes nos quais as instâncias de origem e as instâncias de destino estão localizadas.
• Tamanho da base de dados. Quanto maior for a base de dados, mais tempo demora a migrar a cópia de segurança inicial.
• Frequência das alterações à base de dados.
• Disponibilidade para usar serviços geridos para migração.

Para garantir uma migração e uma transição perfeitas, pode usar padrões de implementação de aplicações, orquestração de infraestruturas e aplicações de migração personalizadas. No entanto, as ferramentas especializadas denominadas serviços de migração geridos podem facilitar o processo de mover dados, aplicações ou até mesmo infraestruturas inteiras de um ambiente para outro. Executam a extração de dados das bases de dados de origem, transportam os dados em segurança para as bases de dados de destino e, opcionalmente, podem modificar os dados durante a transmissão. Com estas capacidades, encapsulam a lógica complexa da migração e oferecem capacidades de monitorização da migração.

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

• Minimize o tempo de inatividade: os serviços usam as capacidades de replicação integradas dos motores de base de dados quando disponíveis e fazem a promoção de réplicas.

• Garantir a integridade e a segurança dos dados: os dados são transferidos de forma segura e fiável da origem para a base de dados de destino.

• Oferecer uma experiência de migração consistente: é possível consolidar diferentes técnicas e padrões de migração numa interface consistente e comum através de ficheiros executáveis de migração de bases de dados, que pode gerir e monitorizar.

• Oferecer modelos de migração resilientes e comprovados: as migrações de bases de dados são eventos pouco frequentes, mas críticos. Para evitar erros de principiante e problemas com soluções existentes, pode usar ferramentas de especialistas experientes, em vez de criar uma solução personalizada.

• Otimize os custos: os serviços de migração geridos podem ser mais rentáveis do que o aprovisionamento de servidores e recursos adicionais para soluções de migração personalizadas.

As secções seguintes descrevem as recomendações da ferramenta de migração, que dependem da estratégia de migração escolhida.

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

O diagrama seguinte mostra um fluxograma com perguntas que podem ajudar a escolher a ferramenta de migração para uma única base de dados quando usa uma estratégia de migração de manutenção agendada:

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

• Prefere serviços de migração geridos?
  • Se for o caso, recomendamos que use o serviço de migração de bases de dados.
  • Se não, recomendamos que faça a migração através das cópias de segurança incorporadas do motor da base de dados.

A utilização de um serviço de migração gerido oferece algumas vantagens, que são abordadas na secção Escolha as suas ferramentas de migração deste documento.

As subsecções seguintes descrevem as ferramentas que podem ser usadas para migrações únicas, juntamente com as respetivas limitações e práticas recomendadas.

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

O serviço de migração de bases de dados gere a sincronização inicial e a replicação contínua de captura de dados de alterações (CDC), e fornece o estado da operação de migração.

Ao usar o Database Migration Service, pode criar tarefas de migração que pode gerir e validar. Recomendamos que use o serviço de migração de base de dados, uma vez que suporta migrações para o Cloud SQL para MySQL através de tarefas de migração únicas. Para bases de dados grandes, pode usar o paralelismo de despejo de dados no serviço de migração de bases de dados.

Para mais informações sobre a arquitetura de migração de bases de dados e sobre o Database Migration Service, consulte os artigos Migre uma base de dados para o Cloud SQL para MySQL através do Database Migration Service e Fidelidade da migração para o MySQL.

Para mais informações sobre as limitações e os pré-requisitos do serviço de migração de bases de dados, consulte o seguinte:

• Limitações conhecidas no Database Migration Service.
• Quotas e limites no Database Migration Service.
• Configure a sua origem no serviço de migração de bases de dados.

Cópias de segurança do motor de base de dados incorporado

Quando um tempo de inatividade significativo é aceitável e as bases de dados de origem são relativamente estáticas, pode usar as capacidades de descarga e carregamento incorporadas do motor de base de dados (também denominadas, por vezes, cópia de segurança e restauro).

É necessário algum esforço para a configuração e a sincronização, especialmente para um grande número de bases de dados, mas as cópias de segurança do motor de base de dados estão normalmente disponíveis e são fáceis de usar.

As cópias de segurança do motor da base de dados têm as seguintes limitações gerais:

• As cópias de segurança podem ser propensas a erros, especialmente se forem feitas manualmente.
• Os dados não estão seguros se as cópias de segurança não forem geridas corretamente.
• As cópias de segurança não têm as capacidades de monitorização adequadas.
• É necessário esforço para dimensionar, se estiverem a ser migradas muitas bases de dados através desta ferramenta.

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

• Se a sua base de dados for relativamente pequena (inferior a 10 GB), recomendamos que use o mysqldump. Não existe um limite fixo, mas o tamanho ideal da base de dados para o mysqldump é normalmente inferior a 10 GB.

• Se importar bases de dados com mais de 10 GB, pode precisar de outras estratégias para minimizar o tempo de inatividade da base de dados. Seguem-se algumas destas estratégias:

  • Exporte o esquema e os dados em subsecções, sem chaves secundárias.
  • Tire partido das indicações de tempo. Se alguma das suas tabelas usar colunas de data/hora, pode usar uma funcionalidade do comando mysqldump que lhe permite especificar uma cláusula WHERE para filtrar por uma coluna de data/hora.
  • Pondere outras abordagens, como usar as ferramentas mydumper e myloader.

Normalmente, as descargas e as cópias de segurança da base de dados não incluem contas de utilizador do MySQL. Quando se prepara para a migração, reveja todas as contas de utilizador na instância de origem. Por exemplo, pode executar o comando SHOW GRANTS para cada utilizador para rever o conjunto atual de privilégios e ver se existem privilégios restritos no Cloud SQL. Da mesma forma, a ferramenta pt-show-grants da Percona também pode listar concessões.

As restrições nos privilégios do utilizador no Cloud SQL podem afetar as migrações quando migram objetos de base de dados que têm um atributo DEFINER. Por exemplo, um procedimento armazenado pode ter um definidor com privilégios superiores para executar comandos SQL, como alterar uma variável global que não é permitida no Cloud SQL. Para casos como este, pode ter de reescrever o código do procedimento armazenado ou migrar objetos que não sejam tabelas, como procedimentos armazenados, como um passo de migração separado. Para mais informações, consulte as práticas recomendadas para importar e exportar dados.

Para ler mais sobre as limitações e as práticas recomendadas, consulte o seguinte:

• Acerca dos utilizadores do Cloud SQL para MySQL.
• 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 de manutenção programada

Como parte da utilização de uma importação gerida para configurar a replicação a partir de uma base de dados MySQL externa, existe um carregamento inicial de dados da base de dados externa para a instância do Cloud SQL. Esta abordagem usa um serviço que extrai dados do servidor externo (a instância do RDS, neste caso) e importa-os diretamente para a instância do Cloud SQL.

Para grandes bases de dados (vários TB), uma forma mais rápida é usar um carregamento inicial de importação personalizado que use as ferramentas mydumper e myloader.

Pode considerar exportar as tabelas da sua base de dados MySQL para ficheiros CSV, que podem ser importados para o Cloud SQL para MySQL. Para exportar dados da sua instância do RDS, pode usar o AWS Database Migration Service (AWS DMS) e um contentor do S3 como destino.

Para ver informações detalhadas e passos, consulte o artigo Use uma importação gerida para configurar a replicação a partir de bases de dados externas.

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

O diagrama seguinte mostra um fluxograma com perguntas que podem ajudar a escolher a ferramenta de migração para uma única base de dados quando usa uma estratégia de migração de replicação contínua:

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

• Prefere usar serviços de migração geridos?

  • Se sim, pode permitir alguns segundos de inatividade de escrita, dependendo do número de tabelas na sua base de dados?

    • Em caso afirmativo, use o serviço de migração de bases de dados.
    • Se não, explore outras opções de migração.

  • Se não, tem de avaliar se a replicação incorporada do motor da base de dados é suportada:

    • Se for o caso, recomendamos que use a replicação integrada.
    • Se não, recomendamos que explore outras opções de migração.

As secções seguintes descrevem as ferramentas que podem ser usadas para migrações contínuas, juntamente com as respetivas limitações e práticas recomendadas.

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

O Database Migration Service oferece suporte integrado para migrações contínuas através da utilização de tipos de tarefas de migração contínuas. Só é possível promover tarefas de migração contínuas, o que indica que a replicação deve ser interrompida.

Se escolher esta ferramenta, tenha em conta as seguintes restrições e práticas recomendadas:

• Evite transações de longa duração durante a migração. Nestes casos, recomendamos a migração de uma réplica de leitura se não estiver a migrar do AWS Aurora.
• Para ver uma lista completa das limitações, consulte o artigo Limitações conhecidas.

Replicação integrada do motor de base de dados

A replicação incorporada do motor de base de dados é uma opção alternativa ao serviço de migração de bases de dados para uma migração contínua.

A replicação de bases de dados representa o processo de copiar e distribuir dados de uma base de dados denominada base de dados principal para outras bases de dados denominadas réplicas. Destina-se a aumentar a acessibilidade dos dados e melhorar a tolerância a falhas e a fiabilidade de um sistema de base de dados. Embora a migração da base de dados não seja o objetivo principal da replicação da base de dados, pode ser usada com êxito como uma ferramenta para alcançar este objetivo. Normalmente, a replicação da base de dados é um processo contínuo que ocorre em tempo real à medida que os dados são inseridos, atualizados ou eliminados na base de dados principal. Pode ser feito como uma operação única ou uma sequência de operações em lote.

A maioria dos motores de base de dados modernos implementa diferentes formas de alcançar a replicação da base de dados. Um tipo de replicação pode ser alcançado copiando e enviando o registo de transações ou o registo de gravação antecipada do servidor principal para as respetivas réplicas. Esta abordagem é denominada replicação física ou binária. Outros tipos de replicação funcionam através da distribuição das declarações SQL não processadas que uma base de dados principal recebe, em vez de replicar alterações ao nível do sistema de ficheiros.

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

Pré-requisitos:

• Certifique-se de que está a usar o MySQL 5.5, 5.6, 5.7 ou 8.0 na sua instância do Amazon RDS ou Amazon Aurora.
• Certifique-se de que os registos binários estão ativados.
• Para acelerar a fase de despejo completo inicial, escolha um nível de máquina suficientemente grande do ponto de vista do tamanho da CPU e da memória.
• Se precisar de acelerar a fase de CDC, pode tentar configurar a replicação paralela e ativar a limpeza de alto desempenho.
• Se a réplica do Cloud SQL estiver ativada com endereços IP internos, uma vez que o endereço IP de saída não é estático, configure a firewall do servidor do Amazon RDS ou do Amazon Aurora para permitir o intervalo de IP interno atribuído para o acesso privado aos serviços da rede VPC que a réplica do Cloud SQL usa como rede privada. Para mais informações, consulte os artigos Acerca da replicação a partir de um servidor externo e Configure o acesso a serviços privados.

Limitações:

• Se tiver tabelas grandes únicas e muitos índices secundários na sua base de dados, a descarga completa inicial pode demorar mais tempo.
• Se o seu servidor externo contiver cláusulas DEFINER (visualizações, eventos, acionadores ou procedimentos armazenados), dependendo da ordem de execução destas declarações, a replicação pode falhar. Saiba mais sobre a DEFINER utilização e as potenciais soluções alternativas no Cloud SQL.
• O InnoDB é o único motor de base de dados suportado no Cloud SQL. A migração do MyISAM pode causar inconsistência de dados e requer a validação de dados. Consulte o artigo Converter tabelas de MyISAM para InnoDB.

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

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

• Refatore as suas aplicações para executar Y (escrita e leitura) ou use um microsserviço de acesso a dados.

  • A replicação contínua é realizada pelas suas aplicações.
  • O esforço de migração centra-se na refatoração ou no desenvolvimento de ferramentas que se ligam às suas instâncias de base de dados.
  • Em seguida, as aplicações de leitura são gradualmente refatoradas e implementadas para usar a instância de destino.

• Replique alterações quase em tempo real da sua instância do MySQL através do Datastream.

  • 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 o BigQuery ou o Cloud Storage e, em seguida, use o Dataflow ou o Dataproc para transferir os dados para a sua instância do Cloud SQL.

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

• Configure uma base de dados Amazon RDS for MySQL no Datastream
• Configure uma base de dados MySQL do Amazon Aurora no Datastream
• Transmita alterações aos dados em tempo real com o Datastream

Ferramentas de terceiros para a migração de replicação contínua

Em alguns casos, pode ser melhor usar uma ferramenta de terceiros para a maioria dos motores de base de dados. Estes casos podem ocorrer se preferir usar um serviço de migração gerido e precisar de garantir que a base de dados de destino está sempre sincronizada em tempo quase 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 recomendações, que pode usar para a maioria dos motores de base de dados.

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

• Vantagens:

  • Processa grandes volumes de dados e migrações complexas.
  • Captura de dados de alterações incorporada para o SQL Server.
  • Modelos de associação pré-configurados e pipelines sem código.
  • Capacidade de processar bases de dados grandes e de serviço crítico que funcionam sob uma carga transacional elevada.
  • Entrega exatamente uma vez.

• Desvantagens:

  • Não é de código aberto.
  • Pode tornar-se dispendioso, especialmente para migrações longas.
  • Algumas limitações na propagação de operações da linguagem de definição de dados (LDD). Para mais informações, consulte os artigos Operações DDL suportadas e Notas e limitações da evolução do esquema.

Para mais informações sobre o Striim, consulte o artigo Executar o Striim no Google Cloud.

O Debezium é uma plataforma distribuída de código aberto para CDC e pode transmitir alterações de dados para subscritores externos:

• Vantagens:

  • Código aberto.
  • Forte apoio da comunidade.
  • Rentável.
  • Controlo detalhado sobre linhas, tabelas ou bases de dados.
  • Especializada para a captura de alterações em tempo real a partir de registos de transações da base de dados.

• Desvantagens:

  • Requer experiência específica com o Kafka e o ZooKeeper.
  • Entrega de alterações de dados, pelo menos, uma vez, o que significa que precisa de processamento de duplicados.
  • Configuração manual da monitorização através do Grafana e do Prometheus.
  • Não existe suporte para a replicação em lote incremental.

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

A Fivetran é uma plataforma de movimento de dados automatizada para mover dados para fora e entre plataformas de dados na nuvem.

• Vantagens:

  • Modelos de associação pré-configurados e pipelines sem código.
  • Propaga todas as alterações de esquema da origem para a base de dados de destino.
  • Entrega exata das alterações aos dados, o que significa que não precisa de processamento de duplicados.

• Desvantagens:

  • Não é de código aberto.
  • O suporte para a transformação de dados complexa é limitado.

Defina o plano de migração e a linha cronológica

Para uma migração bem-sucedida da base de dados e uma mudança de produção, recomendamos que prepare um plano de migração abrangente e bem definido. Para ajudar a reduzir o impacto na sua empresa, recomendamos que crie uma lista de todos os itens de trabalho necessários.

A definição do âmbito da migração revela as tarefas que tem de realizar antes, durante e após o processo de migração da base de dados. Por exemplo, se decidir não migrar determinadas tabelas de uma base de dados, pode precisar de tarefas de pré-migração ou pós-migração para implementar esta filtragem. Também garante que a migração da base de dados não afeta o contrato de nível de serviço (SLA) existente nem o plano de continuidade da empresa.

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

• Documento de design técnico (TDD)
• Matriz RACI
• Linha cronológica (como um plano de contagem decrescente)

As migrações de bases de dados são um processo iterativo e as primeiras migrações são frequentemente mais lentas do que as posteriores. Normalmente, as migrações bem planeadas são executadas sem problemas, mas podem surgir problemas não planeados. Recomendamos que tenha sempre um plano de reversão. Como prática recomendada, siga as orientações do artigo Migrar para Google Cloud: práticas recomendadas para validar um plano de migração.

TDD

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

• Requisitos comerciais e criticidade
• Objetivo de tempo de recuperação (OTR)
• Objetivo de ponto de recuperação (OPR)
• Detalhes da migração de base de dados
• Estimativas do esforço de migração
• Recomendações de validação da migração

Matriz RACI

Alguns projetos de migração requerem uma matriz RACI, que é um documento de gestão de projetos comum que define os indivíduos ou os grupos responsáveis por tarefas e resultados no projeto de migração.

Linha cronológica

Prepare uma cronologia para cada base de dados que precise de ser migrada. Inclua todas as tarefas de trabalho que têm de ser realizadas, bem como datas de início definidas e datas de conclusão estimadas.

Para cada ambiente de migração, recomendamos que crie um plano de contagem decrescente. Um plano de contagem decrescente está estruturado como um cronograma de contagem decrescente e lista todas as tarefas necessárias para concluir o projeto de migração, juntamente com os grupos responsáveis e a duração estimada.

A linha cronológica deve ter em conta não só a execução das tarefas de preparação pré-migração, mas também as tarefas de validação, auditoria ou teste que ocorrem após a transferência de dados.

Normalmente, a duração das tarefas de migração depende do tamanho da base de dados, mas também existem outros aspetos a considerar, como a complexidade da lógica de negócio, a utilização da aplicação e a disponibilidade da equipa.

Um plano de contagem decrescente pode ter o seguinte aspeto:

Data	Fase	Categoria	Tasks	Função	T-minus	Estado
01/11/2023	Pré-migração	Avaliação	Crie um relatório de avaliação	Equipa de descoberta	-21	Concluído
07/11/2023	Pré-migração	Preparação do alvo	Conceba o ambiente de destino conforme descrito no documento de design	Equipa de migração	-14	Concluído
15/11/2023	Pré-migração	Governança da empresa	Data de migração e aprovação de contagem decrescente	Liderança	-6	Concluído
18/11/2023	Migração	Configure o DMS	Crie perfis de ligação	Engenheiro de migração para a nuvem	-3	Concluído
19/11/2023	Migração	Configure o DMS	Crie e inicie tarefas de migração	Engenheiro de migração para a nuvem	-2	Não iniciado
19/11/2023	Migração	Monitorize os DMS	Monitorize trabalhos do DMS e alterações de DDL na instância de origem	Engenheiro de migração para a nuvem	-2	Não iniciado
21/11/2023	Migração	Cutover DMS	Promova a réplica do DMS	Engenheiro de migração para a nuvem	0	Não iniciado
21/11/2023	Migração	Validação da migração	Validação da migração de base de dados	Equipa de migração	0	Não iniciado
21/11/2023	Migração	Teste de candidatura	Execute testes de desempenho e capacidades	Equipa de migração	0	Não iniciado
22/11/2023	Migração	Governança da empresa	Validação da migração: APROVADA ou REPROVADA	Equipa de migração	1	Não iniciado
23/11/2023	Após a migração	Valide a monitorização	Configure a monitorização	Equipa de infraestrutura	2	Não iniciado
25/11/2023	Após a migração	Segurança	Remova a conta de utilizador do DMS	Equipa de segurança	4	Não iniciado

Migrações de várias bases de dados

Se tiver várias bases de dados para migrar, o seu plano de migração deve conter tarefas para todas as migrações.

Recomendamos que inicie o processo migrando uma base de dados mais pequena e, idealmente, não essencial. Esta abordagem pode ajudar a desenvolver os seus conhecimentos e confiança no processo de migração e nas ferramentas. Também pode detetar falhas no processo nas fases iniciais do cronograma de migração geral.

Se tiver várias bases de dados para migrar, as linhas cronológicas podem ser paralelizadas. Por exemplo, para acelerar o processo de migração, pode optar por migrar um grupo de bases de dados pequenas, estáticas ou menos críticas ao mesmo tempo, conforme mostrado no diagrama seguinte.

No exemplo apresentado no diagrama, as bases de dados 1 a 4 são um grupo de bases de dados pequenas que são migradas em simultâneo.

Defina as tarefas de preparação

As tarefas de preparação são todas as atividades que tem de concluir para cumprir os pré-requisitos da migração. Sem as tarefas de preparação, a migração não pode ocorrer ou resulta numa base de dados migrada num estado inutilizável.

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

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

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

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

• Consoante o caminho de migração, pode ter de permitir ligações remotas nas suas instâncias do RDS. Se a sua instância do RDS estiver configurada para ser privada na sua VPC, tem de existir uma conetividade RFC 1918 privada entre a Amazon e o Google Cloud.

• Pode ter de configurar um novo grupo de segurança para permitir ligações remotas nas portas necessárias.

  • Por predefinição, na AWS, o acesso à rede está desativado para instâncias de base de dados.
  • Pode especificar regras num grupo de segurança que permitam o acesso a partir de um intervalo de endereços IP, uma porta ou um grupo de segurança. As mesmas regras aplicam-se a todas as instâncias da base de dados associadas a esse grupo de segurança.

• Certifique-se de que tem espaço livre no disco suficiente para armazenar em buffer os registos WAL durante a operação de carregamento completo na sua instância do Amazon RDS.

• Para obter os melhores resultados de migração, considere migrar a partir de uma réplica de leitura, a menos que esteja a migrar a partir do Amazon Aurora. Além disso, recomendamos que inicie o processo de migração durante um período de atividade reduzida da base de dados.

• O MySQL limita o nome do anfitrião a 60 carateres. Normalmente, os nomes de anfitrião da base de dados do Amazon RDS têm mais de 60 carateres. Se for o caso da base de dados que está a migrar, configure um redirecionamento DNS para criar um registo CNAME que associe o nome do seu domínio ao nome do domínio da instância da base de dados RDS.

• Se estiver a usar a replicação integrada, tem de configurar a instância do Amazon RDS ou do Amazon Aurora para a replicação. A replicação incorporada ou as ferramentas que a usam precisam do registo binário para o MySQL definido como ROW.

• Se estiver a usar ferramentas de terceiros, normalmente, são necessárias definições e configurações iniciais antes de usar a ferramenta. Consulte a documentação da ferramenta de terceiros.

Para mais informações acerca da preparação e dos pré-requisitos da instância, consulte o artigo Configure o servidor externo para replicação para o MySQL.

Preparação e pré-requisitos da base de dados de origem

• Se optar por usar o serviço de migração de bases de dados, tem de configurar a base de dados de origem antes de estabelecer ligação à mesma. Reveja as tarefas de migração antes de as implementar. Para mais informações, consulte o artigo Configure a sua origem para o MySQL.
• Consoante o motor da base de dados, pode ter de alterar determinadas funcionalidades. Por exemplo, o Cloud SQL para MySQL suporta apenas o motor de base de dados InnoDB. Tem de alterar as tabelas MyISAM para InnoDB.
• Algumas ferramentas de migração de terceiros requerem que todas as colunas LOB sejam anuláveis. Todas as colunas LOB que sejam NOT NULL têm de ter essa restrição removida durante a migração.

• Faça medições de base no seu ambiente de origem em utilização de produção. Considere o seguinte:

  • Meça o tamanho dos seus dados, bem como o desempenho da sua carga de trabalho. Quanto tempo demoram as consultas ou as transações importantes, em média? Quanto tempo durante as horas de pico?
  • Documente as medições de base para comparação posterior, para ajudar a decidir se a fidelidade da migração da base de dados é satisfatória. Decida se pode mudar as cargas de trabalho de produção e desativar o ambiente de origem ou se ainda precisa dele para fins de alternativa.

Configuração do Cloud SQL

Escolha cuidadosamente o tamanho e as especificações da instância da base de dados do Cloud SQL para MySQL de destino para corresponder à origem para necessidades de desempenho semelhantes. Preste especial atenção ao tamanho do disco e à taxa de transferência, aos IOPS e ao número de vCPUs. O dimensionamento incorreto pode levar a tempos de migração longos, problemas de desempenho da base de dados, erros da base de dados e problemas de desempenho da aplicação.

Tem de confirmar as seguintes propriedades e requisitos antes de criar as instâncias do Cloud SQL, porque não podem ser alterados posteriormente sem as recriar.

• Escolha cuidadosamente o projeto e a região das instâncias do Cloud SQL de destino. Não é possível migrar instâncias do Cloud SQL entre projetos e regiões Google Cloud sem transferência de dados.
• Migre para uma versão principal correspondente no Cloud SQL. Por exemplo, se a sua origem usar o MySQL 8.0.34 no Amazon RDS ou no Amazon Aurora, deve migrar para o Cloud SQL para MySQL versão 8.0.34.
• Replique as informações do utilizador separadamente se estiver a usar cópias de segurança do motor de base de dados incorporado ou o serviço de migração de bases de dados. O Cloud SQL gere os utilizadores através do Google IAM. Para ver detalhes, reveja as limitações na secção Cópias de segurança do motor de base de dados incorporado.
• Reveja os flags de configuração do motor da base de dados e compare os respetivos valores da instância de origem e de destino. Certifique-se de que compreende o respetivo impacto e se têm de ser iguais ou não. Por exemplo, recomendamos que execute o comando SHOW VARIABLES na base de dados de origem antes da migração e, em seguida, o execute novamente na base de dados do Cloud SQL. Atualize as definições de flags conforme necessário na base de dados do Cloud SQL para replicar as definições de origem. Tenha em atenção que nem todas as flags do MySQL são permitidas numa instância do Cloud SQL.

Para mais informações sobre a configuração do Cloud SQL, consulte o seguinte:

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

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

Se importar ficheiros de captura SQL para o Cloud SQL, pode ter de criar um contentor do Cloud Storage. O contentor armazena a descarga da base de dados.

Se usar a replicação, tem de garantir que a réplica do Cloud SQL tem acesso à sua base de dados principal. Este acesso pode ser conseguido através das opções de conetividade documentadas.

Consoante o seu cenário e criticidade, pode ter de implementar um cenário alternativo, que normalmente inclui inverter a direção da replicação. Neste caso, pode precisar de um mecanismo de replicação adicional do Cloud SQL para a sua instância da Amazon de origem.

Para a maioria das ferramentas de terceiros, tem de aprovisionar recursos específicos de migração. Por exemplo, para o Striim, tem de usar o Google Cloud Marketplace para começar. Em seguida, para configurar o ambiente de migração no Striim, pode usar o Flow Designer para criar e alterar aplicações ou selecionar um modelo pré-existente. As aplicações também podem ser codificadas através da linguagem de programação Tungsten Query Language (TQL). Através de um painel de controlo de validação de dados, pode obter uma representação visual dos dados processados pela sua aplicação Striim.

Pode desativar os recursos que ligam o seu ambiente da Amazon e Google Cloud depois de a migração estar concluída e validada.

Para mais informações, consulte o seguinte:

• Faça a gestão de tarefas de migração no Database Migration Service
• Práticas recomendadas para importar e exportar dados
• Conetividade para o MySQL

Defina as tarefas de execução

As tarefas de execução implementam o trabalho de migração propriamente dito. As tarefas dependem da ferramenta de migração escolhida, conforme descrito nas subsecções seguintes.

Cópias de segurança do motor de base de dados incorporado

Para fazer uma migração única, use o utilitário mysqldump para criar uma cópia de segurança, que copia os dados do Amazon RDS para o computador cliente local. Para ver instruções, consulte o artigo Importe um ficheiro de captura SQL para o Cloud SQL para MySQL.

Pode verificar o estado das operações de importação e exportação da sua instância do Cloud SQL.

Tarefas de migração do Database Migration Service

Defina e configure tarefas de migração no serviço de migração de bases de dados para migrar dados de uma instância de origem para a base de dados de destino. As tarefas de migração estabelecem ligação à instância da base de dados de origem através de perfis de ligação definidos pelo utilizador.

Teste todos os pré-requisitos para garantir que a tarefa pode ser executada com êxito. Escolha uma hora em que as suas cargas de trabalho possam ter um pequeno tempo de inatividade para a migração e a mudança de produção.

No serviço de migração de bases de dados, a migração começa com a cópia de segurança completa inicial e o carregamento, seguido de um fluxo contínuo de alterações da instância da base de dados de origem para a de destino.

O serviço de migração de bases de dados requer alguns segundos para obter o bloqueio de leitura em todas as tabelas na sua instância do Amazon RDS ou do Amazon Aurora de origem que precisa de executar a descarga completa inicial de forma consistente. Para alcançar o bloqueio de leitura, pode ser necessário um tempo de inatividade de gravação entre 1 e 49 segundos. Os tempos de inatividade dependem do número de tabelas na sua base de dados, com 1 segundo correspondente a 100 tabelas e 9 segundos correspondentes a 10 000 tabelas.

O processo de migração com o Database Migration Service termina com a operação de promoção. A promoção de uma instância da base de dados desliga a base de dados de destino do fluxo de alterações provenientes da base de dados de origem e, em seguida, a instância de destino agora autónoma é promovida a uma instância principal. Por vezes, esta abordagem também é denominada mudança de produção.

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

• Reveja uma tarefa de migração
• Faça a gestão de tarefas de migração
• Promova uma migração

Para um processo de configuração de migração detalhado, consulte o artigo Migre uma base de dados para o Cloud SQL para MySQL através do Database Migration Service. No Database Migration Service, a migração é realizada através do início e da execução de uma tarefa de migração.

Replicação integrada do motor de base de dados

Pode usar a replicação incorporada do Amazon RDS para uma instância externa do Cloud SQL para MySQL.

Para o MySQL, tem de começar por fazer um despejo inicial que pode ser armazenado num contentor do Cloud Storage e, em seguida, importar os dados para o Cloud SQL para MySQL. Em seguida, inicia o processo de replicação.

Monitorize a replicação e pare as gravações na instância de origem num momento adequado. Verifique novamente o estado da replicação para se certificar de que todas as alterações foram replicadas e, em seguida, promova a réplica do Cloud SQL para MySQL a uma instância autónoma para concluir a migração.

Para obter instruções detalhadas sobre como configurar a replicação incorporada a partir de um servidor externo, como o Amazon RDS ou o Amazon Aurora para MySQL, consulte os artigos Acerca da replicação a partir de um servidor externo e Configure o Cloud SQL e o servidor externo para replicação.

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

• Exporte a sua base de dados para um contentor do Cloud Storage
• Use uma importação gerida para configurar a replicação a partir de bases de dados externas
• Inicie a replicação no servidor externo

Ferramentas de terceiros

Defina as tarefas de execução para a ferramenta de terceiros que escolheu.

Esta secção foca-se no Striim como exemplo. O Striim usa aplicações que adquirem dados de várias origens, processam os dados e, em seguida, fornecem os dados a outras aplicações ou destinos.

As aplicações podem ser criadas graficamente através do cliente Web e contêm origens, destinos e outros componentes lógicos organizados num ou mais fluxos.

Para configurar o seu ambiente de migração no Striim, pode usar a funcionalidade Flow Designer para criar e alterar aplicações ou pode selecionar entre vários modelos pré-existentes. As aplicações também podem ser codificadas através da linguagem de programação TQL.

Pode obter uma representação visual dos dados processados pela sua aplicação Striim através de um painel de controlo de validação de dados.

Para começar rapidamente a usar o Striim no Google Cloud, consulte o artigo Executar o Striim no Google Cloud. Para saber mais sobre os conceitos básicos do Striim, consulte os conceitos do Striim. Certifique-se de que também lê o guia de práticas recomendadas para Mudar de um carregamento inicial para uma replicação contínua.

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

• Informar as equipas envolvidas sempre que cada um dos passos do plano começar e terminar.
• Se algum dos passos demorar mais do que o esperado, compare o tempo decorrido com o tempo máximo atribuído a cada passo. Emitir atualizações intermediárias regulares às equipas envolvidas quando isto acontecer.
• Se o intervalo de tempo for superior ao tempo máximo reservado para cada passo no plano, considere reverter.
• Tome decisões de "aprovar ou rejeitar" para cada passo do plano de migração e transição.
• Considere ações de reversão ou cenários alternativos para cada um dos passos.

Defina cenários alternativos

Defina itens de ação alternativos para cada tarefa de execução da migração, para se salvaguardar contra problemas imprevistos que possam ocorrer durante o processo de migração. As tarefas de alternativa dependem normalmente da estratégia de migração e das ferramentas usadas.

A alternativa pode exigir um esforço significativo. Como prática recomendada, não faça a mudança para produção até que os resultados do teste sejam satisfatórios. A migração da base de dados e o cenário alternativo devem ser devidamente testados para evitar uma interrupção grave.

Defina critérios de sucesso e limite o tempo de todas as tarefas de execução da migração. A realização de um teste de migração ajuda a recolher informações sobre os tempos esperados para cada tarefa. Por exemplo, para uma migração de manutenção agendada, pode permitir o tempo de inatividade representado pela janela de transição. No entanto, é importante planear a sua próxima ação caso a tarefa de migração única ou o restauro da cópia de segurança falhe a meio. Consoante o tempo de inatividade planeado que já passou, pode ter de adiar a migração se a tarefa de migração não terminar no tempo esperado.

Normalmente, um plano de contingência refere-se à reversão da migração após a mudança de produção, se surgirem problemas na instância de destino. Se implementar um plano alternativo, lembre-se de que tem de ser tratado como uma migração completa da base de dados, incluindo o planeamento e os testes.

Se optar por não ter um plano alternativo, certifique-se de que compreende as possíveis consequências. Não ter um plano alternativo pode exigir um esforço imprevisto e causar interrupções evitáveis no processo de migração.

Embora uma alternativa seja um último recurso e a maioria das migrações de bases de dados não a use, recomendamos que tenha sempre uma estratégia alternativa.

Alternativa simples

Nesta estratégia alternativa, volta a mudar as suas aplicações para a instância da base de dados de origem. Adote esta estratégia se puder permitir tempo de inatividade quando reverter ou se não precisar das transações confirmadas no novo sistema de destino.

Se precisar de todos os dados escritos na base de dados de destino e puder tolerar algum tempo de inatividade, pode considerar parar as escritas na instância da base de dados de destino, fazer cópias de segurança incorporadas e restaurá-las na instância de origem e, em seguida, voltar a ligar as suas aplicações à instância da base de dados de origem inicial. Consoante a natureza da sua carga de trabalho e a quantidade de dados escritos na instância da base de dados de destino, pode transferi-los para o sistema de base de dados de origem inicial mais tarde, especialmente se as suas cargas de trabalho não dependerem de uma hora de criação de registo específica nem de restrições de ordenação cronológica.

Replicação inversa

Nesta estratégia, replica as escritas que ocorrem na nova base de dados de destino após a mudança de produção para a base de dados de origem inicial. Desta forma, mantém a origem original sincronizada com a nova base de dados de destino e tem as gravações a ocorrer na nova instância da base de dados de destino. A sua principal desvantagem é que não pode testar o fluxo de replicação até mudar para a instância da base de dados de destino. Por isso, não permite testes ponto a ponto e tem um pequeno período sem alternativa.

Escolha esta abordagem quando ainda puder manter a instância de origem durante algum tempo e migrar através da migração de replicação contínua.

Replicação para a frente

Esta estratégia é uma variação da replicação inversa. Replica as escritas na nova base de dados de destino numa instância de base de dados de terceiros à sua escolha. Pode direcionar as suas aplicações para esta base de dados de terceiros, que se liga ao servidor e executa consultas de leitura apenas enquanto o servidor estiver indisponível. Pode usar qualquer mecanismo de replicação, consoante as suas necessidades. A vantagem desta abordagem é que pode ser totalmente testada ponto a ponto.

Adote esta abordagem quando quiser ter uma alternativa em qualquer altura ou quando tiver de rejeitar a base de dados de origem inicial pouco depois da mudança para produção.

Escritas duplicadas

Se escolher uma estratégia de migração de microsserviços de Y (escrita e leitura) ou de acesso aos dados, este plano alternativo já está definido. Esta estratégia é mais complicada, porque tem de refatorar as aplicações ou desenvolver ferramentas que se ligam às instâncias da base de dados.

As suas aplicações escrevem nas instâncias de base de dados de origem e de destino iniciais, o que lhe permite fazer uma transição gradual para produção até usar apenas as instâncias de base de dados de destino. Se existirem problemas, pode voltar a associar as suas aplicações à origem inicial sem tempo de inatividade. Pode rejeitar a origem inicial e o mecanismo de escrita duplicado quando considerar que a migração foi realizada sem problemas.

Recomendamos esta abordagem quando é fundamental não ter tempo de inatividade de migração, ter uma alternativa fiável e quando tem tempo e recursos para refatorar a aplicação.

Realize testes e validação

Os objetivos deste passo são testar e validar o seguinte:

• Migração bem-sucedida dos dados na base de dados.
• Integração com aplicações existentes depois de serem mudadas para usar a nova instância de destino.

Defina os principais fatores de sucesso, que são subjetivos à sua migração. Seguem-se alguns exemplos de fatores subjetivos:

• Que dados migrar. Para algumas cargas de trabalho, pode não ser necessário migrar todos os dados. Pode não querer migrar dados que já estão agregados, são redundantes, estão arquivados ou são antigos. Pode arquivar esses dados num contentor do Cloud Storage como cópia de segurança.
• Uma percentagem aceitável de perda de dados. Isto aplica-se particularmente aos dados usados para cargas de trabalho de estatísticas, em que a perda de parte dos dados não afeta as tendências gerais nem o desempenho das suas cargas de trabalho.
• Critérios de qualidade e quantidade de dados, que pode aplicar ao seu ambiente de origem e comparar com o ambiente de destino após a migração.
• Critérios de desempenho. Algumas transações empresariais podem ser mais lentas no ambiente de destino, mas o tempo de processamento continua dentro das expetativas definidas.

As configurações de armazenamento no seu ambiente de origem podem não ser mapeadas diretamente para os Google Cloud alvos de ambiente. Por exemplo, configurações dos volumes de SSD de uso geral (gp2 e gp3) com desempenho de picos de IOPS ou SSD de IOPS aprovisionados. Para comparar e dimensionar corretamente as instâncias de destino, faça testes de referência das instâncias de origem nas fases de avaliação e validação.

No processo de testes de referência, aplica sequências de operações semelhantes à produção às instâncias da base de dados. Durante este período, captura e processa métricas para medir e comparar o desempenho relativo dos sistemas de origem e de destino.

Para configurações convencionais baseadas no servidor, use medições relevantes observadas durante os picos de carga. Para modelos de capacidade de recursos flexíveis, como o Aurora Serverless, considere analisar os dados do histórico de métricas para observar as suas necessidades de dimensionamento.

As seguintes ferramentas podem ser usadas para testes, validação e testes de desempenho de bases de dados:

• HammerDB: uma ferramenta de testes de carga e de benchmark de base de dados de código aberto. Suporta cargas de trabalho transacionais e analíticas complexas, baseadas nas normas da indústria, em vários motores de base de dados (TPROC-C e TPROC-H). O HammerDB tem documentação detalhada e uma vasta comunidade de utilizadores. Pode partilhar e comparar resultados em vários motores de base de dados e configurações de armazenamento. Para mais informações, consulte os artigos Teste de carga do SQL Server com o HammerDB e Benchmark do desempenho do SQL Server do Amazon RDS com o HammerDB.
• Ferramenta de referência DBT2: referências especializadas para o MySQL. Um conjunto de kits de carga de trabalho de base de dados imita uma aplicação para uma empresa proprietária de armazéns e envolve uma combinação de transações de leitura e escrita. Use esta ferramenta se quiser usar um teste de carga de processamento de transações online (OLTP) pronto a usar.
• DbUnit: uma ferramenta de testes unitários de código aberto usada para testar interações de bases de dados relacionais em Java. A configuração e a utilização são simples e suporta vários motores de base de dados (MySQL, PostgreSQL, SQL Server e outros). No entanto, a execução do teste pode ser lenta por vezes, dependendo do tamanho e da complexidade da base de dados. Recomendamos esta ferramenta quando a simplicidade é importante.
• DbFit: uma framework de testes de base de dados de código aberto que suporta o desenvolvimento de código orientado por testes e testes automatizados. Usa uma sintaxe básica para criar exemplos de teste e inclui testes baseados em dados, controlo de versões e relatórios de resultados de testes. No entanto, o suporte para consultas e transações complexas é limitado e não tem um grande suporte da comunidade nem documentação extensa, em comparação com outras ferramentas. Recomendamos esta ferramenta se as suas consultas não forem complexas e quiser realizar testes automatizados e integrá-los no seu processo de integração e entrega contínuas.

Para executar um teste ponto a ponto, incluindo testes do plano de migração, faça sempre um exercício de simulação de migração. Uma execução de teste faz a migração da base de dados de âmbito total sem mudar nenhuma carga de trabalho de produção e oferece as seguintes vantagens:

• Permite-lhe garantir que todos os objetos e configurações são migrados corretamente.
• Ajuda a definir e executar os seus exemplos de testes de migração.
• Oferece estatísticas sobre o tempo necessário para a migração real, para que possa calibrar a sua linha cronológica.
• Representa uma oportunidade para testar, validar e adaptar o plano de migração. Por vezes, não é possível planear tudo antecipadamente, pelo que esta funcionalidade ajuda a detetar eventuais lacunas.

Os testes de dados podem ser realizados num pequeno conjunto das bases de dados a migrar ou no conjunto completo. Consoante o número total de bases de dados e as ferramentas usadas para implementar a respetiva migração, pode optar por adotar uma abordagem baseada no risco. Com esta abordagem, realiza a validação de dados num subconjunto de bases de dados migradas através da mesma ferramenta, especialmente se esta ferramenta for um serviço de migração gerido.

Para testar, deve ter acesso às bases de dados de origem e de destino e realizar as seguintes tarefas:

• Compare os esquemas de origem e de destino. Verifique se existem todas as tabelas e ficheiros executáveis. Verifique as contagens de linhas e compare os dados ao nível da base de dados.
• Executar scripts de validação de dados personalizados.
• Teste se os dados migrados também estão visíveis nas aplicações que mudaram para usar a base de dados de destino (os dados migrados são lidos através da aplicação).
• Realize testes de integração entre as aplicações comutadas e a base de dados de destino testando vários exemplos de utilização. Este teste inclui a leitura e a gravação de dados nas bases de dados de destino através das aplicações, para que as cargas de trabalho suportem totalmente os dados migrados juntamente com os dados recém-criados.
• Teste o desempenho das consultas de base de dados mais usadas para observar se existe alguma degradação devido a configurações incorretas ou dimensionamento errado.

Idealmente, todos estes cenários de teste de migração são automatizados e repetíveis em qualquer sistema de origem. O conjunto de testes automatizados é adaptado para ser executado em relação às aplicações comutadas.

Se estiver a usar o Database Migration Service como ferramenta de migração, consulte o artigo Validar uma migração.

Ferramenta de validação de dados

Para realizar a validação de dados, recomendamos que use a ferramenta de validação de dados (DVT). A DVT é uma ferramenta de CLI Python de código aberto, suportada pela Google, que oferece uma solução automatizada e repetível para validação em diferentes ambientes.

A DVT pode ajudar a simplificar o processo de validação de dados, oferecendo funções de validação personalizadas de vários níveis para comparar tabelas de origem e de destino ao nível da tabela, da coluna e da linha. Também pode adicionar regras de validação.

O DVT abrange muitas Google Cloud origens de dados, incluindo o AlloyDB para PostgreSQL, o BigQuery, o Cloud SQL, o Spanner, o JSON e os ficheiros CSV no Cloud Storage. Também pode ser integrado com funções do Cloud Run e o Cloud Run para acionamento e organização baseados em eventos.

O DVT suporta os seguintes tipos de validações:

• Comparações ao nível do esquema
• Coluna (incluindo "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
• Linha (incluindo hash e correspondência exata nas comparações de campos)
• Comparação dos resultados de consultas personalizadas

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 da Google Cloud.

Faça a migração

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

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

• Informar as equipas envolvidas sempre que um passo do plano começar e terminar.
• Se algum dos passos demorar mais do que o esperado, compare o tempo decorrido com o tempo máximo atribuído a esse passo. Emitir atualizações intermediárias regulares às equipas envolvidas quando isto acontecer.
• Se o intervalo de tempo for superior ao tempo máximo reservado para cada passo no plano, considere reverter.
• Tome decisões de "aprovar ou rejeitar" para cada passo do plano de migração e transição.
• Considere ações de reversão ou cenários alternativos para cada um dos passos.

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

Faça a mudança para produção

O processo de transição de produção de alto nível pode diferir consoante a estratégia de migração escolhida. Se puder ter tempo de inatividade nas suas cargas de trabalho, a mudança da migração começa com a interrupção das gravações na base de dados de origem.

Para migrações de replicação contínua, normalmente, segue os seguintes passos gerais no processo de transferência:

• Pare de escrever na base de dados de origem.
• Esvazie a fonte.
• Pare o processo de replicação.
• Implemente as aplicações que apontam para a nova base de dados de destino.

Depois de os dados terem sido migrados através da ferramenta de migração escolhida, valide os dados na base de dados de destino. Confirma que a base de dados de origem e as bases de dados de destino estão sincronizadas e que os dados na instância de destino cumprem as normas de êxito da migração escolhidas.

Assim que a validação de dados cumprir os seus critérios, pode fazer a mudança ao nível da aplicação. Implemente as cargas de trabalho que foram refatoradas para usar a nova instância de destino. Implementa as versões das suas aplicações que apontam para a instância da base de dados de destino. As implementações podem ser realizadas através de atualizações contínuas, lançamentos faseados ou usando um padrão de implementação azul-verde. Pode ocorrer alguma indisponibilidade da aplicação.

Siga as práticas recomendadas para a mudança de produção:

• Monitorize as suas aplicações que funcionam com a base de dados de destino após a mudança.
• Defina um período de monitorização para considerar se precisa ou não de implementar o plano de alternativos.
• Tenha em atenção que a sua instância do Cloud SQL ou do AlloyDB for PostgreSQL pode ter de ser reiniciada se alterar algumas flags da base de dados.
• Tenha em atenção que o esforço de reverter a migração pode ser superior ao de corrigir os problemas que aparecem no ambiente de destino.

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

Após a conclusão da mudança, pode eliminar as bases de dados de origem. Recomendamos que execute as seguintes ações importantes antes da limpeza da instância de origem:

• Crie uma cópia de segurança final de cada base de dados de origem. Estas cópias de segurança oferecem-lhe um estado final das bases de dados de origem. As cópias de segurança também podem ser necessárias em alguns casos para agir em conformidade com alguns regulamentos de dados.

• Recolha as definições dos parâmetros da base de dados da sua instância de origem. Em alternativa, verifique se correspondem aos que reuniu na fase de criação do inventário. Ajuste os parâmetros da instância de destino para corresponderem aos da instância de origem.

• Recolha estatísticas da base de dados da instância de origem e compare-as com as da instância de destino. Se as estatísticas forem díspares, é difícil comparar o desempenho da instância de origem e da instância de destino.

Num cenário de alternativa, pode querer implementar a replicação das suas escritas na instância do Cloud SQL de volta à base de dados de origem original. A configuração é semelhante ao processo de migração, mas é executada ao contrário: a base de dados de origem inicial torna-se o novo destino.

Como prática recomendada para manter as instâncias de origem atualizadas após a mudança, replique as gravações realizadas nas instâncias do Cloud SQL de destino de volta para a base de dados de origem. Se precisar de reverter, pode voltar às instâncias de origem antigas com uma perda de dados mínima.

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

• Configure um período de manutenção para a sua instância principal para controlar quando podem ocorrer atualizações disruptivas.
• Configure o armazenamento na instância para ter, pelo menos, 20% de espaço disponível para acomodar quaisquer operações de manutenção críticas da base de dados que o Cloud SQL possa realizar. Para receber um alerta se o espaço em disco disponível for inferior a 20%, crie uma política de alertas baseada em métricas para a métrica de utilização do disco.

Não inicie uma operação administrativa antes de a operação anterior estar concluída.

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

Otimize o seu ambiente após a migração

A otimização é a última fase da migração. Nesta fase, itera nas tarefas de otimização até que o ambiente de destino cumpra os requisitos de otimização. Os passos de cada iteração são os seguintes:

1. Avalie o seu ambiente, equipas e ciclo de otimização atuais.
2. Estabeleça os seus requisitos e objetivos de otimização.
3. Otimize o seu ambiente e as suas equipas.
4. Ajuste o ciclo de otimização.

Repete esta sequência até atingir os seus objetivos de otimização.

Para mais informações sobre a otimização do seu Google Cloud ambiente, consulte Migrar para Google Cloud: otimize o seu ambiente e Google Cloud Framework bem arquitetado: otimização do desempenho.

Estabeleça os seus requisitos de otimização

Reveja os seguintes requisitos de otimização para o seu Google Cloud ambiente e escolha os que melhor se adequam às suas cargas de trabalho:

Aumente a fiabilidade e a disponibilidade da sua base de dados

Com o Cloud SQL, pode implementar uma estratégia de alta disponibilidade e recuperação de desastres que se alinha com o seu objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para aumentar a fiabilidade e a disponibilidade, considere o seguinte:

• Em casos de cargas de trabalho com muitas leituras, adicione réplicas de leitura para descarregar o tráfego da instância principal.
• Para cargas de trabalho críticas, use a configuração de alta disponibilidade, réplicas para a comutação por falha regional e uma configuração de recuperação de desastres robusta.
• Para cargas de trabalho menos críticas, as cópias de segurança automatizadas e a pedido podem ser suficientes.
• Para evitar a remoção acidental de instâncias, use a proteção de eliminação de instâncias.
• Considere usar a edição Cloud SQL Enterprise Plus para beneficiar de maior disponibilidade, retenção de registos e manutenção planeada com tempo de inatividade quase nulo. Para mais informações sobre o Cloud SQL Enterprise Plus, consulte Introdução às edições do Cloud SQL e Manutenção planeada com tempo de inatividade quase nulo.

Para mais informações sobre como aumentar a fiabilidade e a disponibilidade da sua base de dados, consulte o seguinte:

• Promova réplicas para migração regional ou recuperação de desastres
• Recuperação de desastres da base de dados do Cloud SQL
• Acerca das cópias de segurança do Cloud SQL
• Impeça a eliminação da documentação de uma instância

Aumentar a rentabilidade da sua infraestrutura de base de dados

Para ter um impacto económico positivo, as suas cargas de trabalho têm de usar os recursos e os serviços disponíveis de forma eficiente. Considere as seguintes opções:

• Forneça à base de dados a capacidade de armazenamento mínima necessária fazendo o seguinte:

  • Para dimensionar automaticamente a capacidade de armazenamento à medida que os dados aumentam, ative os aumentos automáticos de armazenamento. No entanto, certifique-se de que configura as instâncias para terem alguma margem de segurança nos volumes de trabalho de pico. Lembre-se de que as cargas de trabalho da base de dados tendem a aumentar ao longo do tempo.

• Identifique possíveis recursos sobrestimados:

  • Ajustar o tamanho das instâncias do Cloud SQL pode reduzir o custo da infraestrutura sem adicionar riscos adicionais à estratégia de gestão da capacidade.
  • O Cloud Monitoring oferece painéis de controlo predefinidos que ajudam a identificar o estado de funcionamento e a utilização da capacidade de muitos Google Cloud componentes, incluindo o Cloud SQL. Para ver detalhes, consulte o artigo Crie e faça a gestão de painéis de controlo personalizados.

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

• Remova tabelas e objetos que já não sejam necessários. Pode armazená-los numa cópia de segurança completa ou num contentor de arquivo do Cloud Storage.

• Avalie o tipo de armazenamento mais rentável (SSD ou HDD) para o seu exemplo de utilização.

  • Para a maioria dos exemplos de utilização, o SSD é a escolha mais eficiente e rentável.
  • Se os seus conjuntos de dados forem grandes (10 TB ou mais), insensíveis à latência ou acedidos com pouca frequência, o HDD pode ser mais adequado.
  • Para ver detalhes, consulte o artigo Escolha entre o armazenamento SSD e HDD.

• Compre descontos de fidelidade para cargas de trabalho com necessidades de recursos previsíveis.

• Use o Active Assist para receber estatísticas e recomendações de custos.

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

Aumente o desempenho da sua infraestrutura de base de dados

Os problemas de desempenho menores relacionados com a base de dados têm frequentemente o potencial de afetar toda a operação. Para manter e aumentar o desempenho da sua instância do Cloud SQL, considere as seguintes diretrizes:

• Se tiver um grande número de tabelas de base de dados, estas podem afetar o desempenho e a disponibilidade da instância, e fazer com que a instância perca a respetiva cobertura do SLA.

• Certifique-se de que a sua instância não tem restrições de memória ou CPU.

  • Para cargas de trabalho com utilização intensiva do desempenho, certifique-se de que a instância tem, pelo menos, 60 GB de memória.
  • Para inserções, atualizações ou eliminações lentas na base de dados, verifique as localizações do escritor e da base de dados. O envio de dados a longas distâncias introduz latência.

• Melhore o desempenho das consultas através do painel de controlo Estatísticas de consultas predefinido no Cloud Monitoring (ou funcionalidades incorporadas semelhantes do motor de base de dados). Identifique os comandos mais caros e tente otimizá-los.

• Impedir que os ficheiros da base de dados se tornem desnecessariamente grandes. Defina autogrow em MBs em vez de como uma percentagem, usando incrementos adequados ao requisito.

• Verifique a localização do leitor e da base de dados. A latência afeta o desempenho de leitura mais do que o desempenho de escrita.

• Pondere usar a edição Cloud SQL Enterprise Plus para beneficiar de limites de configuração da máquina e cache de dados aumentados. 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".

Aumente as capacidades de observabilidade da base de dados

Diagnosticar e resolver problemas em aplicações que se ligam a instâncias de bases de dados pode ser desafiador e demorado. Por este motivo, é essencial ter um local centralizado onde todos os membros da equipa possam ver o que está a acontecer ao nível da base de dados e da instância. Pode monitorizar as instâncias do Cloud SQL das seguintes formas:

• O Cloud SQL usa agentes personalizados de memória incorporados para recolher telemetria de consultas.

  • Use o Cloud Monitoring para recolher medições do seu serviço e dos Google Cloud recursos que usa. O Cloud Monitoring inclui painéis de controlo predefinidos para vários Google Cloud produtos, incluindo um painel de controlo de monitorização do Cloud SQL.
  • Pode criar painéis de controlo personalizados que ajudam a monitorizar as métricas e configurar políticas de alerta para receber notificações atempadas.
  • Em alternativa, pode ponderar usar soluções de monitorização de terceiros integradas com Google Cloud, como o Datadog e o Splunk.

• O Cloud Logging recolhe dados de registo de componentes de aplicações comuns.

• O Cloud Trace recolhe dados de latência e planos de consultas executados a partir de aplicações para ajudar a monitorizar a forma como os pedidos se propagam através da sua aplicação.

• O Database Center oferece uma vista geral da frota de bases de dados centralizada e assistida por IA. Pode monitorizar o estado das suas bases de dados, a configuração de disponibilidade, a proteção de dados, a segurança e a conformidade com a indústria.

Práticas recomendadas gerais e diretrizes operacionais do Cloud SQL

Aplique as práticas recomendadas para o Cloud SQL para configurar e otimizar a base de dados.

Seguem-se algumas recomendações gerais importantes do Cloud SQL:

• Se tiver instâncias grandes, recomendamos que as divida em instâncias mais pequenas, sempre que possível.
• Configure o armazenamento para acomodar a manutenção crítica da base de dados. Certifique-se de que tem, pelo menos, 20% de espaço disponível para acomodar quaisquer operações de manutenção críticas da base de dados que o Cloud SQL possa realizar.
• Ter demasiadas tabelas de base de dados pode afetar o tempo de atualização da base de dados. Idealmente, procure ter menos de 10 000 tabelas por instância.
• Escolha o tamanho adequado para as suas instâncias de forma a ter em conta a retenção de registos de transações (binários), especialmente para instâncias com atividade de escrita elevada.

Para poder resolver de forma eficiente quaisquer problemas de desempenho da base de dados que possa encontrar, use as seguintes diretrizes até que o problema seja resolvido:

Aumente a escala da infraestrutura: aumente os recursos (como o débito do disco, a vCPU e a RAM). Consoante a urgência e a disponibilidade e a experiência da sua equipa, a escalabilidade vertical da instância pode resolver a maioria dos problemas de desempenho. Posteriormente, pode investigar mais aprofundadamente a causa principal do problema num ambiente de teste e considerar opções para o eliminar.

Realizar e agendar operações de manutenção da base de dados: desfragmentação de índices, atualizações de estatísticas, análise de vácuo e reindexação de tabelas muito atualizadas. Verifique se e quando estas operações de manutenção foram realizadas pela última vez, especialmente nos objetos afetados (tabelas, índices). Descubra se houve uma alteração nas atividades normais da base de dados. Por exemplo, adicionar recentemente uma nova coluna ou ter muitas atualizações numa tabela.

Realize o ajuste e a otimização da base de dados: as tabelas na sua base de dados estão estruturadas corretamente? As colunas têm os tipos de dados corretos? O seu modelo de dados é adequado para o tipo de carga de trabalho? Investigue as consultas lentas e os respetivos planos de execução. Estão a usar os índices disponíveis? Verifique se existem verificações de índice, bloqueios e esperas noutros recursos. Pondere adicionar índices para suportar as suas consultas críticas. Elimine índices não críticos e chaves externas. Considere reescrever consultas e uniões complexas. O tempo necessário para resolver o seu problema depende da experiência e da disponibilidade da sua equipa, e pode variar entre horas e dias.

Aumente a escala das suas leituras: considere ter réplicas de leitura. Quando a escalabilidade vertical não é suficiente para as suas necessidades e as medidas de otimização e ajuste da base de dados não ajudam, considere a escalabilidade horizontal. O encaminhamento de consultas de leitura das suas aplicações para uma réplica de leitura melhora o desempenho geral da carga de trabalho da base de dados. No entanto, pode ser necessário um esforço adicional para alterar as suas aplicações de modo a estabelecer ligação à réplica de leitura.

Reestruturação da base de dados: considere a partição e a indexação da base de dados. Esta operação requer um esforço significativamente maior do que o ajuste e a otimização da base de dados e pode envolver uma migração de dados, mas pode ser uma solução a longo prazo. Por vezes, um mau design do modelo de dados pode originar problemas de desempenho, que podem ser parcialmente compensados por um aumento vertical. No entanto, um modelo de dados adequado é uma solução a longo prazo. Considere particionar as tabelas. Arquive os dados que já não são necessários, se possível. Normalizar a estrutura da base de dados, mas lembrar-se de que a desnormalização também pode melhorar o desempenho.

Partição da base de dados: pode aumentar a escala das suas gravações dividindo a base de dados. A divisão em partições é uma operação complicada e envolve a reestruturação da base de dados e das aplicações de uma forma específica, bem como a execução da migração de dados. Divide a instância da base de dados em várias instâncias mais pequenas através de critérios de partição específicos. Os critérios podem basear-se no cliente ou no assunto. Esta opção permite-lhe dimensionar horizontalmente as suas gravações e leituras. No entanto, aumenta a complexidade da sua base de dados e cargas de trabalho da aplicação. Também pode levar a fragmentos desequilibrados denominados pontos críticos, o que superaria a vantagem da fragmentação. - Especificamente para o Cloud SQL para MySQL, certifique-se de que as suas tabelas têm uma chave principal ou única. O Cloud SQL usa a replicação baseada em linhas, que funciona melhor em tabelas com chaves principais ou únicas.

Para mais detalhes, consulte as práticas recomendadas gerais e as diretrizes operacionais para o Cloud SQL para MySQL.

O que se segue?

• Leia acerca de outras migrações da AWS para Google Cloud .
• Saiba como comparar os serviços da AWS e do Azure com os serviços Google Cloud Google Cloud.
• Saiba quando encontrar ajuda para as suas migrações.
• Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.

Colaboradores

Autores:

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

Outros colaboradores:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Redator técnico
• Matthew Smith | Engenheiro estratégico da nuvem
• Somdyuti Paul | Data Management Specialist
• Zach Seils | Especialista em redes