Partilhar via

Práticas recomendadas para pg_dump e pg_restore para o 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 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 PostgreSQL - Servidor flexível.

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.

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

Melhores práticas 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 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 #60min
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:

Partilhe as suas sugestões e bugs com a equipa de produto da Base de Dados do Azure para PostgreSQL.

Conteúdos relacionados