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 e Validar e Migrar na página de 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 . Selecione validações de pré-migração para saber mais.
Configuração flexível do servidor 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 WALs (Write Ahead Logs). 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') );
É 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 pela saída para o 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 ou no crescimento automático do armazenamento. Cada etapa do espectro de configuração de armazenamento dobra de tamanho, portanto, estimar o armazenamento necessário com antecedência é prudente.
O início rápido para criar um banco de dados do Azure para servidor flexível PostgreSQL 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 de servidor.
Cronograma de migração
Cada migração tem um tempo de vida máximo de sete dias (168 horas) uma vez iniciada e expirará após sete dias. Você pode concluir a migração e a substituição do aplicativo assim que a validação dos dados e todas as verificações estiverem 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 não-prod (dev, UAT, test, 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 é concluída rapidamente. 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. Dados 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 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 executar a migração do servidor de produção.
Migração de PITR - A melhor maneira de obter uma boa estimativa sobre o tempo necessário para migrar seu servidor de banco de dados de produção seria fazer uma restauração point-in-time do seu servidor de produção e executar a migração offline neste servidor recém-restaurado.
Migração de buffer - Depois de concluir a etapa acima, 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, você pode considerar 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 - Quando a migração for concluída para o servidor de produção, você precisará verificar se os dados no servidor flexível são uma cópia exata da instância de origem. Os clientes podem usar ferramentas de código aberto/de terceiros ou podem 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:
Correspondência de contagem de linhas para todas as tabelas envolvidas na migração.
Contagens correspondentes para todos os objetos de banco de dados (tabelas, sequências, extensões, procedimentos, índices)
Comparando IDs máximos ou mínimos de colunas principais relacionadas ao aplicativo
Nota
O tamanho dos bancos de dados precisa ser a métrica certa para validação. A instância de origem pode ter inchaços/tuplas mortas, o que pode aumentar o tamanho da instância de origem. É completamente normal haver diferenças de tamanho entre instâncias de origem e servidores de destino. Se houver um problema nas três primeiras etapas de validação, isso indica um problema com a migração.
Migração de configurações do servidor - Todos os parâmetros personalizados do servidor, 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 usando um servidor flexível com o SKU – Standard_D4ds_v4(4 núcleos, 16GB de memória, 128GB de disco e 500 iops)
| Tamanho da base de dados | Tempo aproximado gasto (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 |
Nota
Os números acima 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.
Importante
Escolha uma SKU mais alta para seu servidor flexível para executar migrações mais rápidas. O Servidor Flexível do Banco de Dados do Azure para PostgreSQL oferece suporte a tempo de inatividade quase nulo Compute & IOPS scaling para que o SKU possa ser atualizado com o mínimo de tempo de inatividade. Você sempre pode alterar a SKU para corresponder às necessidades do aplicativo pós-migração.
Melhorar a velocidade de migração - migração paralela de tabelas
Um poderoso SKU é recomendado para o destino, pois o serviço de migração do 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 caso a distribuição de dados entre as tabelas precise ser mais equilibrada e/ou uma SKU mais poderosa não afete 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 e criará um gargalo. Assim, dividimos tabelas grandes em pedaços menores, que são migrados em paralelo. Esta funcionalidade aplica-se a mesas com mais de 10000000 (10 m) 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 int significativo.
Nota
No caso das abordagens #2 ou #3, o usuário 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 o usuário 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 int significativo, mas tiver uma coluna que atenda aos critérios de tipo de dados, a coluna poderá ser convertida em um índice exclusivo usando o comando abaixo. 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 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 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 acima for satisfeita, a tabela é migrada em várias partições em paralelo, o que deve proporcionar um aumento acentuado na velocidade de migração.
Como funciona
- O serviço de migração procura o valor inteiro máximo e mínimo do índice Chave primária/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 10000000 (10 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 10000000 (10 m) linhas de modo que a diferença entre o valor mínimo e máximo da chave primária é superior a 10000000 (10 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 fileiras mortas e inchaço da mesa, garantindo o uso eficiente do armazenamento. Mais importante ainda, ajuda a garantir uma migração mais rápida, uma vez que o tempo de migração necessário é uma função do tamanho da base de dados.
O PostgreSQL fornece o comando VACUUM para recuperar o armazenamento ocupado por linhas mortas. A ANALYZE opção também reúne estatísticas, otimizando 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 os alunos precisam estar cientes antes de prosseguir com um tutorial ou módulo. Essas condições podem incluir versões específicas de software, requisitos de hardware ou ferramentas adicionais 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 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 pode resultar em apenas operações de inserção 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 wrapper de dados estrangeiros postgres_fdw, 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.
- Remova temporariamente (desvincule) o wrapper de dados estrangeiros na instância de origem.
- Execute a migração de dados de repouso usando o serviço de migração.
- Restaure as funções de wrapper de dados externos, usuário e 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 caso, 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.