Migrar da AWS para o Google Cloud: migrar do Amazon RDS para SQL Server para o Cloud SQL para SQL Server

Last reviewed 2024-06-28 UTC

O Google Cloud fornece ferramentas, produtos, orientações e serviços profissionais para migrar do Amazon Relational Database Service (RDS) para o Cloud SQL para SQL Server.

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

Este documento se concentra em uma migração homogênea do banco de dados, que é uma migração em que os bancos de dados de origem e de destino têm a mesma tecnologia. A origem é o Amazon RDS para SQL Server e o destino é o Cloud SQL para SQL Server.

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

• Primeiros passos
• Migrar do Amazon EC2 para o Compute Engine
• Migrar do Amazon S3 para o Cloud Storage
• Migrar do Amazon EKS para o GKE
• Migrar da AWS para o Google Cloud: migre do Amazon RDS para SQL Server para o Cloud SQL para SQL Server (este documento)

Esta série presume que você leu e está familiarizado com os seguintes documentos:

• Migrar para o Google Cloud: primeiros passos: descreve o framework geral de migração que você segue nesta migração.
• Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração: descreve possíveis alterações e melhorias no plano de migração.

No diagrama a seguir, confira o caminho da sua jornada de migração. Em cenários de migração, a fase de implantação é equivalente a executar um processo de migração.

É possível migrar do Amazon RDS para o Cloud SQL em uma série de iterações como, por exemplo, é possível migrar algumas instâncias do banco de dados primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral do Compute Engine, que são:

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

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

Avaliar o ambiente de origem

Na fase de avaliação, você determina os requisitos e as dependências dos recursos que serão migrados.

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

1. Criar um inventário abrangente das suas cargas de trabalho.
2. Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
3. Treinar e instruir suas equipes sobre o Google Cloud, incluindo práticas recomendadas de bancos de dados.
4. Criar experimentos e provas de conceito no Google Cloud.
5. Calcular o custo total de propriedade (TCO) do ambiente de destino.
6. Decidir a ordem e a prioridade das cargas de trabalho que você quer migrar.

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

Para mais informações sobre a fase de avaliação e essas tarefas, consulte Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho. As seções a seguir são baseadas nas informações deste documento.

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

Para definir o escopo da migração, crie um inventário e colete informações sobre suas instâncias do Amazon RDS. Idealmente, o processo deve ser automatizado, porque as abordagens manuais são propensas a erros e podem levar a suposições incorretas.

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

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

Ferramentas para avaliações

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Considere como concluir as seguintes tarefas:

• Definir e aplicar políticas de segurança para as instâncias: por exemplo, talvez seja necessário substituir o Amazon Security Groups. É possível usar os papéis do Google IAM, regras de firewall de VPC e o VPC Service Controls para controlar o acesso às instâncias do Cloud SQL e restringir dados em uma VPC. Se pretende usar a autenticação do Windows com o Cloud SQL para SQL Server, implante o Microsoft AD gerenciado e conecte-o a infraestrutura atual do Active Directory.
• Corrigir e configurar as instâncias: ferramentas de implantação atuais que talvez precisem ser atualizadas. Por exemplo, talvez você esteja usando a configuração personalizada em grupos de parâmetros ou grupos de opções da Amazon. Talvez seja necessário adaptar as ferramentas de provisionamento para usar o Google Cloud Storage ou o Secret Manager para ler essas listas de configuração personalizadas.
• Gerenciar a infraestrutura de monitoramento e alertas: as categorias de métricas das instâncias do banco de dados de origem da Amazon oferecem observabilidade durante o processo de migração. As categorias de métricas podem incluir o Amazon CloudWatch, insights de desempenho, monitoramento avançado e listas de processos de SO.

Concluir a avaliação

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

Planejar e criar sua base

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

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

Criar sua base no Google Cloud

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

1. Criar uma hierarquia de recursos.
2. Configurar o gerenciamento de identidade e acesso.
3. Configurar o faturamento.
4. Configurar a conectividade de rede.
5. Aumentar sua segurança.
6. Configurar a geração de registros, o monitoramento e os alertas.

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

