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

Last reviewed 2024-09-12 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 PostgreSQL ou o AlloyDB para PostgreSQL.

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 PostgreSQL e o destino é o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL.

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:

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.

Caminho de migração com quatro fases.

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 e do Amazon Aurora. Idealmente, este processo deve ser automático, 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 for PostgreSQL ou o AlloyDB for PostgreSQL podem não ter funcionalidades, especificações de instâncias ou funcionamento 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, alta disponibilidade, modelo de capacidade de recursos e integrações de funcionalidades específicas do motor de base de dados, bem como extensões. Consoante o tipo de motor de base de dados, o tamanho da instância e a arquitetura, também existem diferenças nos valores predefinidos das definições de 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 secção 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 têm de ser adaptados para 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 para as 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 para PostgreSQL e restringir os dados numa VPC.

  • Aplique patches e configure as suas instâncias. As suas ferramentas de implementação existentes podem ter de ser atualizadas. 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 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 alerta. As categorias de métricas para as instâncias da 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 Cloud SQL para PostgreSQL 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 do Amazon Aurora para PostgreSQL para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL

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:

Fluxograma para ajudar a escolher a estratégia de migração.

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.

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

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

Para migrações únicas para o Cloud SQL para PostgreSQL ou para o AlloyDB para PostgreSQL, recomendamos que use cópias de segurança do motor da base de dados para exportar os dados da instância de origem e importar esses dados para a instância de destino. Os trabalhos de migração únicos não são suportados 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. Esta abordagem é adequada para qualquer tamanho de base de dados e, normalmente, é mais eficaz do que outras ferramentas para instâncias grandes.

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 podem não estar seguros se as capturas de ecrã não forem geridas corretamente.
  • As cópias de segurança não têm as capacidades de monitorização adequadas.
  • As cópias de segurança exigem esforço para serem dimensionadas quando se migram muitas bases de dados.

Pode usar as utilidades de cópia de segurança incorporadas do PostgreSQL, pg_dump e pg_dumpall, para migrar o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL. No entanto, as utilidades pg_dump e pg_dumapall têm as seguintes limitações gerais:

  • As utilidades de cópia de segurança incorporadas devem ser usadas para migrar bases de dados com um tamanho igual ou inferior a 500 GB. A descarga e o restauro de bases de dados grandes podem demorar muito tempo e podem exigir um espaço em disco e uma memória substanciais.
  • O utilitário pg_dump não inclui utilizadores nem funções. Para migrar estas contas de utilizadores e funções, pode usar o utilitário pg_dumpall.
  • O Cloud Storage suporta um tamanho máximo de objeto único de até 5 terabytes (TB). Se tiver bases de dados com mais de 5 TB, a operação de exportação para o Cloud Storage falha. Neste caso, tem de dividir os ficheiros de exportação em segmentos mais pequenos.

Se optar por usar estas utilidades, considere as seguintes restrições e práticas recomendadas:

  • Comprima os dados para reduzir o custo e a duração da transferência. Use a opção --jobs com o comando pg_dump para executar um determinado número de tarefas de despejo em simultâneo.
  • Use a opção -z com o comando pg_dump para especificar o nível de compressão a usar. Os valores aceitáveis para esta opção variam entre 0 e 9. O valor predefinido é comprimir a um nível 6. Os valores mais elevados diminuem o tamanho do ficheiro de despejo, mas podem causar consumos elevados de recursos no anfitrião do cliente. Se o anfitrião do cliente tiver recursos suficientes, os níveis de compressão mais elevados podem reduzir ainda mais o tamanho do ficheiro de despejo.
  • Use as flags corretas quando criar um ficheiro de despejo SQL.
  • Valide a base de dados importada. Monitorize o resultado do utilitário pg_restore para verificar se existem mensagens de erro durante o processo de restauro. Reveja os registos do PostgreSQL para ver se existem avisos ou erros durante o processo de restauro. Execute consultas básicas e contagens de tabelas para verificar a integridade da base de dados.

