Partilhar via

Práticas recomendadas para pg_dump e pg_restore para o Banco de Dados do Azure para PostgreSQL

Este artigo analisa as opções e as práticas recomendadas para acelerar o pg_dump e o pg_restore. Ele também explica as melhores configurações de servidor para realizar pg_restore.

Práticas recomendadas para pg_dump

Você pode usar o utilitário pg_dump para extrair um banco de dados de servidor flexível do Banco de Dados do Azure para PostgreSQL em um arquivo de script ou arquivo morto. Algumas das opções de linha de comando que você pode usar para reduzir o tempo geral de despejo usando pg_dump estão listadas nas seções a seguir.

Formato de diretório(-Fd)

Esta opção gera um arquivo em formato de diretório que você pode inserir no pg_restore. Por padrão, a saída é compactada.

Trabalhos paralelos(-j)

Com pg_dump, você pode executar trabalhos de despejo simultaneamente usando a opção de trabalhos paralelos. Essa opção reduz o tempo total de despejo, mas aumenta a carga no servidor de banco de dados. Recomendamos que você chegue a um valor de trabalho paralelo depois de monitorar de perto as métricas do servidor de origem, como CPU, memória e uso de IOPS (operações de entrada/saída por segundo).

Quando você está definindo um valor para a opção de trabalhos paralelos, pg_dump requer o seguinte:

  • O número de conexões deve ser igual ao número de trabalhos paralelos +1, portanto, certifique-se de definir o max_connections valor de acordo.
  • O número de trabalhos paralelos deve ser menor ou igual ao número de vCPUs alocados para o servidor de banco de dados.

Compressão(-Z0)

Esta opção especifica o nível de compressão a ser usado. Zero significa ausência de compressão. A compressão zero durante o processo de pg_dump pode ajudar com ganhos de desempenho.

Inchaço da mesa e aspiração

Antes de iniciar o processo de pg_dump, considere se a aspiração de mesa é necessária. O inchaço nas mesas aumenta significativamente pg_dump vezes. Execute a seguinte consulta para identificar inchaços de tabela:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

A dead_pct coluna nesta consulta é a percentagem de tuplas mortas quando comparadas com tuplas vivas. Um valor alto dead_pct para uma tabela pode indicar que ela não está sendo aspirada corretamente. Para obter mais informações, consulte Ajuste de vácuo automático no Banco de Dados do Azure para servidor flexível PostgreSQL.

Para cada tabela identificada, você pode executar uma análise de vácuo manual executando o seguinte:

vacuum(analyze, verbose) <table_name>

Usar um servidor PITR

Você pode realizar um pg_dump em um servidor online ou ao vivo. Ele faz backups consistentes mesmo se o banco de dados estiver sendo usado. Ele não impede que outros usuários usem o banco de dados. Considere o tamanho do banco de dados e outras necessidades comerciais ou do cliente antes de iniciar o processo de pg_dump. Bancos de dados pequenos podem ser bons candidatos para executar um pg_dump no servidor de produção.

Para bancos de dados grandes, você pode criar um servidor de recuperação point-in-time (PITR) a partir do servidor de produção e executar o processo de pg_dump no servidor PITR. Executar pg_dump em um PITR seria um processo de execução a frio. A contrapartida dessa abordagem é que você não estaria preocupado com a utilização extra de CPU, memória e E/S que vem com um processo de pg_dump executado em um servidor de produção real. Você pode executar pg_dump em um servidor PITR e, em seguida, soltar o servidor PITR após a conclusão do processo de pg_dump.

Ao observar um desempenho lento do pg_dump enquanto a largura de banda da rede é alta, considere optar por um SKU de vCore mais elevado. SKUs de vCore mais elevados normalmente fornecem taxa de transferência adicional de CPU e rede, o que pode reduzir o tempo geral de download. Monitore as métricas de CPU, rede e IOPS para confirmar se a largura de banda ou a computação é o gargalo antes de dimensionar.

Ajuste de parâmetros