Monitoramento e alertas

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

Migrar instâncias do Amazon RDS para SQL Server para o Cloud SQL para SQL Server

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

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

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

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

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

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

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

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

8. Execute a migração.

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

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

11. Realize ajustes e a otimização.

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

Escolher a estratégia de migração

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Escolher as ferramentas de migração

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

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

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

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

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

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

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

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

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

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

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

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

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

Backups de mecanismo de banco de dados integrados

Quando um tempo de inatividade significativo for aceitável e os bancos de dados de origem estiverem relativamente estáticos, é possível usar os recursos de backup e restauração integrados do mecanismo do banco de dados.

A configuração e a sincronização podem levar algum tempo, especialmente para um grande número de bancos de dados, mas os backups do mecanismo de banco de dados geralmente estão disponíveis e são fáceis de usar. Essa abordagem é adequada para qualquer tamanho de banco de dados. Ela costuma ser mais eficaz do que outras ferramentas para instâncias grandes.

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

• Os backups podem estar propensos a erros, especialmente se forem feitos manualmente.
• Os dados não estarão protegidos se os backups não forem gerenciados adequadamente.
• Os backups não têm recursos de monitoramento adequados.

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

• Para backups de bancos de dados maiores que 5 TB, use um backup distribuído (um backup de vários arquivos).
• Ao usar um backup distribuído, não é possível fazer backup ou restaurar mais de 10 arquivos de backup ao mesmo tempo.
• Você precisa fazer backup em um bucket do Amazon S3 na mesma região do Amazon da instância do banco de dados de origem.
• Os backups não incluem registros, permissões e servidores do SQL Server, porque estão situados no nível da instância. Para transferir esse tipo de dados da instância de origem para a instância de destino, use os scripts ou ferramentas do PowerShell, como o DBAtools.

Para mais detalhes sobre limitações e práticas recomendadas, consulte Práticas recomendadas para importar e exportar dados com o Cloud SQL para SQL Server e Problemas conhecidos do Cloud SQL para SQL Server.

Outras abordagens para migrações de manutenção programadas

Usar outras abordagens pode fornecer mais controle e flexibilidade na manutenção programada do processo de migração.

Por exemplo, com o uso de arquivos simples para exportar e importar dados (ou o uso de scripts), é possível:

• Fazer transformações, verificações ou outras operações nos dados durante a migração. Por exemplo, validações, agregação ou normalização e desnormalização dos dados de origem.
• Escolha quais estruturas você quer migrar e quais deixar para trás. Você pode extrair apenas um subconjunto das tabelas em arquivos simples para importação.
• Escolha filtrar os dados com base em domínio, origem, idade ou outros critérios personalizados. Por exemplo, exclua dados que atingem uma idade limite e armazene-os em arquivos ou no backup final da fonte de dados de destino antes da migração.
• Refatore as estruturas do banco de dados e sincronize os tempo de inatividades com o tempo de inatividade da migração.
• Consolide várias instâncias ou bancos de dados em uma única instância ou banco de dados para reduzir custos operacionais e facilitar os problemas de escalonabilidade. Por exemplo, talvez você queira mudar a abordagem de uma instância, banco de dados ou esquema por cliente para um único locatário com uma estrutura única de banco de dados otimizada para multilocação.

Outras abordagens incluem:

• Usar arquivos CSV ou JSON:com essa abordagem, extraia os dados do banco de dados para os arquivos. Em seguida, importe esses arquivos para as instâncias de destino.

  • Embora essa abordagem geralmente seja mais lenta, esse método ajuda a migrar um subconjunto de tabelas (ou dados dentro de uma determinada tabela).
  • Muitas ferramentas aceitam os formatos CSV e JSON.
  • Se automatizar o processo, terá a opção de fazer a transição para uma replicação contínua em lote.

• Usar o Assistente de importação e exportação do SQL Server da Microsoft: essa ferramenta usa o SQL Server Integration Services (SSIS) e permite importar dados de várias fontes, como outros mecanismos de banco de dados ou arquivos simples.

