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, disponíveis na página de configuraçã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. Selecione validações pré-imigração para saber mais.

Configuração do servidor flexível de destino

Durante a cópia básica de dados inicial, várias instruções de inserção são executadas no destino, o que, por sua vez, gera WALs (Logs de Gravação Antecipada). 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 original e execute o comando a seguir para que todos os Bancos de Dados sejam migrados:

SELECT pg_size_pretty( pg_database_size('dbname') );

É aconselhável alocar armazenamento suficiente no Servidor Flexível, equivalente a 1,25 vezes ou 25% mais armazenamento do que o que está sendo usado de acordo com o resultado do comando acima. O crescimento automático de armazenamento também pode ser usado.

Importante

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

O início rápido Criar um Banco de Dados do Azure para PostgreSQL com Servidor Flexível usando o portal é um excelente lugar para começar. As opções de computação e armazenamento no Banco de Dados do Azure para PostgreSQL – Servidor Flexível também fornecem informações detalhadas sobre cada configuração do servidor.

Linha do tempo da migração

Cada migração tem um tempo de vida máximo de sete dias (168 horas) após ter sido iniciada e seu tempo limite será atingido após sete dias. Você pode executar sua migração e substituição de aplicativos assim 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 básica inicial a janela de substituição dura três dias (72 horas) antes de expirar. Nas migrações offline, os aplicativos devem parar de gravar no Banco de Dados para evitar 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 de não produção (desenvolvimento, UAT, testes, 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 é concluída rapidamente. 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. Considerando os muitos fatores que podem afetar o tempo de migração, é difícil estimar o tempo total para a conclusão da migração. A melhor abordagem seria executar um teste de migração com sua carga de trabalho.

Para o cálculo do tempo total de inatividade durante a execução da migração do servidor de produção são levadas em conta as fases a seguir.

  • Migração da 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 do servidor de produção e executar a migração offline nesse servidor recém-restaurado.

  • Migração de buffer – Depois de concluir a etapa acima, você poderá planejar a migração de produção real durante um período em que o tráfego do aplicativo seja 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 significativo o suficiente.

  • Data de validade: após a migração do servidor de produção ter sido concluída, você precisará verificar se os dados no servidor flexível são uma cópia exata da instância original. Os clientes podem usar ferramentas de código aberto/terceiros ou fazer a validação manualmente. Prepare as etapas de validação que você gostaria de fazer antes da migração real. A validação pode incluir:

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

  • Equiparação dos números de todos os objetos do banco de dados (tabelas, sequências, extensões, procedimentos, índices)

  • Comparação entre o máximo ou mínimo de IDs das principais colunas relacionadas a aplicativos

    Observação

    O tamanho dos bancos de dados precisa usar a métrica certa para a validação. A instância original talvez tenha sobrecargas/tuplas inativas, o que poderá aumentar seu tamanho. É totalmente normal haver diferenças de tamanho entre a instância original e os servidores de destino. Se houver algum problema nas três primeiras etapas de validação, isso indica um problema com a migração.

  • Migração das configurações do servidor: quaisquer parâmetros de servidor, regras de firewall (se aplicável), tags e alertas personalizados precisam ser copiados manualmente da instância original 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 uma 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 normalmente a migração seja executada sem problemas, é uma boa prática se planejar para contingências caso seja necessário mais tempo para a depuração ou uma 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 executar migrações para bancos de dados de vários tamanhos usando o serviço de migração. A migração foi executada usando um servidor flexível com o SKU: Standard_D4ds_v4 (4 núcleos, 16 GB de memória, disco de 128 GB e 500 IOPS)

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

Observação

Os números acima fornecem uma aproximação 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

Para executar migrações mais rápidas, escolha um SKU mais alto para o servidor flexível. O Banco de Dados do Azure para PostgreSQL com Servidor Flexível dá suporte ao dimensionamento de IOPS e um tempo de inatividade de computação próximo de zero, de modo que o SKU possa ser atualizado com um tempo de inatividade mínimo. Você sempre pode alterar o SKU de acordo com as necessidades do aplicativo após a migração.

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

Recomendamos um SKU poderoso para o destino devido ao fato de que a ferramenta de migração no Servidor Flexível é executada a partir de um contêiner. 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. Essa seção contém etapas para aumentar a velocidade da migração caso a distribuição de dados entre as tabelas precise ser mais equilibrada e/ou um SKU mais poderoso não afete a velocidade de migração de forma significativa.

Se a distribuição de dados na origem estiver altamente desequilibrada, com a maioria dos dados presentes em apenas uma tabela, a computação alocada para a migração precisará será totalmente utilizada e criará um gargalo. Portanto, dividiremos tabelas grandes em partes menores, que serão migradas em paralelo. Esse recurso se aplica a tabelas com mais de 10.000.000 (10 mi) de tuplas. A divisão da tabela em partes menores é possível se uma das seguintes condições for atendida.

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

    Observação

    No caso das abordagens n.º 2 ou n.º 3, o usuário precisa avaliar cuidadosamente as implicações de adicionar uma coluna de índice exclusivo ao esquema original. Somente após a confirmação de que a adição de uma coluna de índice exclusiva não afetará o aplicativo, o usuário deve prosseguir com as alterações.

  2. Se a tabela não tiver uma chave primária simples ou um índice exclusivo do tipo int ou int significativo, mas tiver uma coluna que cumpra os critérios de tipo de dados, a coluna poderá ser convertida em um índice exclusivo usando o comando abaixo. Esse comando não requer um bloqueio na tabela.

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

  3. Se a tabela não tiver uma chave primária int/big int simples ou um índice exclusivo ou qualquer coluna que atenda aos critérios de tipo de dados, você poderá adicionar essa coluna usando ALTER e removê-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 acima for atendida, a tabela será migrada em várias partições em paralelo, o que deve proporcionar um aumento significativo na velocidade de migração.

Como ele funciona

  • A ferramenta de migração busca o valor inteiro máximo e mínimo da chave primária/índice exclusivo da tabela que deve ser dividida e migrada em paralelo.
  • Se a diferença entre o valor mínimo e máximo for superior a 10.000.000 (10 mi), a tabela será dividida em diversas partes e cada parte será migrada separadamente, 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 10000000 (10 m) linhas, de modo que a diferença entre o valor mínimo e máximo da chave primária seja superior a 10000000 (10 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. A limpeza resolve problemas como linhas mortas e sobrecarga de tabela, garantindo o uso eficiente do armazenamento. Mais importante ainda, ajuda a garantir uma migração mais rápida, pois o tempo de migração depende 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 coleta estatísticas, otimizando ainda mais o planejamento de consultas. Para tabelas com intensa atividade de gravação, o processo VACUUM pode ser mais agressivo se usar VACUUM FULL, mas irá requerer mais tempo para ser executado.

  • Limpeza padrão
VACUUM your_table;
  • Limpeza com análise
VACUUM ANALYZE your_table;
  • Limpeza agressiva para tabelas de gravação pesadas
VACUUM FULL your_table;

Neste exemplo, substitua your_table pelo nome da tabela real. O comando VACUUM sem FULL recupera o espaço com eficiência, enquanto VACUUM ANALYZE otimiza o planejamento de consultas. 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 a sobrecarga do banco de dados ao longo do tempo. O comando VACUUMLO foi projetado para objetos grandes no PostgreSQL.

  • Limpeza de objetos grandes
VACUUMLO;

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

Consideração especial

Existem condições especiais que costumam se referir a circunstâncias, configurações ou pré-requisitos únicos dos quais um estudante precisa estar ciente antes de prosseguir em um tutorial ou módulo. Essas condições podem incluir versões de software específicas, requisitos de hardware ou ferramentas adicionais necessárias para a conclusão bem-sucedida do conteúdo do aprendizado.

Migração online

A migração online faz uso do pgcopydb follow e algumas das restrições de decodificação lógica se aplicam. Além disso, é recomendável ter uma chave primária em todas as tabelas de um banco de dados em migração online. Se a chave primária estiver ausente, a deficiência poderá resultar em apenas operações de inserção 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 é 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 da 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 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 encapsulador de dados externos na instância original.
  2. Execute a migração dos dados restantes usando a ferramenta de migração.
  3. Restaure as funções, o usuário e os links do encapsulador de dados externos no destino após migração.

Banco de dados com extensão postGIS

A extensão PostGIS tem alterações interruptivas/problemas de compactação entre versões diferentes. Se você migrar para um servidor flexível, o aplicativo deverá ser verificado de acordo com a versão mais recente da extensão PostGIS para garantir que o aplicativo não seja afetado ou que alterações necessárias precisam ser 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ê poderá se deparar com 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 ao migration user a permissão para fechar todas as conexões ativas com o banco de dados ou fechar as conexões manualmente antes de tentar a migração novamente.

Conteúdo relacionado