Ajuste os seguintes parâmetros de servidor para ajudar a acelerar a criação de índice durante as operações de restauração. Arquivos do pg_dump geralmente incluem comandos de criação de índices (por exemplo, CREATE INDEX ou ALTER TABLE ... ADICIONAR RESTRIÇÃO); melhorar o desempenho na construção de índices pode reduzir o tempo total de migração:

  • maintenance_work_mem = 2097151 (2 GB) — Aumente esse valor para alocar mais memória para a criação de índices e outras tarefas de manutenção. Para índices grandes, considere aumentar essa configuração (por exemplo, centenas de megabytes para vários gigabytes) e validar o uso de memória em uma instância que não seja de produção antes de aplicá-la na produção.
  • max_parallel_maintenance_workers = 4 — Aumente esse valor para permitir a criação de índice paralelo em servidores multi-vCore. Defina isso em relação ao número de vCores e teste para determinar o nível ideal para sua carga de trabalho.

Teste qualquer parâmetro ou alterações de SKU em um servidor que não seja de produção ou PITR. Valide o desempenho e a estabilidade e, em seguida, aplique as alterações à produção. Após a conclusão da migração ou restaurações grandes, reverta os parâmetros para valores que correspondam aos requisitos normais da carga de trabalho.

Sintaxe para pg_dump

Use a seguinte sintaxe para pg_dump:

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

Você pode usar o utilitário pg_restore para restaurar um banco de dados de servidor flexível do Banco de Dados do Azure para PostgreSQL a partir de um arquivo morto criado por pg_dump. Algumas opções de linha de comando para reduzir o tempo geral de restauração estão listadas nas seções a seguir.

Restauração paralela

Usando vários trabalhos simultâneos, você pode reduzir o tempo necessário para restaurar um banco de dados grande em um servidor de destino multi-vCore. O número de trabalhos pode ser igual ou menor do que o número de vCPUs alocados para o servidor de destino.

Parâmetros do servidor

Se você estiver restaurando dados para um novo servidor ou servidor que não seja de produção, poderá otimizar os seguintes parâmetros de servidor antes de executar pg_restore:

work_mem = 32 MB
max_wal_size = 65536 (64 GB)
checkpoint_timeout = 3600 #60 min.
maintenance_work_mem = 2097151 (2 GB)
autovacuum = desligado
wal_compression = em

Depois que a restauração for concluída, certifique-se de que todos esses parâmetros sejam atualizados adequadamente de acordo com os requisitos da carga de trabalho.

Nota

Siga as recomendações anteriores somente se houver memória e espaço em disco suficientes. Se você tiver um servidor pequeno com 2, 4 ou 8 vCores, defina os parâmetros de acordo.

Outras considerações

  • Desative a alta disponibilidade (HA) antes de executar pg_restore.
  • Analise todas as tabelas que são migradas após a conclusão da restauração.

Sintaxe para pg_restore

Use a seguinte sintaxe para pg_restore:

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

  • -Fd: O formato de diretório.
  • -j: O número de postos de trabalho.
  • -C: Comece a saída com um comando para criar o próprio banco de dados e, em seguida, reconecte-se a ele.

Aqui está um exemplo de como essa sintaxe pode aparecer:

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

Considerações sobre máquinas virtuais

Crie uma máquina virtual na mesma região e zona de disponibilidade, de preferência onde você tenha os servidores de destino e de origem. Ou, no mínimo, crie a máquina virtual mais próxima do servidor de origem ou de um servidor de destino. Recomendamos que você use as Máquinas Virtuais do Azure com um SSD local de alto desempenho.

Para obter mais informações sobre as SKUs, consulte:

Examples

Aqui estão alguns exemplos de como usar pg_dump e pg_restore com as melhores práticas discutidas acima.

Usando pg_dump com formato de diretório e trabalhos paralelos

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -Fd -j 4 -f /backups/mydb_dump_dir

Explicação:

  • -Fd: Dumps de dados no formato de diretório, que é necessário para a restauração paralela.
  • -j 4: Usa 4 trabalhos paralelos para acelerar o descarregamento.
  • -f: Especifica o diretório de saída.

Usar pg_dump sem compressão para melhorar o desempenho

pg_dump -h <server>.postgres.database.azure.com -U <username> -d <database> \
  -F c -Z 0 -f /backups/mydb_nocompress.dump

Explicação:

  • -F c: Formato personalizado.
  • -Z 0: Desativa a compressão para melhorar o desempenho.

Usando pg_restore com observações paralelas

pg_restore -h <server>.postgres.database.azure.com -U <username> -d <target_database> \
  -Fd -j 4 /backups/mydb_dump_dir

Explicação:

  • -Fd: Corresponde ao formato de diretório usado no dump.
  • -j 4: Usa 4 trabalhos paralelos para acelerar a restauração.

Conteúdos relacionados

  • Last updated on