• Use o Assistente de geração e publicação de scripts do SQL Server e utilitário bcp: essa ferramenta faz parte do Microsoft SQL Server Management Studio.

  • Essa abordagem permite criar scripts para todo o esquema do banco de dados ou apenas partes dele.
  • O utilitário bcp permite criar um script dos dados e exportá-los para arquivos.

• Use a replicação de snapshot se a origem usar o Amazon RDS Standard:

  • Com essa abordagem, você restaura o backup do SQL Server da instância do RDS para outra instância autônoma do SQL Server no Compute Engine. Em seguida, use a replicação de snapshot para migrar para o Cloud SQL para SQL Server.
  • A geração de snapshots mantém bloqueios nas tabelas de origem, o que pode afetar as cargas de trabalho.
  • A replicação de snapshot pode introduzir cargas adicionais no servidor do Amazon RDS.
  • No entanto, você pode escolher quais objetos são migrados ou replicados, gerando a flexibilidade.
  • Por exemplo, consulte Como migrar dados do SQL Server 2017 para o Cloud SQL para SQL Server usando a replicação de snapshots.

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

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

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

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

  • Se a resposta for sim, vá para a próxima pergunta. Se você tiver um tempo de inatividade mínimo disponível e não precisar da transformação de dados, recomendamos o Database Migration Service. Caso contrário, explore opções de terceiros.
  • Se a resposta for não, vá para a próxima pergunta. Se o mecanismo de replicação integrada do banco de dados for compatível, recomendamos o uso da replicação integrada. Caso contrário, recomendamos outras opções de migração.

• Você tem um tempo de inatividade mínimo e pode migrar sem a transformação dos dados ou sincronização em tempo real?

  • Em caso afirmativo, recomendamos o Database Migration Service.
  • Se a resposta for não, use opções de terceiros.

• Há suporte para a replicação integrada específica do mecanismo de banco de dados?

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

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

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

O Database Migration Service oferece suporte a migrações homogêneas para o Cloud SQL para SQL Server quando a origem é o Amazon RDS.

O Database Migration Service é uma ferramenta econômica e simples. Recomendamos o Database Migration Service para situações nas seguintes circunstâncias:

• Você tem um tempo de inatividade mínimo.
• Você não precisa de sincronização em tempo real.
• Não é preciso fazer transformações de dados durante a migração.

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

• O tempo de inatividade depende da frequência do backup do log de transação.
• Os backups não incluem registros, permissões e servidores do SQL Server, porque estão situados no nível da instância. Faça um script com eles na instância de origem e, em seguida, transfira-os para a instância de destino usando scripts ou ferramentas do PowerShell, como o DBAtools.

Para acessar uma lista completa de limitações, consulte Limitações conhecidas.

Replicação integrada do mecanismo de banco de dados

O Cloud SQL oferece suporte à replicação do SQL Server. No entanto, o Standard Amazon RDS para SQL Server só pode ser um assinante. A replicação integrada do Amazon RDS Standard não está disponível. Somente o Amazon RDS Custom para SQL Server pode ser configurado como um publisher integrado.

Para uma lista de recursos compatíveis e não compatíveis no Amazon RDS, consulte Amazon RDS para Microsoft SQL Server:

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

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

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

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

• Implemente funções que consultam dados periodicamente na instância de origem, filtre apenas dados novos e salve os dados em CSV, JSON ou Parquet.

  • Os arquivos são armazenados em um bucket do Google Cloud Storage.
  • Os arquivos podem ser gravados imediatamente na instância do banco de dados de destino usando o Cloud Functions.
  • A captura de dados alterados (CDC) podem ajudar a realizar uma migração de replicação quase em tempo real.
  • Você pode fazer um streaming do CDC para um data lake do Amazon S3 no formato Parquet; usando o AWS Database Migration Service (AWS DMS).
  • É possível ter uma implementação personalizada para ler os arquivos e salvar o conteúdo deles no Cloud SQL.

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

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

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

• Vantagens:

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

• Desvantagens:

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

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

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

• Vantagens:

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

• Desafios:

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

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

