Partilhar via

Vácuo total usando pg_repack 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

Neste artigo, você aprenderá a usar pg_repack para remover o inchaço e melhorar o desempenho do servidor flexível do Banco de Dados do Azure para PostgreSQL. A sobrecarga é a acumulação de dados desnecessários em tabelas e índices devido a atualizações e eliminações frequentes. O inchaço pode fazer com que o tamanho do banco de dados cresça mais do que o esperado e pode afetar gravemente o desempenho de algumas consultas. Use pg_repack para recuperar o espaço desperdiçado e reorganizar os dados de forma mais eficiente.

O que é pg_repack?

pg_repack é uma extensão PostgreSQL que remove o inchaço de tabelas e índices e os reorganiza de forma mais eficiente. pg_repack Funciona criando uma nova cópia da tabela ou índice de destino, aplicando quaisquer alterações que ocorreram durante o processo e, em seguida, trocando as versões antiga e nova atomicamente. pg_repack não requer nenhum tempo de inatividade ou bloqueios de acesso exclusivos na tabela ou índice processado, exceto por um breve período no início e no final da operação. Você pode usar pg_repack para otimizar qualquer tabela ou índice em seu Banco de Dados do Azure para bancos de dados de servidor flexíveis PostgreSQL.

Como usar pg_repack?

Para usar pg_repacko , você precisa instalar a extensão em seu banco de dados de servidor flexível do Banco de Dados do Azure para PostgreSQL e, em seguida, executar o pg_repack comando, especificando o nome da tabela ou o índice que deseja otimizar. A extensão adquire bloqueios na tabela ou índice para impedir que outras operações sejam executadas enquanto a otimização está em andamento. Ele remove o inchaço e reorganiza os dados de forma mais eficiente.

Como funciona a reembalagem de mesa cheia

Para executar uma reembalagem de tabela completa, a extensão segue estas etapas:

  1. Cria uma tabela de log para registrar as alterações feitas na tabela original.
  2. Adiciona um gatilho à tabela original, registrando INSERTs, UPDATEs e DELETEs na tabela de log.
  3. Cria uma nova tabela contendo todas as linhas da tabela original.
  4. Cria índices na nova tabela.
  5. Aplica todas as alterações registradas na tabela de log à nova tabela.
  6. Troca as tabelas original e nova, incluindo índices e tabelas do sistema.
  7. Deixa cair a tabela original.

Durante estas etapas, pg_repack mantém apenas um bloqueio de acesso exclusivo por um curto período, durante a configuração inicial (etapas 1 e 2) e novamente durante a fase final de troca e queda (etapas 6 e 7). Para o resto do tempo, pg_repack só precisa manter um bloqueio de acesso compartilhado na tabela original, permitindo que INSERTs, UPDATEs e DELETEs prossigam como de costume.

Limitações

pg_repack tem algumas limitações que você deve estar ciente antes de usá-lo:

  • A tabela de destino deve ter uma CHAVE PRIMÁRIA ou um índice EXCLUSIVO em uma coluna NOT NULL para que a operação seja bem-sucedida.
  • Enquanto pg_repack estiver em execução, você não poderá executar nenhum comando DDL (Data Definition Language) nas tabelas de destino, exceto VACUUM ou ANALYZE. Para garantir que essas restrições sejam impostas, pg_repack mantém um bloqueio de acesso compartilhado na tabela de destino durante uma reembalagem completa da tabela.

Configurar

Pré-requisitos

  1. Configure a pg_repack extensão permitindo listagem e criando a extensão.

Criar pg_repack aplicativo cliente

O uso desta extensão requer um aplicativo cliente que você pode construir e instalar em uma instância do Ubuntu.

Para instalar a versão 1.4.7 do pg_repack, execute o seguinte script bash em uma máquina Ubuntu.

