Compartilhar via

Boas práticas para migração integrada para o Banco de Dados do Azure para PostgreSQL

  • Artigo

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

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

Validações pré-migração

Como uma primeira etapa da migração, execute a validação pré-migração antes de executar uma migração. Você pode usar as opções Validar e Validar e Migrar na página Instalação da migração. A validação pré-migração realiza verificações minuciosas seguindo um conjunto de regras predefinido. O objetivo é identificar possíveis problemas e fornecer insights acionáveis para ações corretivas. Continue executando a validação pré-migração até que resulte em um estado Bem-sucedida. Para saber mais, confira Validações pré-migração.

Configuração do Servidor Flexível de Destino

Durante a cópia básica inicial dos dados, várias instruções de inserção são executadas no destino, o que gera logs de gravação antecipada (WALs). Até que esses WALs sejam arquivados, os logs consomem armazenamento no destino e também o armazenamento requerido 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% a mais de armazenamento do que o que está sendo usado de acordo com a saída do comando anterior. Você também pode usar Crescimento Automático de Armazenamento.

Importante

O tamanho do armazenamento não pode ser reduzido na configuração manual nem no Autocrescimento do Armazenamento. Cada etapa do espectro de configuração do armazenamento dobra de tamanho, portanto, é prudente estimar antecipadamente o armazenamento necessário.

O início rápido para criar uma instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível usando o portal é um excelente ponto de partida. 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.

Importante

Depois que o servidor flexível for criado, certifique-se de alterar o parâmetro do servidor password_encryption no seu servidor flexível de SCRAM-SHA-256 para MD5 antes de iniciar a migração. Isso é essencial para que as credenciais existentes no servidor único funcionem no seu servidor flexível

Linha do tempo da migração

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

A maioria dos servidores não-produtivos (desenvolvimento, UAT, teste e preparo) 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. No caso da migração do servidor de produção, você precisa saber quanto tempo será gasto na execução da migração para planejá-la com antecedência.

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

As fases a seguir são consideradas para calcular o tempo total de inatividade para realizar 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 o servidor de banco de dados de produção é fazer uma restauração pontual (PITR) do servidor de produção e executar a migração offline nesse servidor recém-restaurado.

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

  • 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 realizar antes da migração real. A validação pode incluir:

    • A contagem de linhas corresponde a todas as tabelas envolvidas na migração.

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

    • Comparar IDs máximas ou mínimas de colunas-chave relacionadas a aplicativos.

      Observação

      O tamanho comparativo dos bancos de dados não é a métrica correta para a 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 as instâncias de origem e os servidores de destino. Um problema nas três etapas anteriores de validação indica um problema com a migração.

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

  • Alteração das 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 que sejam alteradas todas as referências das cadeias de conexão que apontam para a instância original. No servidor flexível, os parâmetros de usuário pode ser usados 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 a migração precisar ser reiniciada.

Parâmetro de comparação de velocidade de migração

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