Definir o plano e o cronograma de migração

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

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

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

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

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

TDD

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

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

Matriz RACI

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

Cronograma

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

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

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

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

Um plano T-Minus pode ser:

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

Várias migrações de banco de dados

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

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

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

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

Definir as tarefas de preparação

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

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

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

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

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

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

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

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

• Para uma replicação contínua (streaming de alterações pelo CDC), use uma instância RDS completa e não uma réplica de leitura, com CDC ativado. Para mais informações, consulte Usar a captura de dados alterados com o SQL Server.

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

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

• Verifique se o banco de dados de origem tem armazenamento em buffer e memória disponível durante as operações de migração. Por exemplo, se estiver usando arquivos de backup de log de transações, monitore o uso do armazenamento e tenha um espaço de armazenamento de buffer adicional.
• Documente as configurações dos parâmetros do banco de dados e aplique-as na instância de destino antes de fazer o teste e a validação da migração.

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

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

Configuração do Cloud SQL

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

Confira se o destino é o ajuste correto. As opções de configuração do Amazon RDS podem ser diferentes do Cloud SQL. Caso o Cloud SQL não atenda aos requisitos, considere as opções que incluem bancos de dados no Compute Engine.

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

• Escolha o projeto e a região das instâncias de destino do Cloud SQL com cuidado. As instâncias do Cloud SQL não podem ser migradas entre projetos e regiões do Google Cloud sem a transferência de dados.

• Migrar para uma versão principal correspondente no Cloud SQL. Por exemplo: se a origem usa o SQL Server 15.0, migre para o Cloud SQL para SQL Server 15.0. Se as versões forem diferentes, a configuração do nível de compatibilidade precisará ser a mesma para garantir os mesmos recursos do mecanismo.

• Replique as informações dos usuários separadamente se você estiver usando o mecanismo de banco de dados integrado ou o Database Migration Service. Para mais detalhes, consulte as limitações na seção Backups específicos do mecanismo de banco de dados.

• Analise as sinalizações de configuração específicas do mecanismo de banco de dados e compare os valores das instâncias de origem e de destino. Entenda os impactos e se eles precisam ser iguais ou não. Por exemplo, recomendamos comparar os valores na visualização sys.configurations no banco de dados de origem com os valores no banco de dados da instância do Cloud SQL. Nem todas as flags precisam ser iguais e nem todas flags alteradas são permitidas em uma instância do Cloud SQL.

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

• Práticas recomendadas gerais para o SQL Server
• Opções de configuração de instância do SQL Server
• Flags específicas do mecanismo de banco de dados para o SQL Server

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

Se você usa a exportação e a importação de arquivos para migrar ou usa a ferramenta de migração do Database Migration Service, crie um bucket do Cloud Storage. O bucket armazena arquivos de backup do log de transações e do banco de dados. Para mais informações sobre como usar o Database Migration Service, consulte Armazenar arquivos de backup em um bucket do Cloud Storage.

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

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

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

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

Definir as tarefas de execução

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

Backups específicos do mecanismo do banco de dados

Para mais informações e instruções sobre backups específicos de bancos de dados, consulte Importar dados de um arquivo BAK para o Cloud SQL para SQL Server e Como exportar dados do RDS para SQL Server Para mais informações sobre como automatizar uploads de arquivos de registro de transações, consulte Programar uploads de arquivos de logs de transações para o Amazon RDS.

Jobs de migração do Database Migration Service

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

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

O processo de migração geralmente envolve as seguintes tarefas:

• Exporte um backup completo do banco de dados de origem e faça o upload dele em um bucket do Google Cloud Storage.
• Faça backup dos logs de arquivos de transações e faça o upload deles no mesmo bucket do Cloud Storage. Para mais informações sobre como automatizar esse processo, consulte Programar uploads de arquivos de registro de transações para o Amazon RDS.
• No Database Migration Service, monitore o processamento dos backups de logs de transações.
• Interrompa a gravação no banco de dados de origem.
• Aguarde até que a origem e o destino estejam sincronizados, quando o backup do log de transação final será processado.
• Interrompe a replicação em andamento e promove o job de migração. Ao promover um job de migração, a instância de destino do Cloud SQL será desconectada da instância do banco de dados de origem e será promovida para uma instância principal.
• Implante os aplicativos que apontam para o novo banco de dados de destino.