Para ler mais sobre as limitações e as práticas recomendadas, consulte os seguintes recursos:

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

A utilização de outras abordagens que não as utilidades de cópia de segurança incorporadas pode oferecer mais controlo e flexibilidade na migração de manutenção agendada. Estes outros tipos de abordagens permitem-lhe fazer transformações, verificações ou outras operações nos seus dados durante a migração. Pode consolidar várias instâncias ou bases de dados numa única instância ou base de dados. A consolidação de instâncias pode ajudar a mitigar os custos operacionais e facilitar os problemas de escalabilidade.

Uma dessas alternativas às utilidades de cópia de segurança é usar ficheiros simples para exportar e importar os seus dados. Para mais informações sobre a importação de ficheiros simples, consulte o artigo Exporte e importe com ficheiros CSV para o Cloud SQL para PostgreSQL.

Outra alternativa é usar uma importação gerida para configurar a replicação a partir de uma base de dados PostgreSQL externa. Quando usa uma importação gerida, existe um carregamento inicial de dados da base de dados externa para a instância do Cloud SQL para PostgreSQL. Este carregamento inicial usa um serviço que extrai dados do servidor externo, ou seja, a instância do RDS ou do Aurora, e importa-os diretamente para a instância do Cloud SQL para PostgreSQL. Para mais informações, consulte o artigo Use uma importação gerida para configurar a replicação a partir de bases de dados externas.

Uma forma alternativa de fazer uma migração de dados única dos seus dados é exportar as tabelas da base de dados PostgreSQL de origem para ficheiros CSV ou SQL. Em seguida, pode importar o ficheiro CSV ou SQL para o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL. Para exportar a data da sua instância de origem, pode usar a extensão aws_s3 para o PostgreSQL. Em alternativa, pode usar o Amazon Database Migration Service e um contentor S3 como destino. Para informações detalhadas sobre esta abordagem, consulte os seguintes recursos:

Também pode importar manualmente dados para uma instância do AlloyDB para PostgreSQL. Os formatos suportados são os seguintes:

  • CSV: com este formato de ficheiro, cada ficheiro neste formato contém o conteúdo de uma tabela na base de dados. Pode carregar os dados para o ficheiro CSV através do programa de linha de comandos psql. Para mais informações, consulte o artigo Importe um ficheiro CSV.
  • DMP: este formato de ficheiro contém o arquivo de uma base de dados PostgreSQL completa. Importa dados deste ficheiro através do utilitário pg_restore. Para mais informações, consulte o artigo Importe um ficheiro DMP.
  • SQL: este formato de ficheiro contém a reconstrução de texto de uma base de dados PostgreSQL. Os dados neste ficheiro são processados através da linha de comandos psql. Para mais informações, consulte o artigo Importe um ficheiro SQL.

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:

Fluxograma para ajudar a escolher uma ferramenta para migrações de replicação contínuas.

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 enquanto o passo de replicação ocorre?

      • 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 de 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 um tipo de tarefa específico para migrações contínuas. Estas tarefas de migração contínua suportam migrações de alta fidelidade para o Cloud SQL for PostgreSQL e para o AlloyDB for PostgreSQL.

Quando usa o serviço de migração de base de dados para migrar para o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL, existem pré-requisitos e limitações associados a cada instância de destino:

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. A replicação da base de dados pode ser feita 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. Estes tipos de replicação são denominados replicação lógica. Para o PostgreSQL, também existem extensões de terceiros, como o pglogical, que implementam a replicação lógica com base no registo de transações (WAL).

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