Tamanho do banco de dados Tempo aproximado necessário (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1.000 GB 07:00

Os números anteriores fornecem uma estimativa aproximada do tempo necessário para concluir a migração. Recomendamos fortemente executar um teste de migração com sua carga de trabalho de modo a obter um valor preciso para migrar seu servidor.

Importante

Embora o SKU com capacidade de intermitência não seja uma limitação, é recomendável escolher um SKU maior para seu servidor flexível para realizar migrações mais rápidas. O Banco de Dados do Azure para PostgreSQL - Servidor Flexível dá suporte para a escala de IOPS e computação com tempo de inatividade quase zero, de modo que a SKU pode ser atualizada com tempo de inatividade mínimo. Você sempre pode alterar o SKU de acordo com as necessidades do aplicativo após a migração.

Aumente a velocidade de migração: Migração paralela de tabelas

Recomendamos uma SKU avançada para o destino porque o serviço de migração do PostgreSQL é executado a partir de um contêiner no servidor flexível. Um SKU poderoso permite que mais tabelas sejam migradas em paralelo. Você pode dimensionar o 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 potente não afetar significativamente a velocidade da migração.

Se a distribuição de dados na origem for altamente distorcida, com a maioria dos dados presentes em uma tabela, a computação alocada para a migração precisará ser totalmente utilizada, o que criará um gargalo. Portanto, divida as tabelas grandes em partes menores, que serão migradas em paralelo. Esse recurso se aplica 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 condições a seguir for atendida:

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

    Observação

    No caso da primeira ou da segunda abordagem, você deve avaliar cuidadosamente as implicações de adicionar uma coluna de índice exclusivo ao esquema de origem. Somente após a confirmação de que a adição de uma coluna de índice exclusivo 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, mas tiver uma coluna que atenda aos critérios de tipo de dados, a coluna poderá ser convertida em um índice exclusivo usando o seguinte comando. Esse 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 simple int/big int ou um í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 comando ALTER requer um bloqueio na tabela.

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

Se qualquer uma das condições anteriores for atendida, a tabela será migrada em várias partições em paralelo, o que deve aumentar a velocidade da migração.

Como ele 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 o máximo for superior a 1.000.000 (1 m), a tabela será dividida em várias partes e cada parte será migrada em paralelo.

Em resumo, o serviço de migração do PostgreSQL irá migrar uma tabela em threads paralelos e reduzir o tempo de migração se:

  • a tabela tiver 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) de linhas, de modo que a diferença entre o valor mínimo e máximo da chave primária seja maior que 1.000.000 (1 m).
  • O SKU usado tem núcleos ociosos que podem ser aproveitados para migrar a tabela em paralelo.

Sobrecarga de limpeza no banco de dados PostgreSQL

Com o tempo, à medida que os dados são adicionados, atualizados e excluídos, o PostgreSQL talvez acumule linhas inativas e espaço de armazenamento desperdiçado. Essa sobrecarga pode levar ao aumento dos requisitos de armazenamento e à diminuição do desempenho da consulta. A limpeza é uma tarefa de manutenção crucial que ajuda a recuperar esse espaço desperdiçado e garante que o banco de dados opere com eficiência. O processo de vácuo resolve problemas como linhas mortas e inchaço de tabelas para garantir o uso eficiente do armazenamento. Ele também ajuda a garantir uma migração mais rápida, pois o tempo de migração é uma função do tamanho do banco de dados.

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

  • Vácuo Standard

    VACUUM your_table;

  • Vácuo com análise

    VACUUM ANALYZE your_table;

  • Vácuo agressivo para tabelas com muita gravação

    VACUUM FULL your_table;

Neste exemplo, substitua your_table pelo nome da tabela real. O comando VACUUM sem FULL recupera o espaço de forma eficiente, enquanto VACUUM ANALYZE otimiza o planejamento da consulta. A opção VACUUM FULL deve ser usada criteriosamente devido ao seu maior impacto 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 comando VACUUMLO foi projetado para objetos grandes no PostgreSQL.

  • Vácuo de objetos grandes

    VACUUMLO;

Incorporar regularmente essas estratégias de limpeza garante um banco de dados PostgreSQL bem gerenciado.

Consideração especial

Há condições especiais que normalmente se referem a circunstâncias, configurações ou pré-requisitos exclusivos dos quais 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 online utiliza pgcopydb follow, e algumas das restrições de decodificação lógica se aplicam. Também recomendamos que você tenha uma chave primária em todas as tabelas de um banco de dados que esteja passando por uma migração online. Se uma chave primária estiver ausente, a deficiência fará com que apenas insert operações sejam 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.

Observação

No caso da migração online de tabelas sem uma chave primária, apenas insert operações são reproduzidas no destino. Isso pode introduzir inconsistência no banco de dados se os registros que forem atualizados ou excluídos na origem não forem refletidos no destino.

Uma alternativa é utilizar o comando ALTER TABLE onde a ação é REPLICA IDENTIY com a opção FULL. A opção FULL 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.

Banco de dados com extensão de postgres_fdw

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

  1. Remova temporariamente (desvincule) o wrapper de dados estrangeiro 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 estrangeiro, usuário e links no destino após a migração.

Banco de dados com extensão postGIS

A extensão postGIS tem problemas de alterações/compactação entre diferentes versões. Se você migrar para um servidor flexível, o aplicativo deverá 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 sejam feitas. As notícias do postGIS e as notas sobre a versão são um bom ponto de partida para entender as alterações interruptivas entre 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 caso, você pode conceder a permissão migration user 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údo relacionado