# Create the file repository configuration
sudo sh -c 'echo "deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
# Import the repository signing key
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
# Update the package lists
sudo apt-get update
# Install required packages to build the code
sudo apt-get install -y postgresql-server-dev-14 unzip make gcc libssl-dev liblz4-dev zlib1g-dev libreadline-dev libzstd-dev
# Download compressed version of build tree for version 1.4.7 of pg_repack
wget 'https://api.pgxn.org/dist/pg_repack/1.4.7/pg_repack-1.4.7.zip'
# Uncompress build tree
unzip pg_repack-1.4.7.zip
# Set current directory to where build tree was uncompressed
cd pg_repack-1.4.7
# Build code
sudo make
# Copy resulting binaries to /usr/local/bin
sudo cp bin/pg_repack /usr/local/bin
# Run pg_repack to check its version
pg_repack --version

Utilizar pg_repack

Exemplo de como executar pg_repack em uma tabela chamada info em um esquema público dentro da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL com pgserver.postgres.database.azure.com de ponto de extremidade, nome de usuário azureuser e foo de banco de dados usando o comando a seguir.

  1. Usando o cliente de sua preferência, conecte-se à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Usamos psql neste exemplo.

        psql "host=<server>.postgres.database.azure.com port=5432 dbname=<database> user=<user> password=<password> sslmode=require"

  2. Encontre a versão da extensão instalada no banco de pg_repack dados.

    SELECT installed_version FROM pg_available_extensions WHERE name = 'pg_repack';

  3. A versão da extensão deve corresponder à versão do aplicativo cliente, que você pode verificar executando este comando:

    azureuser@azureuser:~$ pg_repack --version

  4. Execute pg_repack o cliente em uma tabela chamada info que existe no banco de dados foo.

    pg_repack --host=<server>.postgres.database.azure.com --username=<user> --dbname=<database> --table=info --jobs=2 --no-kill-backend --no-superuser-check

pg_repack opções

Opções úteis pg_repack para cargas de trabalho de produção:

  • -k, --no-superuser-check: Ignore as verificações de superusuário no cliente. Essa configuração é útil para uso pg_repack em plataformas que dão suporte à execução como não superusuários, como o Banco de Dados do Azure para instâncias de servidor flexíveis do PostgreSQL.

  • -j, --jobs: Crie o número especificado de conexões extras com o Banco de Dados do Azure para servidor flexível PostgreSQL e use essas conexões extras para paralelizar a reconstrução de índices em cada tabela. Compilações de índice paralelo são suportadas apenas para repacotes de tabela completa.

  • --index ou --only opções de índices: se sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL tiver núcleos extras e E/S de disco disponíveis, o uso dessa opção pode ser uma maneira útil de acelerar pg_repacko .

  • -D, --no-kill-backend: Em vez de matar clientes de back-end que estão executando consultas de bloqueio, ignore o reempacotamento de uma tabela se o bloqueio não puder ser adquirido depois de aguardar o tempo especificado em --wait-timeout. Por padrão, --wait-timeout é definido como 60 segundos. O valor padrão para esse parâmetro é false.

  • -E LEVEL, --elevel=LEVEL: Escolha o nível da mensagem de saída de DEBUG, INFO, , NOTICE, WARNING, ERRORLOG, FATAL, e PANIC. A predefinição é INFO.

Para entender todas as opções, consulte a documentação do pg_repack.

Perguntas Mais Frequentes

O pg_repack é uma extensão ou um executável do lado do cliente como psql ou pg_dump?

pg_repack na verdade são as duas coisas. pg_repack/lib tem o código para a extensão, incluindo o esquema e os artefatos SQL que ele cria, e a biblioteca C implementando o código de várias dessas funções.

Por outro lado, pg_repack/bin tem o código para o aplicativo cliente, que sabe como interagir com os elementos de programação implementados na extensão. Este aplicativo cliente visa facilitar a complexidade da interação com as diferentes interfaces afloradas pela extensão do lado do servidor. Ele oferece ao usuário algumas opções de linha de comando que são mais fáceis de entender. O aplicativo cliente é inútil sem a extensão criada no banco de dados para o qual está sendo apontado. A extensão do lado do servidor por si só seria totalmente funcional, mas exigiria que o usuário entendesse um padrão de interação complicado. Esse padrão consistiria na execução de consultas para recuperar dados que são usados como entrada para funções implementadas pela extensão, etc.

Conteúdos relacionados