Seguem-se as limitações e os pré-requisitos do Cloud SQL para PostgreSQL:

  • As seguintes versões da Amazon são suportadas:

    • Amazon RDS 9.6.10 e posteriores, 10.5 e posteriores, 11.1 e posteriores, 12, 13, 14
    • Amazon Aurora 10.11 e posteriores, 11.6 e posteriores, 12.4 e posteriores, e 13.3 e posteriores

  • A firewall do servidor externo tem de ser configurada para permitir o intervalo de IP interno que foi atribuído para o acesso privado aos serviços da rede VPC. A base de dados de réplica do Cloud SQL para PostgreSQL usa a rede VPC como rede privada.

  • A firewall da base de dados de origem tem de ser configurada para permitir todo o intervalo de IP interno que foi atribuído para a ligação de serviço privado da rede VPC. A instância de destino do Cloud SQL para PostgreSQL usa esta rede VPC no campo privateNetwork da respetiva definição IpConfiguration.

  • Quando instala a extensão pglogical numa instância do Cloud SQL para PostgreSQL, certifique-se de que definiu a flag enable_pglogical como on (por exemplo, cloudsql.enable_pglogical=on).

  • Certifique-se de que o parâmetro shared_preload_libraries inclui a extensão pglogical na instância de origem (por exemplo, shared_preload_libraries=pg_stat_statements,pglogical). Defina o parâmetro rds.logical_replication como 1. Esta definição ativa os registos de gravação antecipada ao nível lógico.

    Estas alterações requerem o reinício da instância principal.

Para mais informações sobre a utilização do Cloud SQL para PostgreSQL para replicação, consulte a lista de verificação do servidor externo na secção de replicação para PostgreSQL e também Configure a replicação lógica e a descodificação para o PostgreSQL na documentação oficial do Cloud SQL.

O AlloyDB para PostgreSQL suporta a replicação através da extensão pglogical. Para ativar a extensão pglogical para replicação, pode usar o comando CREATE EXTENSION. Antes de usar esse comando, primeiro tem de definir os indicadores da base de dados alloydb.enable_pglogical e alloydb.logical_decoding como on na instância do AlloyDB for PostgreSQL onde quer usar a extensão. A definição destas flags requer o reinício da instância.

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

Pode usar o Datastream para replicar alterações quase em tempo real da sua instância do PostgreSQL de origem. O fluxo de dados usa a captura de dados de alterações (CDC) e a replicação para replicar e sincronizar dados. Em seguida, pode usar o Datastream para a replicação contínua a partir do Amazon RDS e do Amazon Aurora. Usa o Datastream para replicar alterações da sua instância do PostgreSQL para o BigQuery ou o Cloud Storage. Esses dados replicados podem ser transferidos para a sua instância do Cloud SQL for PostgreSQL e do AlloyDB for PostgreSQL com o Dataflow através de um modelo flexível do Dataflow ou com o Dataproc.

Para mais informações sobre a utilização do Datastream e do Dataflow, consulte os seguintes recursos:

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:

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.

Tarefas de migração de base de dados paralelas.

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:

  • Preparações e pré-requisitos para uma instância do Amazon RDS ou do Amazon Aurora
  • Preparação e pré-requisitos da base de dados de origem
  • Configuração de instâncias do Cloud SQL para PostgreSQL e AlloyDB para PostgreSQL
  • 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 e aplicar o grupo de segurança à sua instância do Amazon RDS ou do Amazon Aurora:

    • 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.

  • Se estiver a migrar do Amazon RDS, certifique-se de que tem espaço livre suficiente no disco para armazenar em buffer os registos de gravação antecipada durante a operação de carregamento completo na sua instância do Amazon RDS.

  • Para a replicação contínua (streaming de alterações através da CDC), tem de usar uma instância do RDS completa e não uma réplica de leitura.

  • Se estiver a usar a replicação incorporada, tem de configurar a instância do Amazon RDS ou do Amazon Aurora para a replicação para PostgreSQL. A replicação incorporada ou as ferramentas que usam a replicação incorporada precisam de replicação lógica para o PostgreSQL.

  • 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 PostgreSQL.

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, configure a base de dados de origem antes de estabelecer ligação à mesma. Para mais informações, consulte os artigos Configure a sua origem para o PostgreSQL e Configure a sua origem do PostgreSQL para o AlloyDB para PostgreSQL.

  • Para tabelas que não têm chaves primárias, após o Database Migration Service migrar a cópia de segurança inicial, apenas as declarações INSERT são migradas para a base de dados de destino durante a fase de CDC. As declarações DELETE e UPDATE não são migradas para essas tabelas.

  • Tenha em atenção que não é possível replicar objetos grandes através do serviço de migração de bases de dados, uma vez que a funcionalidade de descodificação lógica no PostgreSQL não suporta a descodificação de alterações a objetos grandes.

  • Se optar por usar a replicação integrada, tenha em atenção que a replicação lógica tem determinadas limitações relativamente a comandos de linguagem de definição de dados (LDD), sequências e objetos grandes. As chaves primárias têm de existir ou ser adicionadas em tabelas que vão ser ativadas para CDC e que passam por muitas atualizações.

  • Algumas ferramentas de migração de terceiros requerem que todas as colunas de objetos grandes sejam anuláveis. Todas as colunas de objetos grandes 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 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 de instâncias do Cloud SQL para PostgreSQL e AlloyDB para PostgreSQL