Para acessar um processo de configuração de migração detalhado, consulte Migrar os bancos de dados do SQL Server para o Cloud SQL para SQL Server.

Replicação integrada do mecanismo de banco de dados

Se estiver usando o Amazon RDS Standard, talvez seja necessário migrar primeiro para a Versão personalizada do Amazon RDS e, em seguida, replicar para o Cloud SQL.

O Cloud SQL oferece suporte à replicação do SQL Server. Para mais informações sobre a replicação de um servidor externo, consulte Como migrar dados do SQL Server 2017 para o Cloud SQL para SQL Server usando a replicação de snapshots.

Ferramentas de terceiros

Defina todas as tarefas de execução para a ferramenta de terceiros escolhida. Por exemplo, para usar o Striim, crie apps no seu namespace e configure o leitor de CDC para se conectar à instância do Amazon. Para mais informações, consulte Configuração do SQL Server na documentação do Striim.

Definir cenários de fallback

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

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

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

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

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

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

Fallback simples

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

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

Replicação reversa

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

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

Replicação direta

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

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

Escritas duplicadas

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

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

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

Realizar testes e validações

Os objetivos desta etapa são testar e validar:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ferramenta de validação de dados

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

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

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

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

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

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

Faça a migração

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

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

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

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

Executar a transferência da produção

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

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

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

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

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

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

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

Limpar o ambiente de origem e configurar a instância do Cloud SQL

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

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

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

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

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

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

Além da limpeza do ambiente de origem, as seguintes configurações importantes para as instâncias do Cloud SQL devem ser concluídas:

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

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

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

• Sobre a manutenção em instâncias do Cloud SQL.
• Configurações específicas do mecanismo do SQL Server.

Otimizar o ambiente após a migração

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

1. Avalie o ambiente atual e suas equipes.
2. Estabeleça suas metas e requisitos de otimização.
3. Otimize o ambiente e as equipes.
4. Ajuste seu processo de otimização.

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

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

Estabelecer seus requisitos de otimização

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

Aumentar a confiabilidade e a disponibilidade do banco de dados

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

• Para cargas de trabalho com muita leitura, adicione réplicas de leitura para descarregar o tráfego da instância principal.
• Para cargas de trabalho essenciais, use a configuração de alta disponibilidade, réplicas de failover regional e uma configuração robusta de recuperação de desastres.
• Para cargas de trabalho menos críticas, criar backups automatizados e sob demanda pode ser suficiente.
• Para evitar a remoção acidental de instâncias, use a proteção de exclusão de instâncias.
• Ative a Recuperação pontual (PITR, na sigla em inglês) da instância do Cloud SQL para SQL Server.
• Automatize os backups do banco de dados SQL usando os planos de manutenção.

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

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

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

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

• Identifique possíveis recursos superestimados:

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

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

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

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

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

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

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

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

Para reduzir os custos de licenciamento, principalmente no Cloud SQL para SQL Server, considere o seguinte:

• Migre para o SQL Server Standard Edition, se as SLAs atenderem às suas necessidades.
• Desative a multissegmentação simultânea (SMT) e adicione 25% mais núcleos. Os núcleos extras podem compensar no impacto do desempenho com a desativação do SMT. Essa estratégia pode ajudar a reduzir custos de licenciamento, mas isso pode afetar o desempenho da instância. Recomendamos fazer o teste de carga nas instância para garantir que os SLAs não foram afetados.
• Considere uma migração heterogênea do Cloud SQL para SQL Server para o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL, dependendo da carga de trabalho.

Aumentar o desempenho da infraestrutura do banco de dados

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

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

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

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

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

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

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

• Evite a fragmentação de dados e índices. Defina uma programação para recriar índices no SQL Server, dependendo da frequência com que os dados são alterados.

