Práticas recomendadas para migração contínua para o Banco de Dados do Azure para PostgreSQL

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

Este artigo explica as armadilhas comuns encontradas e as práticas recomendadas para garantir uma migração suave e bem-sucedida para o Banco de Dados do Azure para PostgreSQL.

Validação pré-migração

Como primeira etapa da migração, execute a validação de pré-migração antes de executar uma migração. Você pode usar as opções Validar, Validar e Migrar na página Configuração da migração. A validação pré-migração conduz verificações completas em relação a um conjunto de regras predefinidas. O objetivo é identificar potenciais problemas e fornecer informações acionáveis para ações corretivas. Continue executando a validação de pré-migração até que ela resulte em um estado bem-sucedido . Para saber mais, consulte Validações pré-migração.

Configuração do Servidor Flexível de Destino

Durante a cópia de base inicial dos dados, várias instruções de inserção são executadas no destino, o que gera logs write-ahead (WALs). Até que essas WALs sejam arquivadas, os logs consomem armazenamento no destino e o armazenamento exigido pelo banco de dados.

Para calcular o número, entre na instância de origem e execute este comando para todos os bancos de dados a serem migrados:

SELECT pg_size_pretty( pg_database_size('dbname') );

Recomendamos que você aloque armazenamento suficiente no servidor flexível, equivalente a 1,25 vezes ou 25% mais armazenamento do que o que está sendo usado pela saída para o comando anterior. Você também pode usar o crescimento automático de armazenamento.

O início rápido para criar um Banco de Dados do Azure para PostgreSQL - instância do Servidor Flexível usando o portal é um excelente lugar para começar. Para obter mais informações sobre cada configuração de servidor, consulte Opções de computação e armazenamento no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Cronograma de migração

Cada migração tem uma vida útil máxima de sete dias (168 horas) após o seu início, e expira após sete dias. Você pode concluir a migração e a substituição do aplicativo após a validação de dados e todas as verificações são concluídas para evitar que a migração atinja o tempo limite. Nas migrações online, após a conclusão da cópia base inicial, a janela de transição dura três dias (72 horas) antes do tempo limite. Em migrações offline, os aplicativos devem parar de gravar no banco de dados para evitar a perda de dados. Da mesma forma, para a migração online, mantenha o tráfego baixo durante toda a migração.

A maioria dos servidores que não são de produção (dev, UAT, test e staging) são migrados usando migrações offline. Como esses servidores têm menos dados do que os servidores de produção, a migração é rápida. Para a migração do servidor de produção, você precisa saber o tempo necessário para concluir a migração para planejá-la com antecedência.

O tempo necessário para que uma migração seja concluída depende de vários fatores. Inclui o número de bancos de dados, tamanho, número de tabelas dentro de cada banco de dados, número de índices e distribuição de dados entre tabelas. Também depende da SKU do servidor de destino e das IOPS disponíveis na instância de origem e no servidor de destino. Com tantos fatores que podem afetar o tempo de migração, é difícil estimar o tempo total para uma migração ser concluída. A melhor abordagem é executar uma migração de teste com sua carga de trabalho.

As seguintes fases são consideradas para calcular o tempo total de inatividade para executar a migração do servidor de produção:

• Migração do PITR: A melhor maneira de obter uma boa estimativa do tempo necessário para migrar seu servidor de banco de dados de produção é fazer uma restauração point-in-time (PITR) do seu servidor de produção e executar a migração offline nesse servidor recém-restaurado.

• Migração de buffer: depois de concluir a etapa anterior, você pode planejar a migração de produção real durante um período de tempo em que o tráfego do aplicativo estiver baixo. Esta migração pode ser planeada no mesmo dia ou, provavelmente, a uma semana de distância. Nesse momento, o tamanho do servidor de origem pode ter aumentado. Atualize o tempo estimado de migração para o servidor de produção com base na quantidade desse aumento. Se o aumento for significativo, considere fazer outro teste usando o servidor PITR. Mas para a maioria dos servidores, o aumento de tamanho não deve ser significativo o suficiente.

• Validação de dados: após a conclusão da migração para o servidor de produção, você precisa verificar se os dados no servidor flexível são uma cópia exata da instância de origem. Você pode usar ferramentas de código aberto ou de terceiros ou pode fazer a validação manualmente. Prepare as etapas de validação que você deseja fazer antes da migração real. A validação pode incluir:

  • Correspondência de contagem de linhas para todas as tabelas envolvidas na migração.

  • A correspondência conta para todos os objetos de banco de dados (tabelas, sequências, extensões, procedimentos e índices).

  • Comparação de IDs máximos ou mínimos de colunas relacionadas ao aplicativo principal.

    Nota

    O tamanho comparativo dos bancos de dados não é a métrica certa para validação. A instância de origem pode ter inchaços ou tuplas mortas, o que pode aumentar o tamanho da instância de origem. É normal haver diferenças de tamanho entre instâncias de origem e servidores de destino. Um problema nas três etapas de validação anteriores indica um problema com a migração.

