Google Cloud oferece ferramentas, produtos, orientação 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 é destinado a administradores de nuvem e de banco de dados que querem planejar, implementar e validar um projeto de migração de banco de dados. Ele também é destinado a tomadores de decisões que estão avaliando a oportunidade de migrar e querem conhecer explorar um exemplo de migração.
Este documento se concentra em uma migração homogênea do banco de dados, que é uma migração em que os bancos de dados de origem e de destino têm a mesma tecnologia. 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 com várias partes sobre a migração da AWS para Google Cloud que inclui os seguintes documentos:
- Primeiros passos
- Migrar do Amazon EC2 para o Compute Engine
- Migrar do Amazon S3 para o Cloud Storage
- Migrar do Amazon EKS para o GKE
- Migrar do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL
- Migrar do Amazon RDS e do Amazon Aurora para PostgreSQL para o Cloud SQL e o AlloyDB para PostgreSQL (este documento)
- Migrar do Amazon RDS para SQL Server para o Cloud SQL para SQL Server
- Migrar da AWS Lambda para o Cloud Run
Para essa migração para Google Cloud, recomendamos que você siga o framework de migração descrito em Migrar para Google Cloud: primeiros passos.
No diagrama a seguir, veja o caminho da sua jornada de migração.
É possível migrar do seu ambiente de origem para o Google Cloud em uma série de iterações. Por exemplo, é possível migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral:
- Avaliar e descobrir suas cargas de trabalho e seus dados.
- Planejar e criar uma base em Google Cloud.
- Migre suas cargas de trabalho e seus dados para o Google Cloud.
- Otimize o Google Cloud ambiente.
Para mais informações sobre as fases desse framework, consulte Migrar para o Google Cloud: primeiros passos.
Para elaborar um plano de migração eficaz, recomendamos que você valide cada etapa do plano e use uma estratégia de reversão. Para ajudar você a validar o plano de migração, consulte Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração.
Avaliar o ambiente de origem
Na fase de avaliação, você determina os requisitos e as dependências para migrar o ambiente de origem para Google Cloud.
A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa entender seu ponto de partida para planejar e executar uma migração do Google Cloud.
A fase de avaliação consiste nas tarefas a seguir:
- Criar um inventário abrangente das suas cargas de trabalho.
- Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
- Treine e instrua suas equipes sobre Google Cloud.
- Crie experimentos e provas de conceito no Google Cloud.
- Calcule o custo total de propriedade (TCO) do ambiente de destino.
- Escolha a estratégia de migração para suas cargas de trabalho.
- Escolha as ferramentas de migração.
- Defina o plano e o cronograma de migração.
- Valide seu plano de migração.
A fase de avaliação do banco de dados ajuda você a escolher o tamanho e as especificações da instância do banco de dados de destino do Cloud SQL que corresponde à origem com necessidades de desempenho semelhantes. Preste uma atenção especial ao tamanho do disco e à capacidade de processamento, IOPS e número de vCPUs. As migrações podem apresentar dificuldades ou falhar devido a erros de tamanho da instância do banco de dados de destino. O dimensionamento incorreto pode levar um tempo maior de execução da imigração, problemas de desempenho do banco de dados, erros de banco de dados e problemas de de desempenho do aplicativo. Ao decidir sobre a instância do Cloud SQL, o desempenho do disco deve ser baseado no tamanho dele e no número de vCPUs.
As seções a seguir dependem de Migrar para o Google Cloud: avaliar e descobrir suas cargas de trabalho e integram as informações desse documento.
Criar um inventário das suas instâncias do Amazon RDS ou Amazon Aurora
Para definir o escopo da migração, crie um inventário e colete informações sobre suas instâncias do Amazon RDS e do Amazon Aurora. O ideal é que esse seja um processo automatizado, porque as abordagens manuais são propensas a erros e podem levar a suposições incorretas.
O Amazon RDS ou o Amazon Aurora e o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL podem não ter recursos, especificações de instâncias ou operações semelhantes. Algumas funcionalidades podem ser implementadas de maneira diferente ou ficar indisponíveis. Áreas de diferença podem incluir infraestrutura, armazenamento, autenticação e segurança, replicação, backup, alta disponibilidade, modelo de capacidade de recursos e recurso específico do mecanismo de banco de dados de integrações e extensões. Dependendo do tipo de mecanismo de banco de dados, do tamanho da instância e da arquitetura, há também diferenças nos valores padrão de configurações de parâmetros do banco de dados.
A comparação pode ajudar você a entender melhor as cargas de trabalho que serão migradas e contribuirão para definir a arquitetura correta para o ambiente de destino da migração. A coleta de informações sobre o desempenho é importante para estimar as necessidades de desempenho do ambiente de destino Google Cloud . Os conceitos e as ferramentas de comparação estão detalhados na Fase Executar teste e validação do processo de migração, mas também se aplicam à etapa de criação de inventário.
Ferramentas para avaliações
Para uma avaliação geral inicial da infraestrutura atual, recomendamos o Google Cloud Migration Center e outras ferramentas especializadas de avaliação de banco de dados, como migVisor e Database Migration Assessment Tool (DMA).
Com a Migration Center, é possível fazer uma avaliação completa do cenário de aplicativos e bancos de dados, incluindo a adequação técnica para uma migração de bancos de dados para Google Cloud. Você recebe as recomendações de tamanho e a configuração de todos os bancos de dados de origem e cria um custo total de propriedade (TCO) para servidores e bancos de dados.
Para mais informações sobre como avaliar o ambiente da AWS usando o Migration Center, consulte Importar dados de outros provedores de nuvem.
Além do Migration Center, use a ferramenta especializada migVisor. O migVisor suporta uma variedade de mecanismos de banco de dados e é especialmente adequado para migrações heterogêneas. Para uma introdução ao migVisor, consulte a Visão geral do migVisor.
O migVisor identifica artefatos e recursos do banco de dados reservados e incompatíveis que podem causar problemas para a migração e aponta para soluções alternativas. Ele também recomenda uma solução de destino Google Cloud , incluindo o dimensionamento inicial e a arquitetura.
A saída da avaliação do banco de dados do migVisor oferece o seguinte:
- Descoberta e análise abrangentes de implantações de banco de dados atuais.
- Um relatório detalhado da complexidade da migração, com base nos recursos reservados usados pelo seu banco de dados.
- Relatório financeiro com detalhes sobre economias de custos pós-migração, custos de migração e um novo orçamento operacional.
- Plano de migração em fases para mover bancos de dados e aplicativos associados com uma interrupção mínima dos negócios.
Para ver alguns exemplos de resultados de avaliação, consulte migVisor: ferramenta de avaliação de migração para a nuvem.
O migVisor aumenta temporariamente a utilização do servidor de banco de dados. Normalmente, essa carga adicional é menor que 3% e pode ser executada fora dos horários de pico.
O resultado da avaliação do migVisor ajuda a criar um inventário completo das instâncias de RDS. O relatório inclui propriedades genéricas (versão do mecanismo de banco de dados e edição, CPUs e tamanho de memória), além de detalhes sobre a topologia do banco de dados, políticas de backup, configurações de parâmetros e personalizações especiais em uso.
Se preferir usar ferramentas de código aberto, use scripts de coletor de dados com (ou no lugar) das ferramentas mencionadas. Esses scripts podem ajudar você a coletar informações de dados detalhadas (cargas de trabalho, recursos, objetos e códigos do banco de dados) e criar o inventário do banco de dados. Além disso, os scripts geralmente fornecem uma avaliação de migração de banco de dados detalhada, incluindo uma estimativa de esforço de migração.
Recomendamos a ferramenta de código aberto DMA, desenvolvida pelos engenheiros do Google. Ela oferece uma avaliação de banco de dados completa e precisa, incluindo recursos em uso, lógica e objetos de banco de dados (como esquemas, tabelas, visualizações, funções, gatilhos e procedimentos armazenados).
Para usar a DMA, faça o download dos scripts de coleta do mecanismo de banco de dados no Repositório Git, e siga as instruções. Envie os arquivos de saída para Google Cloud para análise. Google Cloud cria e entrega uma leitura de avaliação de banco de dados e apresenta as próximas etapas da jornada de migração.
Identificar e documentar o escopo da migração e o tempo de inatividade acessível
Nesta fase, você documenta informações essenciais que influenciam a estratégia e as ferramentas de migração. Até agora, você já pode responder às seguintes perguntas:
- Os bancos de dados têm mais de 5 TB?
- Há alguma tabela grande no banco de dados? Elas têm mais de 16 TB?
- Onde estão localizados os bancos de dados (regiões e zonas) e qual é a proximidade deles com os aplicativos?
- Com que frequência os dados mudam?
- Qual é o modelo de consistência de dados?
- Quais são as opções dos bancos de dados de destino?
- Qual é a compatibilidade dos bancos de dados de origem e destino?
- Os dados precisam estar em locais físicos?
- Há dados que podem ser compactados e arquivados ou que não precisam ser migrados?
Para definir o escopo da migração, decida quais dados manter e quais dados migrar. Migrar todos os bancos de dados pode exigir tempo e esforço consideráveis. Alguns dados podem permanecem nos backups do banco de dados de origem. Por exemplo, tabelas de geração de registros antigas ou ou dados de arquivos podem não ser necessários. Também é possível transferir dados após o processo de migração, dependendo de suas estratégias e ferramentas.
Estabeleça os valores de referência de migração de dados para comparar e avaliar os resultados e os impactos. Essas linhas de base são pontos de referência que representam o estado dos dados antes e depois da migração e ajudam a tomar decisões. É importante fazer medições no ambiente de origem para avaliar o sucesso da migração de dados. Essas medições incluem o seguinte:
- O tamanho e a estrutura dos dados.
- A integridade e consistência dos dados.
- A duração e o desempenho das transações comerciais mais importantes e os processos.
Determine quanto tempo de inatividade você pode pagar. Quais são os impactos comerciais do tempo de inatividade? Há períodos de baixa atividade do banco de dados, em que há menos usuários afetados pela inatividade? Em caso afirmativo, qual é a duração desses períodos e quando eles ocorrerem? Considere ter um tempo de inatividade somente para gravação parcial, enquanto as solicitações de somente leitura ainda são atendidas.
Avaliar seu processo de implantação e administração
Depois de criar os inventários, avalie o desempenho de processos do banco de dados para determinar como eles precisam ser adaptados para facilitar a migração. Esses processos são fundamentais para a maneira como você se prepara e mantém o ambiente de produção.
Considere como concluir as seguintes tarefas:
Defina e aplique políticas de segurança para as instâncias. Por exemplo, talvez seja necessário substituir o Amazon Security Groups. É possível usar papéis do Google IAM, regras de firewall de VPC e o VPC Service Controls para controlar o acesso às instâncias do Cloud SQL para PostgreSQL e restringir os dados em uma VPC.
Corrija e configure as instâncias. Talvez seja necessário atualizar suas ferramentas de implantação. Por exemplo, talvez você esteja usando a configuração personalizada em grupos de parâmetros ou grupos de opções da Amazon. Talvez seja necessário adaptar as ferramentas de provisionamento para usar o Cloud Storage ou o Secret Manager para ler essas listas de configuração personalizadas.
Gerenciar a infraestrutura de monitoramento e alertas. As categorias de métricas das instâncias do banco de dados de origem da Amazon oferecem observabilidade durante o processo de migração. As categorias de métricas podem incluir o Amazon CloudWatch, insights de desempenho, monitoramento avançado e listas de processos de SO.
Concluir a avaliação
Depois de criar os inventários do ambiente do Amazon RDS ou Amazon Aurora, conclua o restante das atividades da fase de avaliação, conforme descrito em Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho.
Planejar e criar sua base
Na fase de planejamento e criação, você provisiona e configura a infraestrutura para fazer o seguinte:
- Ofereça suporte às cargas de trabalho no Google Cloud ambiente.
- Conecte o ambiente de origem e o Google Cloud para concluir a migração.
A fase de criação e planejamento é composta pelas seguintes tarefas:
- Crie uma hierarquia de recursos.
- Configure o Identity and Access Management (IAM) do Google Cloud.
- Configure o faturamento.
- Configurar a conectividade de rede.
- Aumentar sua segurança.
- Configurar a geração de registros, o monitoramento e os alertas.
Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: planeje e crie sua base.
Se você planeja usar o Database Migration Service para migração, consulte Métodos de rede para o Cloud SQL para PostgreSQL para entender as configurações de rede disponíveis nos cenários de migração.
Monitoramento e alertas
Use o Google Cloud Monitoring, que inclui painéis predefinidos para vários Google Cloud produtos, como um painel de monitoramento do Cloud SQL. Também é possível usar soluções de monitoramento de terceiros integradas ao Google Cloud, como o Datadog e o Splunk. Para mais informações, consulte Sobre a observabilidade do banco de dados.
Migrar instâncias do Amazon RDS e do Amazon Aurora para PostgreSQL para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL
Para migrar as instâncias, faça o seguinte:
Escolha a estratégia de migração: replicação contínua ou programada de manutenção.
Escolha as ferramentas de migração, dependendo da estratégia e ou requisitos.
Defina o plano de migração e o cronograma para cada migração de banco de dados incluindo tarefas de preparação e execução.
Defina as tarefas de preparação que precisam ser realizadas para garantir o funcionamento correto da migração.
Defina as tarefas de execução, incluindo as atividades de trabalho que implementam a migração.
Defina cenários substitutos para cada tarefa de execução.
Realize testes e validações que podem ser feitos em um ambiente de teste separado.
Execute a migração.
Execute a transferência da produção.
Limpe o ambiente de origem e configure a instância de destino.
Realize ajustes e a otimização.
Cada fase é descrita nas seções a seguir.
Escolher sua estratégia de migração
Nesta etapa, você tem informações suficientes para avaliar e selecionar uma das estratégias de migração que melhor se adapta ao caso de uso de cada banco de dados:
- Manutenção programada (também chamada de migração única): essa abordagem é ideal se você puder passar um tempo de inatividade. Essa opção é relativamente menor em custo e em complexidade, porque as cargas de trabalho e os serviços não vão exigir muita refatoração. No entanto, se a migração falhar antes da conclusão, você vai precisar reiniciar o processo, o que prolonga o tempo de inatividade.
Replicação contínua (também chamada de migração de truque): para bancos de dados fundamentais, essa opção oferece um risco menor de perda de dados e quase zero tempo de inatividade. Os esforços são divididos em vários blocos, então, se ocorrer uma falha, a reversão e a repetição levam menos tempo. No entanto, a configuração é mais complexa e requer mais planejamento e tempo. Também é possível refatorar os aplicativos que se conectam ao banco de dados do Compute Engine. Considere uma das seguintes variações:
- Use a abordagem em Y (gravação e leitura), que é uma forma de migração paralela, duplicando os dados nas duas origens e as instâncias de destino durante a migração.
- Use um microsserviço de acesso a dados, que reduz o esforço de refatoração exigido pela abordagem em Y (gravação e leitura).
Para mais informações sobre estratégias de migração de dados, consulte Avaliação de abordagens de migração de dados.
O diagrama a seguir mostra um fluxograma com base em exemplos de perguntas que podem surgir ao decidir a estratégia de migração para um único banco de dados:
O fluxograma anterior mostra os seguintes pontos de decisão:
Você pode ter um período de inatividade?
- Se a resposta for não, adote a estratégia de migração de replicação contínua.
- Em caso afirmativo, prossiga para o próximo ponto de decisão.
É possível arcar com o tempo de inatividade representado por uma janela de transferência durante a migração dos dados? A janela de transferência representa a quantidade de tempo para fazer o backup do banco de dados, transferi-lo para o Cloud SQL, restaurá-lo e, em seguida, migrar os aplicativos.
- Se a resposta for não, adote a estratégia de migração de replicação contínua.
- Em caso afirmativo, adote a estratégia de migração de manutenção programada.
As estratégias podem variar para diferentes bancos de dados, mesmo quando estão localizadas na mesma instância. Uma combinação de estratégias pode produzir os melhores resultados. Por exemplo, migrar bancos de dados pequenos e pouco utilizados utilizando a abordagem de manutenção programada, mas a replicação contínua é necessária para bancos de dados fundamentais, em que o tempo de inatividade é caro.
Normalmente, uma migração é considerada concluída quando ocorre a mudança entre a instância de origem inicial e instância de destino. Qualquer replicação (se usada) é interrompida, e todas as leituras e gravações são feitas na instância de destino. Alternar quando as duas instâncias estão sincronizadas significa que não há perda de dados e o tempo de inatividade é mínimo.
Para mais informações sobre estratégias e implantações de migração de dados, consulte Classificação de migrações de banco de dados.
Minimizar o tempo de inatividade e os impactos relacionados à migração
As configurações de migração que não geram um tempo de inatividade do aplicativo exigem uma configuração complicada. Encontre o equilíbrio certo entre a complexidade da configuração e o tempo de inatividade programado durante os horários de funcionamento de baixo tráfego.
Todas as estratégias de migração têm vantagens e impactos associados ao processo de migração. Por exemplo, os processos de replicação envolvem uma carga adicional nas instâncias de origem e os aplicativos podem ser afetados pelos atrasos da replicação. Os aplicativos (e os clientes) podem ter que aguardar durante o tempo de inatividade do aplicativo, pelo menos enquanto o atraso da replicação durar antes de usar o novo banco de dados. Na prática, os fatores a seguir podem aumentar o tempo inatividade:
- As consultas de banco de dados podem levar alguns segundos para serem concluídas. No momento da migração, as consultas em andamento podem ser canceladas.
- O cache pode levar algum tempo para ser preenchido se o banco de dados for grande ou tem uma memória de buffer substancial.
- Os aplicativos interrompidos na origem e reiniciados em Google Cloud podem ter um pequeno atraso até que a conexão com a instância do banco de dados Google Cloud seja estabelecida.
- As rotas de rede para os aplicativos precisam ser redirecionadas. Dependendo de como as entradas DNS estão configuradas, isso pode levar algum tempo. Ao atualizar os registros DNS, reduza o TTL antes da migração.
As práticas comuns a seguir podem ajudar a minimizar a inatividade e o impacto:
- Encontre um período em que o tempo de inatividade tenha um impacto mínimo nas cargas de trabalho. Por exemplo, fora do horário de funcionamento normal, durante fins de semana ou e outras janelas de manutenção programadas.
- Identifique as partes das cargas de trabalho que podem passar pela migração e pela transferência de produção em diferentes estágios. Os aplicativos podem ter componentes diferentes que podem ser isolados, adaptados e migrados sem impacto. Por exemplo, front-ends, módulos de CRM, serviços de back-end e plataformas de geração de relatórios. Esses módulos podem ter bancos de dados, que podem ser programado para migração mais cedo ou mais tarde durante o processo.
- Se for possível ter um pouco de latência no banco de dados de destino, implemente uma migração gradual. Use transferências de dados incrementais e em lote e adapte parte das cargas de trabalho para trabalhar com dados desatualizados na instância de destino.
- Refatore os aplicativos para oferecer suporte a qualquer impacto mínimo da migração. Por exemplo, adapte os aplicativos para salvar nos bancos de dados de origem e de destino e, portanto, implemente uma replicação no nível do aplicativo.
Escolher as ferramentas de migração
O fator mais importante para uma migração bem-sucedida é escolher o caminho da ferramenta de migração. Depois que a estratégia de migração for decidida, reflita e escolha a ferramenta de migração.
Há muitas ferramentas disponíveis, cada uma otimizada para determinados casos de uso de migração. Os casos de uso podem incluir:
- Estratégia de migração (manutenção programada ou replicação contínua).
- Mecanismos de banco de dados de origem e destino e versões do mecanismo.
- Ambientes em que as instâncias de origem e de destino estão localizadas.
- Tamanho do banco de dados. Quanto maior o banco de dados, mais tempo leva para migrar o backup inicial.
- Frequência das mudanças no banco de dados.
- Disponibilidade para usar serviços gerenciados na migração.
Para garantir a migração e a transferência perfeitas, use os padrões de implantação de aplicativos, a orquestração de infraestrutura e os aplicativos de migração personalizados. No entanto, ferramentas especializadas, chamadas de serviços de migração gerenciados, podem facilitar o processo de migração de dados, aplicativos ou até mesmo infraestruturas inteiras de um ambiente para outro. Elas executam a extração de dados dos bancos de dados de origem, transportam dados com segurança para os bancos de dados de destino e podem modificar os dados durante o trânsito. Com esses recursos, elas encapsulam a lógica complexa da migração e oferecem recursos de monitoramento da migração.
Os serviços de migração gerenciados oferecem as seguintes vantagens:
Minimizar o tempo de inatividade: os serviços usam os recursos de replicação integrados dos mecanismos de banco de dados quando disponíveis e realizam a promoção de réplicas.
Garantir a integridade e a segurança de dados: os dados são seguros e transferidos de maneira confiável do banco de dados de origem para o destino.
Oferecer uma experiência de migração consistente: diferentes técnicas e padrões de migração podem ser consolidados em uma interface comum e consistente usando executáveis de migração de banco de dados, que você pode gerenciar e monitorar.
Oferecer modelos de migração resilientes e comprovados: migrações de banco de dados são eventos pouco frequentes, mas fundamentais. Para evitar erros banais e problemas com as soluções atuais, use ferramentas de especialistas, em vez de criar uma solução personalizada.
Otimizar custos: os serviços de migração gerenciados podem ter um custo mais eficaz do que provisionar mais servidores e recursos para as soluções de migração personalizadas.
As próximas seções descrevem as recomendações da ferramenta de migração, de acordo com a estratégia de migração escolhida.
Ferramentas para migrações de manutenção programadas
As subseções a seguir descrevem as ferramentas que podem ser usadas para migrações únicas, além das limitações e práticas recomendadas de cada ferramenta.
Para migrações únicas para o Cloud SQL para PostgreSQL ou para o AlloyDB para PostgreSQL, recomendamos que você use backups do mecanismo de banco de dados para exportar os dados da sua instância de origem e importá-los para a instância de destino. Os jobs de migração únicos não são compatíveis com o Database Migration Service.
Backups de mecanismo de banco de dados integrados
Quando um tempo de inatividade significativo é aceitável e seus bancos de dados de origem estão relativamente estáticos, é possível usar o recurso de despejo e carregamento integrados do mecanismo do banco de dados (também chamados de backup e restauração).
A configuração e a sincronização podem levar algum tempo, especialmente para um grande número de bancos de dados, mas os backups do mecanismo de banco de dados geralmente estão disponíveis e são fáceis de usar. Essa abordagem é adequada para qualquer tamanho de banco de dados. Ela costuma ser mais eficaz do que outras ferramentas para instâncias grandes.
Os backups do mecanismo de banco de dados têm as seguintes limitações gerais:
- Os backups podem estar propensos a erros, especialmente se forem feitos manualmente.
- Os dados podem não estar protegidos se os snapshots não forem gerenciados adequadamente.
- Os backups não têm recursos de monitoramento adequados.
- Os backups exigem esforço para escalonar ao migrar muitos bancos de dados.
Você pode usar os utilitários de backup integrados do PostgreSQL, pg_dump
e
pg_dumpall
, para migrar o Cloud SQL para PostgreSQL e o
AlloyDB para PostgreSQL. No entanto, os utilitários pg_dump
e pg_dumapall
têm as seguintes limitações gerais:
- Os utilitários de backup integrados devem ser usados para migrar bancos de dados com tamanho de 500 GB ou menos. O despejo e a restauração de bancos de dados grandes podem levar muito tempo e exigir espaço em disco e memória substanciais.
- O utilitário
pg_dump
não inclui usuários e funções. Para migrar essas contas de usuário e funções, use o utilitáriopg_dumpall
. - O Cloud Storage é compatível com um tamanho máximo de objeto único de até 5 terabytes (TB). Se você tiver bancos de dados maiores que 5 TB, a operação de exportação para o Cloud Storage falhará. Nesse caso, é preciso dividir os arquivos de exportação em segmentos menores.
Se você optar por usar esses utilitários, considere as seguintes restrições e práticas recomendadas:
- Compacte dados para reduzir custos e duração da transferência. Use a opção
--jobs
com o comandopg_dump
para executar um determinado número de jobs de despejo simultaneamente. - Use a opção
-z
com o comandopg_dump
para especificar o nível de compactação a ser usado. Os valores aceitáveis para essa opção variam de 0 a 9. O valor padrão é comprimir em um nível 6. Valores mais altos diminuem o tamanho do arquivo de despejo, mas podem causar um alto consumo de recursos no host do cliente. Se o host do cliente tiver recursos suficientes, níveis de compactação mais altos podem reduzir ainda mais o tamanho do arquivo de despejo. - Use as flags corretas ao criar um arquivo dump SQL.
- Verifique o banco de dados importado. Monitore a saída do utilitário
pg_restore
em busca de mensagens de erro durante o processo de restauração. Analise os registros do PostgreSQL para verificar se há avisos ou erros durante o processo de restauração. Execute consultas básicas e contagens de tabelas para verificar a integridade do banco de dados.
Para mais informações sobre limitações e práticas recomendadas, consulte os seguintes recursos:
- Práticas recomendadas para importar e exportar dados com o Cloud SQL para PostgreSQL
- Problemas conhecidos do Cloud SQL para PostgreSQL
- Importar um arquivo DMP no AlloyDB para PostgreSQL
- Migrar usuários com credenciais para o AlloyDB para PostgreSQL ou outra instância do Cloud SQL
Outras abordagens para a migração com manutenção programada
Usar outras abordagens além dos utilitários de backup integrados pode fornecer mais controle e flexibilidade na migração de manutenção programada. Esses outros tipos de abordagem permitem que você realize transformações, verificações ou outras operações nos dados durante a migração. É possível consolidar várias instâncias ou bancos de dados em uma única instância ou banco de dados. A consolidação de instâncias pode ajudar a reduzir custos operacionais e facilitar os problemas de escalonabilidade.
Uma alternativa aos utilitários de backup é usar arquivos simples para exportar e importar dados. Para mais informações sobre a importação de arquivos simples, consulte Exportar e importar usando arquivos CSV para o Cloud SQL para PostgreSQL.
Outra alternativa é usar uma importação gerenciada para configurar a replicação de um banco de dados PostgreSQL externo. Quando você usa uma importação gerenciada, há um carregamento inicial de dados do banco de dados externo para a instância do Cloud SQL para PostgreSQL. Esse carregamento inicial usa um serviço que extrai dados do servidor externo (a instância do RDS ou do Aurora) e os importa diretamente para a instância do Cloud SQL para PostgreSQL. Para mais informações, consulte Usar uma importação gerenciada para configurar a replicação de bancos de dados externos.
Uma maneira alternativa de fazer uma migração única de dados é exportar as
tabelas do banco de dados PostgreSQL de origem para arquivos CSV ou SQL. Em seguida, importe o arquivo CSV ou SQL para o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL. Para exportar a data da sua instância de origem, use
a extensão aws_s3
para PostgreSQL. Como alternativa, use o Amazon Database Migration Service e um bucket do S3 como destino. Para informações detalhadas sobre
essa abordagem, consulte os seguintes recursos:
- Como instalar a extensão aws_s3 para PostgreSQL
- Como usar o Amazon S3 como destino do Amazon Database Migration Service
Também é possível importar dados manualmente para uma instância do AlloyDB para PostgreSQL. Os formatos compatíveis são os seguintes:
- CSV: com esse formato, cada arquivo contém o conteúdo de uma tabela no banco de dados. É possível carregar os dados no arquivo CSV usando o programa de linha de comando
psql
. Para mais informações, consulte Importar um arquivo CSV. - DMP: esse formato de arquivo contém o arquivo de um banco de dados PostgreSQL
inteiro. Para importar dados desse arquivo, use o utilitário
pg_restore
. Para mais informações, consulte Importar um arquivo DMP. - SQL: esse formato de arquivo contém a reconstrução de texto de um banco de dados
PostgreSQL. Os dados desse arquivo são processados usando a linha de comando
psql
. Para mais informações, consulte Importar um arquivo SQL.
Ferramentas para migrações de replicação contínuas
O diagrama a seguir mostra um fluxograma com perguntas que podem ajudar você a escolher a ferramenta de migração de um único banco de dados ao usar uma estratégia de migração de replicação contínua:
O fluxograma anterior mostra os seguintes pontos de decisão:
Você prefere usar serviços de migração gerenciados?
Se sim, você pode ter alguns segundos de inatividade de gravação enquanto a etapa de replicação acontece?
- Em caso afirmativo, use o Database Migration Service.
- Em caso negativo, veja outras opções de migração.
Caso contrário, avalie se a replicação integrada do mecanismo de banco de dados é compatível:
- Em caso afirmativo, recomendamos o uso da replicação integrada.
- Se a resposta for não, recomendamos outras opções de migração.
As seções a seguir descrevem as ferramentas que podem ser usadas para migrações contínuas, junto com as limitações e as práticas recomendadas.
Database Migration Service para migração de replicação contínua
O Database Migration Service oferece um tipo de job específico para migrações contínuas. Esses jobs de migração contínua oferecem suporte a migrações de alta fidelidade para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL.
Quando você usa o Database Migration Service para migrar para o Cloud SQL para PostgreSQL ou o AlloyDB para PostgreSQL, há pré-requisitos e limitações associados a cada instância de destino:
Se você estiver migrando para o Cloud SQL para PostgreSQL, use os seguintes recursos:
- A lista completa de pré-requisitos está disponível em Configurar a origem para o PostgreSQL.
- A lista completa de limitações está disponível em Limitações conhecidas do PostgresQL.
Se você estiver migrando para o AlloyDB para PostgreSQL, use os seguintes recursos:
- A lista completa de pré-requisitos está disponível em Configurar a origem do PostgreSQL para o AlloyDB para PostgreSQL.
- A lista completa de limitações está disponível em Limitações conhecidas do PostgreSQL para o AlloyDB para PostgreSQL.
Replicação integrada do mecanismo de banco de dados
A replicação integrada do mecanismo de banco de dados é uma opção alternativa ao Database Migration Service para uma migração contínua.
A replicação do banco de dados representa o processo de copiar e distribuir dados de um banco de dados chamado de banco de dados primário para outros bancos de dados chamados réplicas. O objetivo é aumentar a acessibilidade dos dados e melhorar a tolerância a falhas e a confiabilidade de um sistema de banco de dados. Embora a migração de banco de dados não seja o objetivo principal da replicação de banco de dados, ela pode ser usada como uma ferramenta para alcançar essa meta. A replicação do banco de dados é geralmente um processo contínuo que ocorre em tempo real à medida que os dados são inseridos, atualizados ou excluídos do banco de dados principal. A replicação do banco de dados pode ser feita como uma operação única ou uma sequência de operações em lote.
A maioria dos mecanismos modernos de banco de dados implementa maneiras diferentes de acessar a replicação de bancos de dados. Um tipo de replicação pode ser alcançado copiando e enviando o
registro prévio de escrita ou registro de transações do primário para as réplicas. Essa abordagem
é chamada de replicação física ou binária. Outros tipos de replicação funcionam
distribuindo as instruções SQL brutas que um banco de dados principal recebe, em vez de
replicar as mudanças no nível do sistema de arquivos. Esses tipos de replicação são chamados de replicação lógica. Para o PostgreSQL, também há extensões
de terceiros, como pglogical
, que implementam a replicação lógica com base na
geração de registros prévios de escrita (WAL).
O Cloud SQL oferece suporte à replicação para PostgreSQL. No entanto, existem alguns pré-requisitos e limitações.
Confira a seguir as limitações e pré-requisitos do Cloud SQL para PostgreSQL:
As seguintes versões da Amazon são compatíveis:
- Amazon RDS 9.6.10 e versões mais recentes, 10.5 e versões mais recentes, 11.1 e versões mais recentes, 12, 13, 14
- Amazon Aurora 10.11 e versões mais recentes, 11.6 e versões mais recentes, 12.4 e versões mais recentes e 13.3 e versões mais recentes
O firewall do servidor externo precisa ser configurado para permitir o intervalo de IP interno alocado para o acesso a serviços particulares da rede VPC. O banco de dados de réplica do Cloud SQL para PostgreSQL usa a rede VPC como rede particular.
O firewall do banco de dados de origem precisa ser configurado para permitir todo o intervalo de IP interno alocado para a conexão de serviço particular da rede VPC. A instância de destino do Cloud SQL para PostgreSQL usa essa rede VPC no campo
privateNetwork
da configuraçãoIpConfiguration
.Ao instalar a extensão pglogical em uma instância do Cloud SQL para PostgreSQL, defina a flag
enable_pglogical
comoon
(por exemplo,cloudsql.enable_pglogical=on
).Verifique se o parâmetro
shared_preload_libraries
inclui a extensãopglogical
na instância de origem (por exemplo,shared_preload_libraries=pg_stat_statements,pglogical
). Defina o parâmetrords.logical_replication
como 1. Essa configuração ativa os registros de gravação antecipada no nível lógico.Essas mudanças exigem uma reinicialização da instância principal.
Para mais informações sobre como usar o Cloud SQL para PostgreSQL para replicação, consulte a lista de verificação do servidor externo na seção de replicação do PostgreSQL e também Configurar a replicação lógica e a decodificação para PostgreSQL na documentação oficial do Cloud SQL.
O AlloyDB para PostgreSQL oferece suporte à replicação pela extensão pglogical. Para
ativar a extensão pglogical para a replicação, use o
comando CREATE EXTENSION
. Antes de usar esse comando, defina as
flags do banco de dados alloydb.enable_pglogical
e alloydb.logical_decoding
como on
na instância do AlloyDB para PostgreSQL em que você quer usar a extensão.
A definição dessas flags requer a reinicialização da instância.
Outras abordagens para migração de replicação contínua
Você pode usar o Datastream para replicar mudanças quase em tempo real da sua instância de origem do PostgreSQL. O Datastream usa a captura de dados alterados (CDC) e a replicação para replicar e sincronizar dados. Em seguida, use o Datastream para a replicação contínua do Amazon RDS e do Amazon Aurora. Você 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 o Cloud SQL para PostgreSQL e a instância do AlloyDB para PostgreSQL com o Dataflow usando um modelo flexível do Dataflow ou o Dataproc.
Para mais informações sobre o uso do Datastream e do Dataflow, consulte estes recursos:
- Configurar um banco de dados do Amazon RDS para PostgreSQL no Datastream
- Configurar um banco de dados PostgreSQL do Amazon Aurora no Datastream
- Trabalhar com arquivos de registro WAL do banco de dados PostgreSQL
- Transmitir alterações nos dados em tempo real com o Datastream
- Visão geral do Dataflow
- Modelo flexível do Dataflow para fazer upload de dados em lote do Google Cloud Storage para o AlloyDB para PostgreSQL (e Postgres)
Ferramentas de terceiros para migração de replicação contínuas
Em alguns casos, pode ser melhor usar uma ferramenta de terceiros para a maioria dos mecanismos de bancos de dados Esses casos podem ocorrer se você preferir usar um serviço de migração gerenciado e precisar garantir que o banco de dados de destino esteja sempre em sincronização quase em tempo real com a origem ou se precisar de transformações mais complexas, como limpeza, reestruturação e adaptação de dados durante o processo de migração.
Se decidir usar uma ferramenta de terceiros, escolha uma das seguintes opções recomendadas que podem ser usadas para a maioria dos mecanismos de banco de dados.
O Striim é uma plataforma completa na memória, para coletar, filtrar, transformar, enriquecer, agregar, analisar e entregar dados em tempo real:
Vantagens:
- Processamento de grandes volumes de dados e migrações complexas.
- Captura de dados alterados integrada do SQL Server.
- Modelos de conexão pré-configurados e pipelines sem código.
- Capacidade de lidar com grandes bancos de dados essenciais que operam sob uma grande carga transacional.
- Entrega exatamente uma vez.
Desvantagens:
- Não é código aberto.
- Pode se tornar caro, principalmente para migrações longas.
- Algumas limitações na propagação de operações de linguagem de definição de dados (DDL, na sigla em inglês). Para mais informações, consulte Operações DDL compatíveis e Observações e limitações da evolução do esquema.
Para saber mais sobre o Striim, consulte Como executar o Striim no Google Cloud.
O Debezium é uma plataforma distribuída de código aberto para CDC que transmite alterações de dados para assinantes externos:
Vantagens:
- Código aberto.
- Forte suporte da comunidade.
- Econômico.
- Controle refinado de linhas, tabelas ou bancos de dados.
- Especializado na captura de alterações em tempo real de logs de transações de banco de dados.
Desvantagens:
- Exige experiência específica com Kafka e ZooKeeper.
- Entrega de alterações de dados pelo menos uma vez, o que significa que você precisa lidar com duplicatas.
- Configuração de monitoramento manual usando Grafana e Prometheus.
- Não há suporte para replicação incremental em lote.
Para saber mais sobre as migrações do Debezium, consulte Replicação de dados quase em tempo real usando o Debezium.
O Fivetran é uma plataforma automatizada de movimentação de dados para transferir dados para fora e entre plataformas de dados em nuvem.
Vantagens:
- Modelos de conexão pré-configurados e pipelines sem código.
- Propague todas as mudanças de esquema da origem para o banco de dados de destino.
- Entrega de alterações de dados exatamente uma vez, o que significa que você não precisa lidar com duplicatas.
Desvantagens:
- Não é código aberto.
- O suporte a transformações complexas de dados é limitado.
Definir o plano e o cronograma de migração
Para uma migração bem-sucedida do banco de dados e uma transferência da produção, recomendamos a preparação de um plano de migração abrangente e bem definido. Para reduzir o impacto nos seus negócios, recomendamos criar uma lista com todos os itens de trabalho necessários.
Definir o escopo da migração revela as tarefas de trabalho que precisam ser realizadas antecipadamente, durante e após o processo de migração do banco de dados. Por exemplo, se decidir não migrar determinadas tabelas de um banco de dados, pode ser necessário uma pré-migração ou tarefas pós-migração para implementar essa filtragem. Você também garante que a migração do banco de dados não afeta o contrato de nível de serviço (SLA) e o plano de continuidade de negócios.
Recomendamos que a documentação de planejamento da migração inclua os seguintes documentos:
- Documento de projeto técnico (TDD)
- Matriz RACI
- Cronograma (como um plano T-minus)
As migrações de banco de dados são um processo iterativo, e as primeiras migrações costumam ser mais lentas do que as posteriores. Normalmente, migrações bem planejadas ocorrem sem problemas, mas problemas não planejados ainda podem surgir. Recomendamos que você sempre tenha um plano de reversão. Como prática recomendada, siga as orientações de Migrar para Google Cloud: práticas recomendadas para validar um plano de migração.
TDD
O TDD documenta todas as decisões técnicas a serem tomadas para o projeto. Inclua o seguinte no TDD:
- Requisitos e importância dos negócios
- Objetivo do tempo de recuperação (RTO)
- Objetivo do ponto de recuperação (RPO)
- Detalhes da migração do banco de dados
- Estimativas do esforço de migração
- Recomendações de validação da migração
Matriz RACI
Alguns projetos de migração exigem uma matriz RACI, que é um documento comum de gerenciamento de projetos que define quais indivíduos ou grupos são responsáveis por tarefas e entregas no projeto de migração.
Cronograma
Prepare um cronograma para cada banco de dados que precisa ser migrado. Inclua todas as tarefas de trabalho que devem ser realizadas e defina datas de início e término estimadas.
Para cada ambiente de migração, recomendamos que você crie um plano T-minus. Um plano T-minus é estruturado como uma programação de contagem regressiva e lista todas as tarefas necessárias para concluir o projeto de migração, junto com os grupos responsáveis e a duração estimada.
O cronograma precisa considerar não apenas a execução de tarefas de preparação para a pré-migração, assim como tarefas de validação, auditoria ou teste que ocorrem após uma transferência de dados.
A duração das tarefas de migração normalmente depende do tamanho do banco de dados, mas há outros aspectos que devem ser considerados, como complexidade da lógica de negócios, uso e disponibilidade da equipe.
Um plano T-Minus pode ser:
Data | Fase | Categoria | Tarefas | Papel | T-minus | Status |
---|---|---|---|---|---|---|
11/1/2023 | Pré-migração | Avaliação | Criar relatório de avaliação | Equipe de descoberta | -21 | Concluído |
11/7/2023 | Pré-migração | Preparação do destino | Projetar o ambiente de destino conforme descrito pelo documento de projeto | Equipe de migração | -14 | Concluído |
11/15/2023 | Pré-migração | Governança da empresa | Data da migração e aprovação T-minus | Liderança | -6 | Concluído |
11/18/2023 | Migração | Configurar o DMS | Criar perfis de conexão | Engenheiro de migração para a nuvem | -3 | Concluído |
11/19/2023 | Migração | Configurar o DMS | Criar e iniciar jobs de migração | Engenheiro de migração para a nuvem | -2 | Não iniciado |
11/19/2023 | Migração | Monitorar DMS | Monitorar jobs do DMS e alterações de DDL na instância de origem | Engenheiro de migração para a nuvem | -2 | Não iniciado |
11/21/2023 | Migração | Substituir DMS | Promover réplica do DMS | Engenheiro de migração para a nuvem | 0 | Não iniciado |
11/21/2023 | Migração | Validação da migração | Validação da migração de bancos de dados | Equipe de migração | 0 | Não iniciado |
11/21/2023 | Migração | Teste de aplicativo | Executar testes de recursos e desempenho | Equipe de migração | 0 | Não iniciado |
22/11/2023 | Migração | Governança da empresa | Validação da migração IR ou NÃO IR | Equipe de migração | 1 | Não iniciado |
11/23/2023 | Pós-migração | Validar o monitoramento | Configurar o monitoramento | Equipe de infraestrutura | 2 | Não iniciado |
11/25/2023 | Pós-migração | Segurança | Remover conta de usuário do DMS | Equipe de segurança | 4 | Não iniciado |
Várias migrações de banco de dados
Para migrar vários bancos de dados, o plano de migração deve conter as tarefas de todas as migrações.
Inicie o processo migrando um bucket menor, um banco de dados não essencial. Essa abordagem pode ajudar você a criar conhecimento e confiança no processo e nas ferramentas de migração. Você também pode detectar falhas no processo nas etapas iniciais do cronograma geral de migração.
Se quiser migrar vários bancos de dados, os cronogramas poderão ser carregados em paralelo. Por exemplo, para acelerar o processo de migração, migre um grupo de bancos de dados pequenos, estáticos ou menos importantes ao mesmo tempo, conforme mostrado no diagrama a seguir.
No exemplo mostrado no diagrama, os bancos de dados 1-4 são um grupo de pequenos bancos de dados migrados ao mesmo tempo.
Definir as tarefas de preparação
As tarefas de preparação são todas as atividades que você precisa fazer para atender aos pré-requisitos de migração. Sem as tarefas de preparação, a migração pode não ocorrer ou os resultados da migração no banco de dados migrado pode se tornar inutilizável.
As tarefas de preparação podem ser categorizadas da seguinte maneira:
- Preparações e pré-requisitos para uma instância do Amazon RDS ou do Amazon Aurora
- Preparação e pré-requisitos do banco de dados de origem
- Configuração de instâncias do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL
- Configuração específica da migração
Preparação e pré-requisitos de instâncias do Amazon RDS ou do Amazon Aurora
Considere as seguintes tarefas comuns de configuração e pré-requisito:
- Dependendo do caminho de migração, talvez seja necessário permitir conexões remotas nas instâncias de RDS. Caso a instância de RDS esteja configurada para ser particular na VPC, a conectividade da RFC 1918 particular entre a Amazon e Google Cloudprecisa existir.
Talvez seja necessário configurar um novo grupo de segurança para permitir o acesso remoto nas portas necessárias e aplicá-lo à sua instância do Amazon RDS ou Amazon Aurora:
- Por padrão, na AWS, o acesso à rede é ativado para instâncias de banco de dados.
- É possível especificar regras em um grupo de segurança que permitam o acesso a um intervalo de endereços IP, uma porta ou um grupo de segurança. As mesmas regras se aplicam a todas as instâncias do banco de dados associadas a esse grupo de segurança.
Se você estiver migrando do Amazon RDS, verifique se há espaço livre suficiente em disco para armazenar em buffer os registros de gravação antecipada durante toda a duração da operação de carregamento total na instância do Amazon RDS.
Para uma replicação contínua (streaming de alterações pelo CDC), use uma instância RDS completa e não uma réplica de leitura.
Se você estiver usando a replicação integrada, será necessário configurar a instância do Amazon RDS ou do Amazon Aurora para a replicação do PostgreSQL. A replicação integrada ou as ferramentas que a utilizam precisam de replicação lógica para o PostgreSQL.
Se estiver usando ferramentas de terceiros, configurações iniciais geralmente são necessárias antes de usar a ferramenta. Confira a documentação na ferramenta de terceiros.
Para mais informações sobre a preparação da instância e os pré-requisitos, consulte Configurar o servidor externo para replicação do PostgreSQL.
Preparação e pré-requisitos do banco de dados de origem
Se você usar o Database Migration Service, configure o banco de dados de origem antes de se conectar a ele. Para mais informações, consulte Configurar a origem para PostgreSQL e Configurar a origem para PostgreSQL no AlloyDB para PostgreSQL.
Para tabelas que não têm chaves primárias, depois que o Database Migration Service migra o backup inicial, apenas instruções
INSERT
são migradas para o banco de dados de destino durante a fase de CDC. As instruçõesDELETE
eUPDATE
não são migradas para essas tabelas.Objetos grandes não podem ser replicados pelo Database Migration Service, porque a decodificação lógica no PostgreSQL não oferece suporte a mudanças de decodificação em objetos grandes.
Se você optar por usar a replicação integrada, considere que a replicação lógica tem algumas limitações em relação a comandos, sequências e objetos grandes da linguagem de definição de dados (DDL). As chaves primárias precisam existir ou ser adicionadas a tabelas que serão ativadas para o CDC e que passam por muitas atualizações.
Algumas ferramentas de migração de terceiros exigem que todas as colunas de objetos grandes sejam anuláveis. Todas as colunas de objetos grandes que são
NOT NULL
precisam ter essa restrição removida durante a migração.Faça medições de valor de referência no ambiente de origem em uso na produção. Considere o seguinte:
- Meça o tamanho dos dados e o desempenho da carga de trabalho. Quanto tempo levam em média as consultas ou transações importantes? Quanto tempo elas levam durante os horários de pico?
- Documente as medidas de valor de referência para comparar posteriormente e determinar se a fidelidade da migração do banco de dados é satisfatória. Decida se é possível migrar as cargas de trabalho de produção e desativar o ambiente de origem ou se você ainda precisa dele para fins de substituição.
Configuração de instâncias do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL
Para que a instância de destino atinja níveis de desempenho semelhantes aos da instância de origem, escolha o tamanho e as especificações da instância do banco de dados PostgreSQL de destino para corresponder às da instância de origem. Preste atenção especial ao tamanho do disco e à capacidade de processamento, operações de entrada/saída por segundo (IOPS) e número de CPUs virtuais (vCPUs). O dimensionamento incorreto pode levar um tempo maior de execução da imigração, problemas de desempenho do banco de dados, erros de banco de dados e problemas de de desempenho do aplicativo. Ao decidir sobre a instância do Cloud SQL para PostgreSQL ou do AlloyDB para PostgreSQL, lembre-se de que o desempenho do disco é baseado no tamanho do disco e no número de vCPUs.
Confirme as propriedades e os requisitos a seguir antes de criar as instâncias do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL. Se você quiser mudar essas propriedades e requisitos mais tarde, será necessário recriar as instâncias.
Escolha o projeto e a região das instâncias de destino do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL com cuidado. Não é possível migrar instâncias entre projetos e regiões do Google Cloud sem a transferência de dados.
Migrar para uma versão principal correspondente no Cloud SQL para PostgreSQL e no AlloyDB para PostgreSQL. Por exemplo, se você estiver usando o PostgreSQL 14.x no Amazon RDS ou Amazon Aurora, migre para o Cloud SQL ou o AlloyDB para PostgreSQL para a versão 14.x do PostgreSQL.
Replique as informações do usuário separadamente se você estiver usando o mecanismo de banco de dados integrado ou o Database Migration Service. Para mais detalhes, consulte as limitações na seção Backups específicos do mecanismo de banco de dados.
Analise as sinalizações de configuração específicas do mecanismo de banco de dados e compare os valores das instâncias de origem e de destino. Entenda os impactos e se eles precisam ser iguais ou não. Por exemplo, ao trabalhar com o PostgreSQL, recomendamos comparar os valores da tabela
pg_settings
no banco de dados de origem com o da instância do Cloud SQL e do AlloyDB para PostgreSQL. Atualize as configurações de flag conforme necessário na instância do banco de dados de destino para replicar as configurações de origem.Dependendo da natureza da carga de trabalho, talvez seja necessário ativar extensões específicas para oferecer suporte ao banco de dados. Se a carga de trabalho exigir essas extensões, analise as extensões do PostgreSQL com suporte 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 Opções de configuração de instância, Flags específicas do mecanismo de banco de dados e extensões compatíveis.
Para mais informações sobre a configuração do AlloyDB para PostgreSQL, consulte Siglas de banco de dados compatíveis e extensões compatíveis.
Configuração específica da migração
Se você puder ter inatividade, importe arquivos dump SQL para o Cloud SQL e o AlloyDB para PostgreSQL. Nesses casos, talvez seja necessário criar um bucket do Cloud Storage para armazenar o dump do banco de dados.
Se você usar a replicação, a réplica do Cloud SQL e do AlloyDB para PostgreSQL precisa ter acesso ao banco de dados principal (de origem). Esse acesso pode ser feito usando as opções de conectividade documentadas.
Dependendo do caso de uso e da criticidade, talvez seja necessário implementar um cenário de fallback, que geralmente inclui reverter a direção da replicação. Nesse caso, talvez seja necessário um mecanismo de replicação adicional do Cloud SQL e do AlloyDB para PostgreSQL de destino de volta à instância de origem do Amazon.
É possível desativar os recursos que conectam o ambiente da Amazon e doGoogle Cloud após a conclusão e a validação da migração.
Se você estiver migrando para o AlloyDB para PostgreSQL, considere usar uma instância do Cloud SQL para PostgreSQL como um possível destino para seus cenários de fallback. Use a extensão pglogical para configurar a replicação lógica nessa instância do Cloud SQL.
Para saber mais, acesse os recursos a seguir:
- Práticas recomendadas para importação e exportação de dados
- Conectividade para PostgreSQL e PostgreSQL para AlloyDB para PostgreSQL no Database Migration Service
Definir as tarefas de execução
As tarefas de execução implementam o trabalho de migração. As tarefas dependem da ferramenta de migração escolhida, conforme descrito nas subseções a seguir.
Backups de mecanismo de banco de dados integrados
Use o utilitário pg_dump
para criar um backup. Para mais informações sobre como usar
esse utilitário para importar e exportar dados, consulte os seguintes recursos:
- Página de documentação do utilitário
pg_dump
- Importar dados para o Cloud SQL para PostgreSQL
- Importar um arquivo DMP para o AlloyDB para PostgreSQL
Jobs de migração do Database Migration Service
Defina e configure jobs de migração no Database Migration Service para migrar dados de uma instância de origem para o banco de dados de destino. Os jobs de migração se conectam à instância do banco de dados de origem usando perfis de conexão definidos pelo usuário.
Teste todos os pré-requisitos para garantir que o job seja executado corretamente. Escolha quando as cargas de trabalho podem lidar com um pequeno período de inatividade para a migração e a transferência da produção.
No Database Migration Service, a migração começa com o despejo inicial do esquema e a restauração sem índices e restrições, seguido pela operação de cópia de dados. Depois que a cópia de dados for concluída, os índices e as restrições serão restaurados. Por fim, a replicação contínua de mudanças da origem para a instância do banco de dados de destino é iniciada.
O Database Migration Service usa a extensão
pglogical
para a replicação da origem para a instância de banco de dados de destino. No
início da migração, essa extensão configura a replicação exigindo
bloqueios exclusivos de curto prazo em todas as tabelas da instância de origem do Amazon RDS ou do Amazon
Aurora. Por esse motivo, recomendamos iniciar a migração quando o
banco de dados estiver menos ocupado e evitar instruções na origem durante a fase de despejo
e replicação, já que as instruções DDL não são replicadas. Se você precisar realizar
operações DDL, use as funções "pglogical" para executar instruções DDL na
instância de origem ou execute manualmente as mesmas instruções DDL na instância de destino
da migração, mas somente após o término do estágio de despejo inicial.
O processo de migração com o Database Migration Service termina com a operação de promoção. Promover uma instância de banco de dados desconecta o banco de dados de destino do fluxo de alterações provenientes do banco de dados de origem. Em seguida, a instância de destino independente é promovida a uma instância principal. Essa abordagem também é chamada de switch de produção.
Para um processo de configuração de migração totalmente detalhado, consulte os guias de início rápido para o PostgreSQL e o PostgreSQL para o AlloyDB para PostgreSQL.
Replicação integrada do mecanismo de banco de dados
O Cloud SQL oferece suporte a dois tipos de replicação lógica: a replicação lógica integrada do PostgreSQL e a replicação lógica pela extensão pglogical. Para o AlloyDB para PostgreSQL, recomendamos usar a extensão pglogical
para replicação. Cada tipo de replicação lógica tem seus próprios recursos e limitações.
A replicação lógica integrada tem os seguintes recursos e limitações:
- Ele está disponível no PostgreSQL 10 e em versões mais recentes.
- Todas as mudanças e colunas são replicadas. As publicações são definidas no nível da tabela.
- Os dados são replicados apenas de tabelas base para tabelas base.
- Ele não realiza a replicação de sequência.
- Esse é o tipo de replicação recomendado quando há muitas tabelas sem
chave primária. Configurar a replicação lógica integrada do PostgreSQL. Para tabelas
sem uma chave primária, aplique o formulário
REPLICA IDENTITY FULL
para que a replicação integrada use a linha inteira como o identificador exclusivo em vez de uma chave primária.
A replicação lógica pglogical
tem os seguintes recursos e limitações:
- Ele está disponível em todas as versões do PostgreSQL e oferece suporte a várias versões.
- A filtragem de linhas está disponível na origem.
- Ele não replica as tabelas
UNLOGGED
eTEMPORARY
. - Uma chave primária ou exclusiva é necessária nas tabelas para capturar as alterações de
UPDATE
eDELETE
. - A replicação de sequência está disponível.
- A replicação atrasada é possível.
- Ele oferece detecção de conflitos e resolução configurável se houver vários editores ou conflitos entre dados replicados e mudanças locais.
Para instruções sobre como configurar a replicação lógica integrada do PostgreSQL de um servidor externo, como o Amazon RDS ou o Amazon Aurora para PostgreSQL, consulte os seguintes recursos:
Ferramentas de terceiros
Defina todas as tarefas de execução para a ferramenta de terceiros escolhida.
Esta seção se concentra no Striim como exemplo. O Striim usa aplicativos que coletam dados de várias fontes, processam os dados e os entregam a outros aplicativos ou destinos.
Você usa um ou mais fluxos para organizar esses processos de migração nos aplicativos personalizados. Para programar seus aplicativos personalizados, você pode 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:
Noções básicas do Striim: conceitos do Striim
Guia de início rápido do Striim no Google Cloud : Como executar o Striim no Google Cloud
Configurações de configuração para a replicação contínua: PostgreSQL e SQL Server
Guia de práticas recomendadas: Como mudar de uma carga inicial para a replicação contínua
Se você decidir usar o Striim para migrar seus dados, consulte os guias a seguir sobre como usar o Striim para migrar dados para o Google Cloud:
- Tutoriais do Striim Migration Service para Google Cloud
- Como migrar bancos de dados transacionais para o AlloyDB para PostgreSQL
Definir cenários de fallback
Defina ações necessárias de fallback para cada tarefa de execução de migração para se proteger contra imprevistos que podem ocorrer durante o processo de migração. As tarefas de fallback geralmente dependem da estratégia de migração e das ferramentas usadas.
A substituição pode exigir um esforço significativo. A prática recomendada é não realizar a transferência até que os resultados do teste sejam satisfatórios. A migração do banco de dados e o cenário de fallback devem ser testados adequadamente para evitar uma interrupção grave do serviço.
Defina os critérios de sucesso e o tempo de todas as tarefas de execução de migração. Fazer uma simulação da migração ajuda a coletar informações sobre os tempos esperados para cada tarefa. Por exemplo, para uma migração de manutenção programada, é possível obter o tempo de inatividade representado pela janela de transferência. No entanto, é importante planejar sua próxima ação caso o job de migração única ou a restauração do backup falhe no meio do caminho. Dependendo do tempo decorrido do tempo de inatividade planejado, talvez seja necessário adiar a migração se a tarefa de migração não for concluída no tempo esperado.
Um plano de fallback geralmente reverte a migração depois de executar a transferência da produção se houver problemas na instância de destino. Se você implementar um plano de fallback, ele deve ser tratado como uma migração de banco de dados completa, incluindo planejamento e teste.
Se você optar por não ter um plano de fallback, entenda as possíveis consequências. Não ter um plano de fallback pode gerar um esforço imprevisto e causar interrupções evitáveis no processo de migração.
Embora um plano substituto seja um último recurso e a maioria das migrações de banco de dados acabe não usando-o, recomendamos sempre ter uma estratégia de fallback.
Fallback simples
Nessa estratégia de fallback, retorne os aplicativos à instância do banco de dados de origem. Adote essa estratégia se você puder arcar com o tempo de inatividade quando fizer o fallback ou se não precisar que as transações sejam confirmadas no novo sistema de destino.
Se precisar de todos os dados gravados no banco de dados de destino e puder ficar inativo por algum tempo, considere interromper as gravações na instância do banco de dados de destino, fazer backups integrados e restaurá-los na instância de origem e, por fim, reconectar os aplicativos à instância inicial do banco de dados de origem. Dependendo da natureza da carga de trabalho e da quantidade de dados gravados na instância do banco de dados de destino, você pode trazê-los para o sistema de banco de dados de origem inicial posteriormente, especialmente se as cargas de trabalho não dependerem de nenhum horário específico de criação registrado ou de nenhuma restrição de ordenação de tempo.
Replicação reversa
Nessa estratégia, você replica as gravações que ocorrem no novo destino do banco de dados após a transferência da produção retornar ao banco de dados de origem inicial. Dessa maneira, você mantém a fonte original sincronizada com o novo banco de dados de destino e fica com as gravações na nova instância do banco de dados de destino. A principal desvantagem é que não é possível testar o fluxo de replicação até depois de fazer a transferência para a instância do banco de dados de destino. Portanto, não é possível realizar testes completos e você fica um pequeno período sem fallback.
Escolha essa abordagem quando for possível manter a instância de origem por algum tempo e usar a migração de replicação contínua.
Replicação direta
Essa estratégia é uma variação da replicação reversa. Você replica a gravação no novo banco de dados de destino em uma terceira instância do banco de dados de sua escolha. É possível apontar os aplicativos para esse terceiro banco de dados, que se conecta ao servidor e executa consultas somente leitura enquanto o servidor não está disponível. É possível usar qualquer mecanismo de replicação, dependendo das suas necessidades. A vantagem dessa abordagem é que ela pode ser totalmente testada.
Adote essa abordagem para a cobertura de fallback em todos os momentos ou para descartar o banco de dados de origem inicial logo após a operação de transferência.
Escritas duplicadas
Se escolher uma migração de microsserviço de acesso aos dados ou Y (gravação e leitura), essa estratégia já estará definida. Essa estratégia é mais complicada, porque você precisa refatorar os aplicativos ou desenvolver ferramentas que se conectam às instâncias do bancos de dados.
os aplicativos gravam nas instâncias de banco de dados iniciais e de destino; que permitem fazer uma transferência gradual da produção até usar apenas as instâncias do banco de dados de destino. Se ocorrer um erro, conecte os aplicativos de volta à origem assim que perceber. Só descarte a fonte inicial e o mecanismo de gravação duplicado quando considerar que a migração foi realizada sem problemas.
Recomendamos essa abordagem quando for necessário não ter tempo de inatividade na migração, ter um substituto confiável e tiver tempo e recursos para a refatoração dos aplicativos.
Realizar testes e validações
Os objetivos desta etapa são testar e validar:
- A migração dos dados no banco de dados que foi concluída.
- A integração com aplicativos existentes após a mudança para a nova instância de destino.
Defina os principais fatores de sucesso, que estão relacionados à sua migração. Exemplos de fatores subjetivos:
- Quais dados migrar. Para algumas cargas de trabalho, pode não ser necessário migrar todos os dados. Talvez você não queira migrar os dados que já estão agregados, redundantes, arquivados ou são antigos. É possível arquivar esses dados em um bucket do Google Cloud Storage, como um backup.
- Uma porcentagem aceitável de perda de dados. Isso se aplica particularmente aos dados usados para cargas de trabalho analíticas, em que a perda de parte dos dados não afeta as tendências gerais ou o desempenho das cargas de trabalho.
- Critérios de qualidade e quantidade de dados, que podem ser aplicados ao ambiente de origem e comparados com o ambiente de destino após a migração.
- Critérios de desempenho. Algumas transações de negócios podem ser mais lentas no ambiente de destino, mas o tempo de processamento ainda está dentro das expectativas definidas.
As configurações de armazenamento no ambiente de origem podem não ser mapeadas diretamente para os destinos do ambienteGoogle Cloud . Por exemplo, as configurações de Volumes SSD de uso geral (gp2 e gp3) com desempenho de burst de IOPS ou SSD de IOPS provisionado. Para comparar e dimensionar corretamente as instâncias de destino, compare as instâncias de origem nas fases de avaliação e validação.
No processo de comparativo de mercado, aplique as sequências de operações semelhantes à produção às instâncias do banco de dados. Durante esse período, capture e processe as métricas para mensurar e comparar o desempenho relativo dos sistemas de origem e de destino.
Para configurações convencionais com base no servidor, use medidas relevantes observadas durante os picos de carga. Para modelos de capacidade de recursos flexíveis, como o Aurora sem servidor, considere analisar dados históricos de métricas para observar o escalonamento necessário.
As seguintes ferramentas podem ser usadas para teste, validação e comparativo de mercado do banco de dados:
- HammerDB: ferramenta de comparativo de mercado e teste de carga de banco de dados de código aberto. Ele é compatível com cargas de trabalho transacionais e analíticas complexas, com base em padrões do setor, em diferentes mecanismos de banco de dados (TPROC-C e TPROC-H). O HammerDB tem uma documentação detalhada e uma grande comunidade de usuários. Ele compartilha e compara resultados de diferentes mecanismos de banco de dados e configurações de armazenamento. Para mais informações, consulte Teste de carga do SQL Server usando o HammerDB e Comparativo de mercado de desempenho do Amazon RDS SQL Server usando o HammerDB.
- Ferramenta de comparativo de mercado do DBT2: comparativo de mercado especializado em MySQL. Um conjunto de kits de carga de trabalho de banco de dados imita um aplicativo para uma empresa que possui armazéns e envolve uma combinação de leitura e gravação de transações. Use essa ferramenta se quiser utilizar um modelo de processamento de transações on-line (OLTP, na sigla em inglês).
- DbUnit: ferramenta de teste de unidade de código aberto usada para testar interações de bancos de dados relacionais no Java. A configuração e o uso são simples e oferecem suporte a diferentes mecanismos de banco de dados (MySQL, PostgreSQL, SQL Server e outros). No entanto, a execução do teste pode às vezes ser lenta, dependendo do tamanho e da complexidade do banco de dados. Recomendamos essa ferramenta quando a simplicidade for muito importante.
- DbFit: framework de testes de banco de dados de código aberto compatível com o código orientado por testes de desenvolvimento e testes automatizados. Ele usa uma sintaxe básica para criar casos de teste e apresenta testes orientados a dados, controle de versões e relatórios de resultados de teste. No entanto, o suporte a consultas e transações complexas é limitado e não tem um grande suporte da comunidade nem uma documentação extensa, em comparação com outras ferramentas. Recomendamos essa ferramenta se as consultas não forem complexas e para realizar testes automatizados e integrá-los ao processo de integração e entrega contínuas.
Para executar um teste completo, incluindo o teste do plano de migração, faça sempre um exercício de simulação de migração. Uma simulação executa a migração do banco de dados de escopo completo sem mudar qualquer carga de trabalho e oferece as seguintes vantagens:
- A migração correta de todos os objetos e configurações.
- Ajuda a definir e executar os casos de teste de migração.
- Oferece insights sobre o tempo necessário para a migração, para que você possa calibrar a linha do tempo.
- Representa uma ocasião para testar, validar e adaptar o plano de migração. Às vezes, não é possível planejar tudo com antecedência, então isso ajuda você a detectar lacunas.
O teste de dados pode ser realizado em um pequeno conjunto de bancos de dados a serem migrados ou de todo o conjunto. Dependendo do número total de bancos de dados e das ferramentas usadas para implementar a migração, você pode decidir adotar uma abordagem baseada em riscos. Com essa abordagem, você realiza a validação de dados em um subconjunto de bancos de dados migrados com a mesma ferramenta, principalmente se for um serviço de migração gerenciado.
Para testes, você deve ter acesso aos bancos de dados de origem e de destino e concluir as seguintes tarefas:
- Comparar esquemas de origem e de destino. Verificar se todas as tabelas e executáveis existem. Verificar contagens de linhas e comparar dados no nível do banco de dados.
- Executar scripts de validação de dados personalizados.
- Testar se os dados migrados também estão visíveis nos aplicativos que migraram para o banco de dados de destino (os dados migrados são lidos pelo aplicativo).
- Realize testes de integração entre os aplicativos migrados e o banco de dados de destino testando vários casos de uso. Esse teste inclui a leitura e a gravação dos dados nos bancos de dados de destino pelo aplicativos. Dessa maneira, as cargas de trabalho aceitam totalmente os dados migrados com os dados recém-criados.
- Teste o desempenho das consultas de banco de dados mais usadas para observar se houve uma degradação devido a configurações incorretas ou dimensionamento incorreto.
O ideal é que todos esses cenários de teste de migração sejam automatizados e repetíveis em qualquer sistema de origem. O pacote de casos de teste automatizados é adaptado para ter um bom desempenho em relação aos aplicativos migrados.
Se você estiver usando o Database Migration Service como ferramenta de migração, consulte a versão PostgreSQL ou PostgreSQL para AlloyDB para PostgreSQL do tópico "Verificar uma migração".
Ferramenta de validação de dados
Para realizar a validação de dados, recomendamos o uso da Ferramenta de validação de dados (DVT, na sigla em inglês): A DVT é uma ferramenta de CLI Python de código aberto, com o suporte do Google, que fornece uma solução automatizada e repetível para a validação em ambientes diferentes.
A DVT simplifica o processo de validação de dados oferecendo funções de validação multinível para comparar as tabelas de origem e destino em tabelas, colunas e linhas. Também é possível adicionar regras de validação.
A DVT abrange muitas Google Cloud fontes de dados, incluindo AlloyDB para PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON e arquivos CSV no Cloud Storage. Ela também pode ser integrada às funções do Cloud Run e ao Cloud Run para acionamento e orquestração com base em eventos.
A DVT é compatível com os seguintes tipos de validações:
- Comparações no nível do esquema
- Coluna (incluindo "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" e "STRING_AGG")
- Linha (incluindo hash e correspondência exata em comparações de campo)
- Comparação dos resultados da consulta personalizada
Para mais informações sobre a DVT, consulte o Repositório Git e a Validação de dados facilitada com a ferramenta de validação de dados do Google Cloud.
Faça a migração
As tarefas de migração incluem as atividades para realizar a transferência de um sistema para outro.
Considere as seguintes práticas recomendadas para a migração de dados:
- Informe as equipes envolvidas sempre que uma etapa do plano começar e terminar.
- Se alguma das etapas demorar mais do que o esperado, compare o tempo decorrido com a quantidade máxima de tempo alocada para essa etapa. Faça atualizações intermediárias regulares com as equipes envolvidas se isso acontecer.
- Se o período for maior que a quantidade máxima de tempo reservada para cada etapa do plano, considere a reversão.
- Escolha realizar ou não cada etapa da migração e o plano de transferência.
- Considere ações de reversão ou cenários alternativos para cada uma das etapas.
Faça a migração seguindo as tarefas de execução definidas e consulte a documentação da ferramenta de migração selecionada.
Executar a transferência da produção
O processo de transferência da produção em alto nível pode variar, dependendo estratégia de migração. Se houver inatividade nas cargas de trabalho, a transferência da migração começa com a interrupção das gravações no banco de dados de origem.
Para migrações de replicação contínua, cumpra as seguintes etapas de alto nível no processo de transferência:
- Interrompa a gravação no banco de dados de origem.
- Drene a origem.
- Interrompa o processo de replicação.
- Implante os aplicativos que apontam para o novo banco de dados de destino.
Após migrar os dados com a ferramenta de migração escolhida, valide os dados no banco de dados de destino. Confirme que o banco de dados de origem e os bancos de dados de destino estejam sincronizados e os dados na instância de destino estejam de acordo com os padrões de sucesso da migração escolhidos.
Depois que a validação de dados for aprovada de acordo com seus critérios, é possível realizar a transferência de nível do aplicativo. Implante as cargas de trabalho refatoradas para usar a nova instância de destino. Implante as versões dos aplicativos que apontam para o nova instância do banco de dados de destino. As implantações podem ser realizadas por atualizações graduais, lançamentos em fase de testes ou usando um padrão de implantação azul-verde. Às vezes pode ocorrer a inatividade do aplicativo.
Siga as práticas recomendadas para a transferência da produção:
- Monitore os aplicativos que funcionam com o banco de dados de destino após a transferência.
- Defina um período de monitoramento para avaliar se você precisa implementar o plano de fallback.
- A instância do Cloud SQL ou AlloyDB para PostgreSQL pode precisar reiniciar algumas flags do banco de dados forem alteradas.
- O esforço de reverter a migração pode ser maior do que corrigir os problemas que aparecem no ambiente de destino.
Limpar o ambiente de origem e configurar a instância do Cloud SQL ou AlloyDB para PostgreSQL
Depois que a transferência for concluída, você poderá excluir os bancos de dados de origem. Recomendamos as seguintes ações importantes antes da limpeza da instância de origem:
Crie um backup final de todos os bancos de dados de origem. Esses backups apresentam o estado final dos bancos de dados de origem. Os backups também podem ser necessários em alguns casos de conformidade com regulamentos de dados.
Colete as configurações de parâmetros do banco de dados da instância de origem. Outra opção é verificar se elas correspondem aos que você reuniu na fase de criação de inventário. Ajuste os parâmetros da instância de destino para que correspondam à instância de origem.
Colete as estatísticas do banco de dados na instância de origem e compare-as as estatísticas na instância de destino. Se as estatísticas forem diferentes, é difícil comparar o desempenho das instâncias de origem e de destino.
Em um cenário de fallback, convém implementar a replicação da gravação na instância do Cloud SQL de volta ao banco de dados de origem. A configuração é semelhante ao processo de migração, mas seria executada ao contrário: o banco de dados de origem se tornaria o novo destino.
Como prática recomendada para manter as instâncias de origem atualizadas após a transferência, replique as gravações realizadas nas instâncias do Cloud SQL de destino novamente no banco de dados de origem. Se você precisar reverter, poderá voltar às instâncias de origem antigas com o mínimo de perda de dados.
Como alternativa, use outra instância e repita as mudanças nela. Por exemplo, quando o AlloyDB para PostgreSQL é um destino de migração, configure a replicação para uma instância do Cloud SQL para PostgreSQL para cenários de fallback.
Além da limpeza do ambiente de origem, as seguintes configurações importantes para as instâncias do Cloud SQL para PostgreSQL precisam ser feitas:
- Configure uma janela de manutenção para a instância principal para controlar quando as atualizações disruptivas podem ser realizadas.
- Configure o armazenamento na instância para ter um espaço de no mínimo 20% disponível para acomodar operações importantes de manutenção do banco de dados que o Cloud SQL possa executar. Para receber um alerta se o espaço disponível em disco ficar abaixo de 20%, crie uma política de alertas com base em métricas para a métrica de utilização do disco.
Não inicie uma operação administrativa antes que a operação anterior seja concluída.
Para mais informações sobre manutenção e práticas recomendadas em instâncias do Cloud SQL para PostgreSQL e do AlloyDB para PostgreSQL, consulte os seguintes recursos:
- Sobre a manutenção em instâncias do Cloud SQL para PostgreSQL
- Sobre as configurações de instâncias do Cloud SQL para PostgreSQL
- Sobre a manutenção no AlloyDB para PostgreSQL
- Configurar as flags de banco de dados de uma instância do AlloyDB para PostgreSQL
Para mais informações sobre manutenção e práticas recomendadas, consulte Sobre a manutenção em instâncias do Cloud SQL.
Otimizar o ambiente após a migração
A otimização é a última fase da migração. Nesta fase, você repete as tarefas de otimização até que o ambiente de destino atenda aos requisitos de otimização. As etapas de cada iteração são as seguintes:
- Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
- Estabeleça suas metas e requisitos de otimização.
- Otimize o ambiente e as equipes.
- Ajustar o loop de otimização.
Repita essa sequência até alcançar suas metas de otimização.
Para mais informações sobre como otimizar o ambiente do Google Cloud , consulte Migrar para Google Cloud: otimizar o ambiente e Framework de arquiteturaGoogle Cloud : otimização de performance.
Estabelecer seus requisitos de otimização
Analise os requisitos de otimização a seguir para o ambiente do Google Cloud e escolha os que melhor se adaptam às suas cargas de trabalho:
Aumentar a confiabilidade e a disponibilidade do banco de dados
Com o Cloud SQL, é possível implementar uma abordagem de alta disponibilidade e estratégia de recuperação de desastres que se alinham com o objetivo do tempo de recuperação (RTO, na sigla em inglês) e o objetivo do ponto de recuperação (RPO, na sigla em inglês). Para aumentar a confiabilidade e a disponibilidade, considere o seguinte:
- Para cargas de trabalho com muita leitura, adicione réplicas de leitura para descarregar o tráfego da instância principal.
- Para cargas de trabalho essenciais, use a configuração de alta disponibilidade, réplicas de failover regional e uma configuração robusta de recuperação de desastres.
- Para cargas de trabalho menos críticas, criar backups automatizados e sob demanda pode ser suficiente.
Para evitar a remoção acidental de instâncias, use a proteção de exclusão de instâncias.
Ao migrar para o Cloud SQL para PostgreSQL, considere usar o Cloud SQL Enterprise Plus para aproveitar os benefícios do aumento da disponibilidade, da retenção de registros e da manutenção planejada com tempo de inatividade próximo a zero. Para mais informações sobre o Cloud SQL Enterprise Plus, consulte Introdução às edições do Cloud SQL e Manutenção planejada com tempo de inatividade próximo a zero.
Para mais informações sobre como aumentar a confiabilidade e a disponibilidade do seu banco de dados do Cloud SQL para PostgreSQL, consulte os seguintes documentos:
Ao migrar para o AlloyDB para PostgreSQL, configure os planos de backup e considere usar o proxy de autenticação do AlloyDB para PostgreSQL. Considere criar e trabalhar com clusters secundários para a replicação entre regiões.
Para mais informações sobre como aumentar a confiabilidade e a disponibilidade do banco de dados do AlloyDB para PostgreSQL, consulte os seguintes documentos:
Aumentar o custo-benefício da infraestrutura do banco de dados
Para ter um impacto econômico positivo, as cargas de trabalho precisam usar recursos e serviços com eficiência. Considere as seguintes opções:
Forneça ao banco de dados a capacidade de armazenamento mínima necessária ao:
- Para escalonar a capacidade de armazenamento automaticamente à medida que os dados aumentam, ative os aumentos automáticos de armazenamento. No entanto, não se esqueça de configurar que as instâncias tenham buffer em cargas de trabalho de pico. As cargas de trabalho do banco de dados as cargas de trabalho costumam a aumentar com o tempo.
Identifique possíveis recursos superestimados:
- O redimensionamento das instâncias do Cloud SQL pode reduzir os custos de infraestrutura sem adicionar riscos à capacidade de gerenciamento de projetos.
- O Cloud Monitoring tem painéis predefinidos que ajudam a identificar a integridade e a utilização da capacidade de muitos Google Cloud componentes, incluindo o Cloud SQL. Para mais detalhes, consulte Criar e gerenciar painéis personalizados.
Identifique instâncias que não exigem alta disponibilidade ou configurações de recuperação de desastres e remova-as da infraestrutura.
Remova tabelas e objetos que não são mais necessários. É possível armazená-los em um backup completo ou em um bucket de arquivamento do Cloud Storage.
Avalie o tipo de armazenamento mais econômico (SSD ou HDD) para seu caso de uso.
- Na maioria dos casos de uso, o SSD é mais eficiente e a opção mais econômica.
- Se os conjuntos de dados forem grandes (10 TB ou mais), não sensíveis à latência ou acessados com pouca frequência, o HDD pode ser mais apropriado.
- Para mais detalhes, consulte Escolher entre armazenamento SSD e HDD.
Compre descontos por compromisso de uso para cargas de trabalho com necessidades previsíveis de recursos.
Use o Active Assist para receber insights e recomendações de custo.
Para mais informações e opções, consulte Faça mais com menos: conheça as recomendações de otimização de custos do Cloud SQL com o Active Assist.
Ao migrar para o Cloud SQL para PostgreSQL, é possível reduzir instâncias sobreprovisionadas e identificar instâncias do Cloud SQL para PostgreSQL inativas.
Para mais informações sobre como aumentar a eficiência de custos da sua instância de banco de dados do Cloud SQL para PostgreSQL, consulte os seguintes documentos:
- Ativar o aumento automático de armazenamento do Cloud SQL
- Identificar instâncias inativas do Cloud SQL
- Reduzir o provisionamento de instâncias em excesso do Cloud SQL
- Otimizar consultas com alto uso de memória
- Criar e gerenciar painéis personalizados
- Escolher entre armazenamento SSD e HDD
- Descontos por compromisso de uso
- Active Assist
Ao usar o AlloyDB para PostgreSQL, faça o seguinte para aumentar a eficiência dos custos:
- Use o mecanismo colunar para executar de maneira eficiente determinadas consultas analíticas, como funções de agregação ou verificações de tabela.
- Use o recomendador de cota de armazenamento de cluster do AlloyDB para PostgreSQL para detectar clusters que estão em risco de atingir a cota de armazenamento.
Para mais informações sobre como aumentar a relação custo-benefício da infraestrutura do banco de dados do AlloyDB para PostgreSQL, consulte as seguintes seções da documentação:
Aumentar o desempenho da infraestrutura do banco de dados
Pequenos problemas de desempenho relacionados ao banco de dados frequentemente podem afetar toda a operação. Para manter e aumentar a performance da instância do Cloud SQL, considere as seguintes diretrizes:
- Se houver um grande número de tabelas do banco de dados, elas podem afetar o desempenho e a disponibilidade das instâncias, além de fazer com que a instância perca a cobertura do SLA.
Verifique se a instância não está limitada por memória ou CPU.
- Para cargas de trabalho que exigem alto desempenho, verifique se a instância tem pelo menos 60 GB de memória.
- Para inserções, atualizações ou exclusões demoradas de banco de dados, verifique os locais do gravador e do banco de dados. O envio de dados por uma longa distância gera latência.
Melhore o desempenho da consulta usando painéis do Query Insights predefinidos no Cloud Monitoring (ou um mecanismo de banco de dados similar de recursos integrados). Identifique os comandos mais caros e tente otimizá-los.
Evite o crescimento desnecessário do banco de dados. Defina
autogrow
em MBs em vez de porcentagem, usando incrementos adequados para o requisito.Verifique o local do leitor e do banco de dados. A latência afeta o desempenho de leitura mais do que desempenho de gravação.
Ao migrar do Amazon RDS e do Aurora para PostgreSQL para o Cloud SQL para PostgreSQL, considere estas diretrizes:
- Use o armazenamento em cache para melhorar o desempenho de leitura. Inspecione as várias estatísticas
da
visualização
pg_stat_database
. Por exemplo, a proporçãoblks_hit / (blks_hit + blks_read)
precisa ser maior que 99%. Se essa proporção não for maior que 99%, considere aumentar o tamanho da RAM da instância. Para mais informações, consulte Coletor de estatísticas do PostgreSQL. - Recupere espaço e evite a baixa performance do índice. Dependendo da frequência
de mudança dos dados, defina uma programação 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 de máquina e o cache de dados. Para mais informações sobre o Cloud SQL Enterprise Plus, consulte Introdução às edições do Cloud SQL.
- Mude para o AlloyDB para PostgreSQL. Se você mudar, poderá ter compatibilidade total com o PostgreSQL, melhor processamento transacional e cargas de trabalho de análise transacional rápidas com suporte no banco de dados de processamento. Você também recebe uma recomendação para novos índices usando o recurso de consultor de índice.
Para mais informações sobre como aumentar o desempenho da sua infraestrutura de banco de dados do Cloud SQL para PostgreSQL, consulte a documentação de melhoria de desempenho do Cloud SQL para PostgreSQL.
Ao 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 de banco de dados do AlloyDB para PostgreSQL:
- Use o mecanismo de colunas do AlloyDB para PostgreSQL para acelerar suas consultas analíticas.
- Use o index advisor no AlloyDB para PostgreSQL. O consultor de índice rastreia as consultas executadas regularmente no seu banco de dados e as analisa periodicamente para recomendar novos índices que podem aumentar a performance delas.
- Melhorar a performance da consulta usando os insights de consulta no AlloyDB para PostgreSQL.
Aumentar os recursos de observabilidade do banco de dados
Diagnosticar e solucionar problemas em aplicativos que se conectam ao banco de dados instâncias pode ser desafiador e demorado. Por isso, um sistema centralizado local em que todos os membros da equipe podem ver o que está acontecendo no banco de dados e na instância é essencial. É possível monitorar instâncias do Cloud SQL das seguintes maneiras:
O Cloud SQL usa agentes personalizados de memória integrada para coletar a telemetria de consultas.
- Use o Cloud Monitoring para coletar medições do seu serviço e dos Google Cloud recursos que você usa. O Cloud Monitoring inclui painéis predefinidos para vários Google Cloud produtos, como um painel de monitoramento do Cloud SQL.
- É possível criar painéis personalizados para monitorar métrica. e configurar políticas de alertas para receber notificações oportunas.
- Também é possível usar soluções de monitoramento de terceiros integradas ao Google Cloud, como o Datadog e o Splunk.
O Cloud Logging coleta dados de registro de componentes comuns do aplicativo.
O Cloud Trace coleta dados de latência e planos de consulta executados em aplicativos para ajudar a rastrear como as solicitações se propagam pelo aplicativo.
Central de banco de dados: fornece uma visão geral da frota do banco de dados centralizado e assistido por IA. É possível monitorar a integridade dos bancos de dados, a configuração de disponibilidade, a proteção de dados, a segurança e a compliance do setor.
Para mais informações sobre como aumentar a observabilidade da sua infraestrutura de banco de dados, consulte as seguintes seções da documentação:
- Monitorar instâncias do Cloud SQL para PostgreSQL
- Monitorar instâncias com o AlloyDB para PostgreSQL
Práticas recomendadas e diretrizes operacionais gerais do Cloud SQL e do AlloyDB para PostgreSQL
Aplique as práticas recomendadas do Cloud SQL para configurar e ajustar o banco de dados.
Essas são algumas recomendações gerais importantes do Cloud SQL:
- Se você tiver instâncias grandes, recomendamos dividi-las em instâncias menores, quando for possível.
- Configure o armazenamento para acomodar a manutenção crítica do banco de dados. Tenha no mínimo 20% de espaço disponível para acomodar quaisquer operações importantes de manutenção de banco de dados que o Cloud SQL possa executar.
- Ter muitas tabelas de banco de dados pode afetar o tempo de upgrade do banco de dados. O ideal é ter menos de 10 mil tabelas por instância.
- Escolha o tamanho apropriado para as instâncias para contabilizar a retenção de log de transações (binário), especialmente para instâncias com alta atividade de gravação.
Para conseguir lidar com eficiência com qualquer problema de desempenho do banco de dados que você possa encontrar, use as seguintes diretrizes até que o problema seja resolvido:
Ampliar a infraestrutura: aumente os recursos, como a capacidade de processamento do disco, a vCPU e e RAM. Dependendo da urgência, da disponibilidade e da experiência da sua equipe, o escalonamento vertical da instância pode resolver a maioria dos problemas de desempenho. Mais tarde, você pode investigar a causa raiz do problema em um ambiente de teste e considerar opções para eliminá-lo.
Executar e programar operações de manutenção do banco de dados: desfragmentação de índices, atualizações de estatísticas, análise de vácuo e reindexação de tabelas extremamente atualizadas. Verifique se e quando essas operações de manutenção foram realizadas pela última vez, especialmente nos objetos afetados (tabelas e índices). Descubra se houve uma alteração das atividades normais do banco de dados. Por exemplo, adicionar recentemente uma nova coluna ou ter muitas atualizações em uma tabela.
Executar o ajuste e a otimização do banco de dados: as tabelas no banco de dados estão bem estruturadas? As colunas têm os tipos de dados corretos? Esse é o modelo de dados ideal para o tipo de carga de trabalho? Investigue as consultas lentas e os planos de execução. Eles estão usando os índices disponíveis? Verifique se há varreduras de índice, bloqueios e esperas em outros recursos. Considere adicionar índices para oferecer suporte às consultas importantes. Elimine índices não importantes e chaves externas. Considere reescrever consultas e junções complexas. O tempo que leva para resolver o problema depende da experiência e da disponibilidade da equipe e pode variar de horas a dias.
Fazer o escalonamento horizontal das leituras considere ter réplicas de leitura. Quando o dimensionamento vertical não for suficiente para suas necessidades e as medidas de ajuste e otimização do banco de dados não estiverem ajudando, considere o dimensionamento horizontal. Rotear consultas de leitura dos aplicativos para uma réplica de leitura melhora o desempenho geral da carga de trabalho do banco de dados. No entanto, pode ser necessário mais esforço para que os aplicativos se conectem à réplica de leitura.
Rearquitetura do banco de dados: considere particionar e indexar o banco de dados. Essa operação requer significativamente mais esforço do que o ajuste e a otimização do banco de dados e pode envolver a migração de dados, mas pode ser uma solução de longo prazo. Às vezes, um projeto ruim do modelo de dados pode levar a problemas de desempenho, o que pode ser parcialmente compensado pelo escalonamento vertical. No entanto, um modelo de dados adequado é uma solução de longo prazo. Particione as tabelas. Se possível, arquive dados desnecessário. Normalize a estrutura do banco de dados, mas lembre-se: desnormalizar também pode melhorar o desempenho.
Fragmentação do banco de dados: escalone horizontalmente as gravações fragmentando o banco de dados. A fragmentação é uma operação complicada e envolve a rearquitetura do banco de dados e aplicativos de uma forma específica e a execução da migração de dados. Você deve dividir os de banco de dados em várias instâncias menores usando uma regra específica de particionamento. Os critérios podem ser baseados no cliente ou no assunto. Essa opção permite escalonar horizontalmente as gravações e as leituras. No entanto, isso aumenta a complexidade dos bancos de dados e cargas de trabalho. Isso também pode levar a fragmentos desequilibrados, chamados pontos de acesso, que superariam o benefício da fragmentação.
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
é possível usar um balanceador de carga, como o HAProxy, para gerenciar o tráfego para as
réplicas. No entanto, evite muitas réplicas, porque isso dificulta a operação
VACUUM
. Para mais informações sobre o uso do HAProxy, consulte o site oficial HAProxy. - Otimize a operação
VACUUM
aumentando a memória do sistema e o parâmetromaintenance_work_mem
. Aumentar a memória do sistema significa que mais tuplas podem ser agrupadas em cada iteração. - Como índices maiores consomem um tempo significativo para a verificação de índices, defina o parâmetro
INDEX_CLEANUP
comoOFF
para limpar rapidamente e congelar os dados da tabela. - Ao usar o AlloyDB para PostgreSQL, use o painel "Insights do sistema" e os registros de auditoria do AlloyDB para PostgreSQL. O painel "Insights do sistema" do AlloyDB para PostgreSQL mostra métricas dos recursos que você usa e permite monitorá-los. Para mais detalhes, consulte as diretrizes do tópico Monitorar instâncias na documentação do AlloyDB para PostgreSQL.
Para saber mais, acesse os recursos a seguir:
- Seção de práticas recomendadas gerais e Diretrizes operacionais do Cloud SQL para PostgreSQL
- Sobre a manutenção e Visão geral do AlloyDB para PostgreSQL
A seguir
- Leia sobre outras jornadas de migração da AWS para o Google Cloud .
- Saiba como comparar os serviços da AWS e do Azure com o Google Cloud.
- Saiba quando buscar ajuda para suas migrações.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Alex Cârciu | Arquiteto de soluções
- Marco Ferrari | Arquiteto de soluções do Cloud
Outro colaborador: Paul de Somdyuti | Especialista em gerenciamento de dados