• Altere as Configurações específicas do mecanismo do SQL Server para que funcionem de maneira ideal no Cloud SQL.

• Para a manutenção de índices e estatísticas, consulte Solução de manutenção do SQL Server.

• Atualize as estatísticas regularmente no Cloud SQL para SQL Server.

• Considere executar operações ETL em uma réplica de leitura, porque elas podem afetam o cache da instância.

Para mais informações sobre como melhorar o desempenho, consulte Desempenho em "Diagnosticar problemas" e Cloud SQL: análise de desempenho e ajuste de consultas do SQL Server

Aumentar os recursos de observabilidade do banco de dados

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

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

  • Use o Cloud Monitoring para coletar medidas do seu serviço e do Google Cloud de recursos que você usa.
  • É possível criar painéis personalizados para monitorar métrica. e configurar políticas de alertas para receber notificações oportunas.

• O Cloud Logging coleta dados de registro de componentes comuns do aplicativo. Também é possível acessar e consultar logs da instância do Cloud SQL.

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

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

Práticas recomendadas e diretrizes operacionais gerais do Cloud SQL

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

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

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

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

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

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

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

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

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

Fragmentação do banco de dados: escalone horizontalmente as gravações fragmentando o banco de dados. A fragmentação é uma operação complicada e envolve a rearquitetura do banco de dados e aplicativos de uma forma específica e a execução da migração de dados. Você deve dividir os de banco de dados em várias instâncias menores usando uma regra específica de particionamento. Os critérios podem ser baseados no cliente ou no assunto. Essa opção permite escalonar horizontalmente as gravações e as leituras. No entanto, isso aumenta a complexidade dos bancos de dados e cargas de trabalho. Isso também pode levar a fragmentos desequilibrados, chamados pontos de acesso, que superariam o benefício da fragmentação.

Especificamente para o Cloud SQL para SQL Server, considere as seguintes práticas recomendadas:

• Para atualizar as configurações do SQL Server para um desempenho ideal com o Cloud SQL, consulte as Configurações do SQL Server.
• Determine a capacidade do subsistema de E/S antes de implantar o SQL Server.

• Se tiver instâncias grandes, divida-as em instâncias menores, se for possível:

  • Um tamanho de disco de 4 TB ou mais fornece mais capacidade de processamento e IOPS.
  • Uma vCPU maior fornece mais IOPS e capacidade de processamento. Ao usar uma vCPU mais alta, monitore o banco de dados aguardando o paralelismo, que também pode aumentar.

• Desative a SMT se a performance cair em algumas situações. Por exemplo, se um aplicativo executar linhas de execução que se tornam um gargalo e a arquitetura da CPU não lidar com isso de forma eficaz.

• Defina uma programação para reorganizar ou reconstruir os índices, dependendo das alterações da frequência de dados.

• Defina um fator de preenchimento apropriado para reduzir a fragmentação. Monitore o SQL Server quanto a índices ausentes que possam oferecer melhor desempenho.

• Evite o crescimento desnecessário do banco de dados. Defina autogrow em MBs em vez de porcentagem, usando incrementos adequados para o requisito. Além disso, gerencie proativamente o crescimento do banco de dados antes que o limite de autogrow seja atingido.

• Para escalonar automaticamente a capacidade de armazenamento, ative os aumentos automáticos de armazenamento. O Cloud SQL pode adicionar espaço de armazenamento se o banco de dados e a instância ficarem sem espaço.

• Entenda os requisitos de localidade, a ordem de classificação e a diferenciação de maiúsculas e minúsculas dos dados com que você está trabalhando. Ao selecionar uma ordenação para o servidor, banco de dados, coluna ou expressão, você atribui algumas características aos dados.

• Mesclagens de hash recursivas ou esgotamento de hash reduzem o desempenho em um servidor. Se forem observados muitos eventos de aviso de hash em um trace, atualize as estatísticas nas colunas que estão sendo mescladas. Para mais informações, consulte Classe de evento de aviso de hash.

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

A seguir

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

Colaboradores

Autores:

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

Outros colaboradores:

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

Para ver perfis não públicos do LinkedIn, faça login.