• Migração de configurações do servidor: quaisquer parâmetros de servidor personalizados, regras de firewall (se aplicável), tags e alertas devem ser copiados manualmente da instância de origem para o destino.

• Alterando cadeias de conexão: O aplicativo deve alterar suas cadeias de conexão para um servidor flexível após a validação bem-sucedida. Essa atividade é coordenada com a equipe do aplicativo para alterar todas as referências de cadeias de conexão que apontam para a instância de origem. No servidor flexível, o parâmetro user pode ser usado no formato user=username na cadeia de conexão.

Por exemplo: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Embora uma migração geralmente seja executada sem problemas, é uma boa prática planejar contingências se for necessário mais tempo para depuração ou se uma migração precisar ser reiniciada.

Avaliação comparativa da velocidade de migração

A tabela a seguir mostra o tempo necessário para executar migrações para bancos de dados de vários tamanhos usando o serviço de migração. A migração foi realizada utilizando um servidor flexível com o Standard_D4ds_v4 SKU (4 núcleos, 16 GB de memória).

Os números anteriores fornecem uma aproximação do tempo necessário para concluir a migração. É altamente recomendável executar uma migração de teste com sua carga de trabalho para obter um valor preciso para migrar seu servidor.

Melhorar a velocidade de migração: migração paralela de tabelas

Recomendamos um SKU poderoso para o destino porque o serviço de migração PostgreSQL é executado sem um contêiner no servidor flexível. Um poderoso SKU permite que mais tabelas sejam migradas em paralelo. Você pode dimensionar a SKU de volta para sua configuração preferida após a migração. Esta seção contém etapas para melhorar a velocidade de migração se a distribuição de dados entre as tabelas precisar ser mais equilibrada ou se uma SKU mais poderosa não afetar significativamente a velocidade de migração.

Se a distribuição de dados na fonte for altamente enviesada, com a maioria dos dados presentes em uma tabela, a computação alocada para migração precisará ser totalmente utilizada, o que cria um gargalo. Assim, divida tabelas grandes em partes menores, que são migradas em paralelo. Este recurso aplica-se a tabelas com mais de 1.000.000 (1 m) de tuplas. A divisão da tabela em partes menores é possível se uma das seguintes condições for satisfeita:

• A tabela deve ter uma coluna com uma chave primária simples (não composta) ou um índice exclusivo do tipo int ou significant int.

  Nota

  No caso da primeira ou segunda abordagens, você deve avaliar cuidadosamente as implicações da adição de uma coluna de índice exclusiva ao esquema de origem. Somente após a confirmação de que a adição de uma coluna de índice exclusiva não afetará o aplicativo é que você deve prosseguir com as alterações.

• Se a tabela não tiver uma chave primária simples ou um índice exclusivo do tipo int , ou significant int se tiver uma coluna que atenda aos critérios de tipo de dados, a coluna poderá ser convertida em um índice exclusivo usando o comando a seguir. Este comando não requer um bloqueio na tabela.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• Se a tabela não tiver uma chave primária ou um simple int/big int índice exclusivo ou qualquer coluna que atenda aos critérios de tipo de dados, você poderá adicionar essa coluna usando ALTER e soltá-la após a migração. A execução do ALTER comando requer um bloqueio na mesa.

      alter table <table name> add column <column name> big serial unique;
  

Se qualquer uma das condições anteriores for satisfeita, a tabela será migrada em várias partições em paralelo, o que deve fornecer um aumento na velocidade de migração.

Como funciona

• O serviço de migração procura o valor inteiro máximo e mínimo da chave primária/índice exclusivo da tabela que deve ser dividido e migrado em paralelo.
• Se a diferença entre o valor mínimo e máximo for superior a 1.000.000 (1 m), a tabela é dividida em várias partes e cada parte é migrada em paralelo.

Em resumo, o serviço de migração PostgreSQL migra uma tabela em threads paralelos e reduz o tempo de migração se:

• A tabela tem uma coluna com uma chave primária simples ou um índice exclusivo do tipo int ou int significativo.
• A tabela tem pelo menos 1.000.000 (1 m) linhas para que a diferença entre o valor mínimo e máximo da chave primária seja superior a 1.000.000 (1 m).
• O SKU usado tem núcleos ociosos, que podem ser usados para migrar a tabela em paralelo.