Para que a instância de destino alcance níveis de desempenho semelhantes aos da instância de origem, escolha o tamanho e as especificações da instância da base de dados PostgreSQL de destino de modo a corresponderem aos da instância de origem. Preste especial atenção ao tamanho e à taxa de transferência do disco, às operações de entrada/saída por segundo (IOPS) e ao número de CPUs virtuais (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. Ao decidir sobre a instância do Cloud SQL for PostgreSQL ou do AlloyDB for PostgreSQL, tenha em atenção que o desempenho do disco se baseia no tamanho do disco e no número de vCPUs.

Tem de confirmar as seguintes propriedades e requisitos antes de criar as instâncias do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL. Se quiser alterar estas propriedades e requisitos mais tarde, tem de recriar as instâncias.

  • Escolha cuidadosamente o projeto e a região das instâncias do Cloud SQL for PostgreSQL e do AlloyDB for PostgreSQL de destino. Não é possível migrar instâncias entre Google Cloud projetos e regiões sem transferência de dados.

  • Migre para uma versão principal correspondente no Cloud SQL para PostgreSQL e no AlloyDB para PostgreSQL. Por exemplo, se estiver a usar o PostgreSQL 14.x no Amazon RDS ou no Amazon Aurora, deve migrar para o Cloud SQL ou o AlloyDB for PostgreSQL para a versão 14.x do PostgreSQL.

  • 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. Para ver detalhes, reveja as limitações na secção Cópias de segurança específicas do motor da base de dados.

  • Reveja as flags de configuração específicas 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, quando trabalha com o PostgreSQL, recomendamos que compare os valores da tabela pg_settings na base de dados de origem com os da instância do Cloud SQL e do AlloyDB para PostgreSQL. Atualize as definições de flags conforme necessário na instância da base de dados de destino para replicar as definições de origem.

  • Consoante a natureza da sua carga de trabalho, pode ter de ativar extensões específicas para suportar a sua base de dados. Se a sua carga de trabalho exigir estas extensões, reveja as extensões do PostgreSQL suportadas e como ativá-las no Cloud SQL e no AlloyDB para PostgreSQL.

Para mais informações sobre a configuração do Cloud SQL para PostgreSQL, consulte as opções de configuração da instância, flags específicos do motor de base de dados> e extensões suportadas.

Para mais informações sobre a configuração do AlloyDB para PostgreSQL, consulte os indicadores de base de dados suportados e as extensões suportadas.

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

Se puder tolerar o tempo de inatividade, pode importar ficheiros de despejo SQL para o Cloud SQL e o AlloyDB para PostgreSQL. Nestes casos, pode ter de criar um contentor do Cloud Storage para armazenar o despejo da base de dados.

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

Consoante o exemplo de utilização e a 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 e do AlloyDB for PostgreSQL de destino para a instância da Amazon de origem.

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

Se estiver a migrar para o AlloyDB for PostgreSQL, considere usar uma instância do Cloud SQL for PostgreSQL como um potencial destino para os seus cenários de alternativa. Use a extensão pglogical para configurar a replicação lógica para essa instância do Cloud SQL.

Para obter mais informações, consulte os seguintes recursos:

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

Use a utilidade pg_dump para criar uma cópia de segurança. Para mais informações sobre a utilização desta utilidade para importar e exportar dados, consulte os seguintes recursos:

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 Database Migration Service, a migração começa com o despejo do esquema inicial e o restauro sem índices nem restrições, seguido da operação de cópia de dados. Após a conclusão da cópia de dados, os índices e as restrições são restaurados. Por fim, é iniciada a replicação contínua das alterações da instância da base de dados de origem para a de destino.

O Database Migration Service usa a extensão pglogical para a replicação da origem para a instância de base de dados de destino. No início da migração, esta extensão configura a replicação exigindo bloqueios exclusivos de curto prazo em todas as tabelas na sua instância de origem do Amazon RDS ou do Amazon Aurora. Por este motivo, recomendamos que inicie a migração quando a base de dados estiver menos ocupada e evite declarações na origem durante a fase de despejo e replicação, uma vez que as declarações DDL não são replicadas. Se tiver de executar operações DDL, use as funções "pglogical" para executar declarações DDL na instância de origem ou execute manualmente as mesmas declarações DDL na instância de destino da migração, mas apenas após a conclusão da fase de descarga inicial.

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. Em seguida, a instância de destino agora autónoma é promovida a uma instância principal. Esta abordagem também é denominada mudança de produção.

Para um processo de configuração de migração totalmente detalhado, consulte os guias de início rápido para PostgreSQL e PostgreSQL para AlloyDB para PostgreSQL.

Replicação integrada do motor de base de dados

O Cloud SQL suporta dois tipos de replicação lógica: a replicação lógica incorporada do PostgreSQL e a replicação lógica através da extensão pglogical. Para o AlloyDB for PostgreSQL, recomendamos a utilização da extensão pglogical para replicação. Cada tipo de replicação lógica tem as suas próprias funcionalidades e limitações.

A replicação lógica incorporada tem as seguintes funcionalidades e limitações:

  • Está disponível no PostgreSQL 10 e posteriores.
  • Todas as alterações e colunas são replicadas. As publicações são definidas ao nível da tabela.
  • Os dados só são replicados de tabelas base para tabelas base.
  • Não realiza a replicação de sequências.
  • É o tipo de replicação recomendado quando existem muitas tabelas que não têm uma chave principal. Configure a replicação lógica do PostgreSQL incorporada. Para tabelas sem uma chave principal, aplique o formulário REPLICA IDENTITY FULL para que a replicação incorporada use a linha inteira como o identificador exclusivo em vez de uma chave principal.

A replicação lógica do pglogical tem as seguintes funcionalidades e limitações:

  • Está disponível em todas as versões do PostgreSQL e oferece suporte entre versões.
  • A filtragem de linhas está disponível na origem.
  • Não replica as tabelas UNLOGGED e TEMPORARY.
  • É necessária uma chave principal ou uma chave exclusiva nas tabelas para captar as alterações UPDATE e DELETE.
  • A replicação de sequências está disponível.
  • É possível que a replicação esteja atrasada.
  • Oferece deteção de conflitos e resolução configurável se existirem vários publicadores ou conflitos entre dados replicados e alterações locais.

Para obter instruções sobre como configurar a replicação lógica do PostgreSQL incorporada a partir de um servidor externo, como o Amazon RDS ou o Amazon Aurora para PostgreSQL, consulte os seguintes recursos:

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.

Usa um ou mais fluxos para organizar estes processos de migração nas suas aplicações personalizadas. Para programar as suas aplicações personalizadas, pode optar por usar uma ferramenta de programação gráfica ou a linguagem de programação Tungsten Query Language (TQL).

Para mais informações sobre como usar o Striim, consulte os seguintes recursos:

Se decidir usar o Striim para migrar os seus dados, consulte os seguintes guias sobre como usar o Striim para migrar dados para o Google Cloud:

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 a versão do tópico "Validar uma migração" para o PostgreSQL ou o PostgreSQL para o AlloyDB for PostgreSQL.

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.

Em alternativa, pode usar outra instância e replicar as alterações nessa instância. Por exemplo, quando o AlloyDB for PostgreSQL é um destino de migração, considere configurar a replicação para uma instância do Cloud SQL for PostgreSQL para cenários de alternativa.

Além da limpeza do ambiente de origem, têm de ser feitas as seguintes configurações críticas para as suas instâncias do Cloud SQL para PostgreSQL:

  • 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 nas instâncias do Cloud SQL for PostgreSQL e do AlloyDB for PostgreSQL, consulte os seguintes recursos:

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:

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:

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.

Quando migrar do Amazon RDS e do Aurora para PostgreSQL para o Cloud SQL para PostgreSQL, considere as seguintes diretrizes:

  • Use o armazenamento em cache para melhorar o desempenho de leitura. Inspecione as várias estatísticas a partir da vista pg_stat_database. Por exemplo, a proporção blks_hit / (blks_hit + blks_read) deve ser superior a 99%. Se esta relação não for superior a 99%, considere aumentar a quantidade de RAM da sua instância. Para mais informações, consulte o artigo Coletor de estatísticas do PostgreSQL.
  • Recupere espaço e evite um mau desempenho do índice. Consoante a frequência com que os dados mudam, defina um agendamento para executar o comando VACUUM no Cloud SQL para PostgreSQL.
  • Use a edição Cloud SQL Enterprise Plus para aumentar os limites de configuração da máquina e a cache de dados. Para mais informações sobre o Cloud SQL Enterprise Plus, consulte o artigo Introdução às edições do Cloud SQL.
  • Mude para o AlloyDB para PostgreSQL. Se mudar, pode ter compatibilidade total com o PostgreSQL, melhor processamento transacional e cargas de trabalho de análise transacional rápidas suportadas na sua base de dados de processamento. Também recebe uma recomendação para novos índices através da utilização da funcionalidade de consultor de índices.

Para mais informações sobre como aumentar o desempenho da sua infraestrutura de base de dados do Cloud SQL para PostgreSQL, consulte a documentação de melhoria do desempenho do Cloud SQL para PostgreSQL.

Quando migrar do Amazon RDS e do Aurora para PostgreSQL para o AlloyDB para PostgreSQL, considere as seguintes diretrizes para aumentar o desempenho da sua instância da base de dados do AlloyDB para PostgreSQL:

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.

Para mais informações sobre como aumentar a observabilidade da sua infraestrutura de base de dados, consulte as seguintes secções da documentação:

Práticas recomendadas gerais e diretrizes operacionais do Cloud SQL e do AlloyDB para PostgreSQL

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.

Para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL, considere as seguintes práticas recomendadas:

  • Para descarregar o tráfego da instância principal, adicione réplicas de leitura. Também pode usar um equilibrador de carga, como o HAProxy, para gerir o tráfego para as réplicas. No entanto, evite ter demasiadas réplicas, pois isso dificulta a operação VACUUM. Para mais informações sobre a utilização do HAProxy, consulte o Website HAProxy.
  • Otimize a operação VACUUM aumentando a memória do sistema e o parâmetro maintenance_work_mem. Aumentar a memória do sistema significa que é possível processar mais tuplos em cada iteração.
  • Uma vez que os índices maiores consomem uma quantidade significativa de tempo para a análise de índices, defina o parâmetro INDEX_CLEANUP como OFF para limpar rapidamente e congelar os dados da tabela.
  • Quando usar o AlloyDB for PostgreSQL, use o painel de controlo System Insights do AlloyDB for PostgreSQL e os registos de auditoria. O painel de controlo System Insights do AlloyDB for PostgreSQL apresenta métricas dos recursos que usa e permite monitorizá-los. Para mais detalhes, consulte as diretrizes do tópico Monitorizar instâncias na documentação do AlloyDB para PostgreSQL.

Para mais detalhes, consulte os seguintes recursos:

O que se segue?

Colaboradores

Autores:

Outro colaborador: Somdyuti Paul | Data Management Specialist