Compartilhar via

Melhores práticas para pg_dump e pg_restore no Banco de Dados do Azure para PostgreSQL ─ Servidor Flexível

  • Artigo

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

Este artigo analisa as opções e melhores práticas para acelerar pg_dump e pg_restore. Também explica as melhores configurações de servidor para realizar o 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 podem ser usadas para reduzir o tempo de despejo geral 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 pode ser inserido em pg_restore. Por padrão, a saída é compactada.

Trabalhos paralelos (-j)

Com pg_dump, é possível executar trabalhos de despejo simultaneamente usando a opção de trabalhos paralelos. Essa opção reduz o tempo total de dump, mas aumenta a carga no servidor de banco de dados. Recomenda-se chegar a um valor de trabalho paralelo após um monitoramento detalhado das métricas do servidor de origem, como uso de CPU, memória e IOPS (operações de entrada/saída por segundo).

Quando você define um valor para a opção de trabalhos paralelos, o pg_dump requer que o seguinte ocorra:

  • O número de conexões deve ser igual ao número de trabalhos paralelos +1, portanto, defina o valor max_connections adequadamente.
  • 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 compactação a ser usado. Zero significa sem compressão. A compactação zero durante o processo pg_dump pode ajudar nos ganhos de desempenho.

Incha a mesa e aspiração

Antes de iniciar o processo pg_dump, considere se a limpeza da tabela é necessária. O inchaço nas tabelas aumenta significativamente os tempos de pg_dump. Execute a seguinte consulta para identificar sobrecargas 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 coluna dead_pct na consulta é a porcentagem de tuplas mortas quando comparadas às vivas. Um valor dead_pct alto para uma tabela pode indicar que ela não está sendo limpa corretamente. Para saber mais, confira Ajuste do Autovacuum no Banco de Dados do Azure para PostgreSQL ─ Servidor Flexível.

Para cada tabela identificada, é possível realizar uma análise manual de limpeza executando o seguinte:

vacuum(analyze, verbose) <table_name>

Usar um servidor PITR

É possível executar um pg_dump em um servidor online ou ativo. 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 de negócios ou dos clientes antes de iniciar o processo de pg_dump. Bancos de dados pequenos podem ser bons candidatos para a execução de um pg_dump no servidor de produção.

Para bancos de dados grandes, é possível criar um servidor de PITR (recuperação pontual) com base no servidor de produção e executar o processo de pg_dump nele. A execução do pg_dump em um PITR seria um processo de execução a frio. A compensação dessa abordagem é que você não precisa se preocupar com a utilização extra de CPU, memória e E/S resultante da execução de um processo de pg_dump em um servidor de produção real. É possível executar o pg_dump em um servidor PITR e, após a conclusão do processo, remover esse servidor.

Sintaxe de 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

Práticas recomendadas para pg_restore

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

Ao usar diversos trabalhos simultâneos, é possível reduzir o tempo necessário para restaurar um grande banco de dados em um servidor de destino multi-vCore. O número de trabalhos pode ser igual ou menor que o número de vCPUs alocados para o servidor de destino.

Parâmetros do Servidor

Para a restauração de dados em um novo servidor ou em um servidor que não seja de produção, otimize os seguintes parâmetros do servidor antes da execução de pg_restore:

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

Após a conclusão da restauração, certifique-se de que todos esses parâmetros sejam atualizados adequadamente de acordo com os requisitos de carga de trabalho.

Observação

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

Outras considerações

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

Sintaxe de 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 do diretório.
  • -j: o número de trabalhos.
  • -C: inicie 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 a máquina virtual

Crie uma máquina virtual na mesma região e zona de disponibilidade, de preferência onde estão os servidores de destino e origem. Também é possível, no mínimo, criar a máquina virtual mais próxima do servidor de origem ou de destino. Recomenda-se usar as Máquinas Virtuais do Azure com um SSD local de alto desempenho.

Para saber mais sobre SKUs, confira:

Compartilhe suas sugestões e bugs com a equipe de produtos do Banco de Dados do Azure para PostgreSQL.

Conteúdo relacionado