Inchaço de vácuo no banco de dados PostgreSQL

Com o tempo, à medida que os dados são adicionados, atualizados e excluídos, o PostgreSQL pode acumular linhas mortas e espaço de armazenamento desperdiçado. Esse inchaço pode levar ao aumento dos requisitos de armazenamento e à diminuição do desempenho da consulta. A aspiração é uma tarefa de manutenção crucial que ajuda a recuperar esse espaço desperdiçado e garante que o banco de dados opere de forma eficiente. A aspiração resolve problemas como linhas mortas e inchaço da mesa para garantir o uso eficiente do armazenamento. Ele também ajuda a garantir uma migração mais rápida porque o tempo de migração é uma função do tamanho do banco de dados.

O PostgreSQL fornece o comando para recuperar o VACUUM armazenamento ocupado por linhas mortas. A ANALYZE opção também reúne estatísticas para otimizar ainda mais o planejamento de consultas. Para tabelas com atividade de gravação pesada, o VACUUM processo pode ser mais agressivo usando VACUUM FULLo , mas requer mais tempo para ser executado.

• Vácuo padrão

  VACUUM your_table;
  

• Vácuo com análise

  VACUUM ANALYZE your_table;
  

• Vácuo agressivo para tabelas de escrita pesadas

  VACUUM FULL your_table;
  

Neste exemplo, substitua your_table pelo nome real da tabela. O VACUUM comando sem FULL recupera espaço de forma eficiente, enquanto VACUUM ANALYZE otimiza o planejamento de consultas. A VACUUM FULL opção deve ser usada criteriosamente devido ao seu impacto mais pesado no desempenho.

Alguns bancos de dados armazenam objetos grandes, como imagens ou documentos, que podem contribuir para o inchaço do banco de dados ao longo do tempo. O VACUUMLO comando é projetado para objetos grandes em PostgreSQL.

• Aspirar objetos grandes

  VACUUMLO;
  

A incorporação regular dessas estratégias de vácuo garante um banco de dados PostgreSQL bem mantido.

Consideração especial

Há condições especiais que normalmente se referem a circunstâncias, configurações ou pré-requisitos exclusivos que você precisa estar ciente antes de prosseguir com um tutorial ou módulo. Essas condições podem incluir versões específicas de software, requisitos de hardware ou outras ferramentas necessárias para a conclusão bem-sucedida do conteúdo de aprendizagem.

Migração online

A migração on-line faz uso do pgcopydb follow, e algumas das restrições lógicas de decodificação se aplicam. Também recomendamos que você tenha uma chave primária em todas as tabelas de um banco de dados que está passando pela migração online. Se uma chave primária estiver ausente, a deficiência resultará em apenas insert operações sendo refletidas durante a migração, excluindo atualizações ou exclusões. Adicione uma chave primária temporária às tabelas relevantes antes de prosseguir com a migração online.

Uma alternativa é usar o ALTER TABLE comando onde a ação é REPLICA IDENTIY com a FULL opção. A FULL opção registra os valores antigos de todas as colunas na linha para que, mesmo na ausência de uma chave primária, todas as operações CRUD sejam refletidas no destino durante a migração online. Se nenhuma dessas opções funcionar, execute uma migração offline como alternativa.

Base de dados com extensão postgres_fdw

O módulo postgres_fdw fornece o postgres_fdw wrapper de dados estrangeiros, que pode ser usado para acessar dados armazenados em servidores PostgreSQL externos. Se o banco de dados usar essa extensão, as etapas a seguir deverão ser executadas para garantir uma migração bem-sucedida.

1. Remova temporariamente (desvincule) o wrapper de dados estrangeiros na instância de origem.
2. Execute a migração de dados do restante usando o serviço de migração.
3. Restaure as funções de wrapper de dados externos, o usuário e os links para o destino após a migração.

Base de dados com extensão postGIS

A extensão postGIS tem mudanças de quebra / problemas compactos entre diferentes versões. Se você migrar para um servidor flexível, o aplicativo deve ser verificado em relação à versão mais recente do postGIS para garantir que o aplicativo não seja afetado ou que as alterações necessárias devam ser feitas. As notícias e notas de lançamento do postGIS são um bom ponto de partida para entender as mudanças mais recentes em todas as versões.

Limpeza da conexão do banco de dados

Às vezes, você pode encontrar esse erro ao iniciar uma migração:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

Nesse cenário, você pode conceder a migration user permissão para fechar todas as conexões ativas com o banco de dados ou fechar as conexões manualmente antes de tentar novamente a migração.

Conteúdos relacionados

• Serviço de migração
• Problemas e limitações conhecidos