Compartilhar via


Considerações de extensão específicas do Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Este artigo descreve algumas considerações especiais que você deve estar ciente ao usar determinadas extensões em uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL.

Pré-requisitos

Leia o artigo Como usar extensões do PostgreSQL para o Banco de Dados do Azure para PostgreSQL para saber como:

  • Extensões da lista de permitidos no Servidor Flexível do Banco de Dados do Azure para PostgreSQL
  • Carregue as bibliotecas de extensões que implantam bibliotecas binárias, que exigem alocação e acesso à memória compartilhada e precisam ser carregadas quando o servidor é iniciado.
  • Instale extensões em algum banco de dados de modo que os objetos SQL empacotados nessas extensões sejam implantados nesse banco de dados e possam ser acessados em seu contexto.
  • Remova extensões de algum banco de dados, de modo que os objetos SQL empacotados nessas extensões sejam removidos desse banco de dados.
  • Atualize os artefatos SQL implantados por uma extensão já instalada.
  • Exiba quais extensões estão instaladas e suas versões correspondentes.
  • Saiba quais são os possíveis erros com os quais você pode se deparar ao gerenciar extensões no Servidor Flexível do Banco de Dados do Azure para PostgreSQL, e qual pode ser a causa de cada um deles.

Extensões

A lista a seguir enumera todas as extensões com suporte que exigem considerações específicas quando usadas no serviço de servidor flexível do Banco de Dados do Azure para PostgreSQL:

  • dblink
  • pg_buffercache
  • pg_cron
  • pg_failover_slots
  • pg_hint_plan
  • pg_prewarm
  • pg_repack
  • pg_stat_statements
  • postgres_fdw
  • pgstattuple

A extensão dblink permite que você se conecte de uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL a outro ou outros bancos de dados no mesmo servidor. O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a conexões de entrada e saída para qualquer servidor PostgreSQL. O servidor de envio precisa permitir conexões de saída para o servidor de recebimento. Dessa forma, o servidor de recebimento precisa permitir conexões do servidor de envio por meio de seu firewall.

Se você planeja usar essa extensão, recomendamos a implantar seus servidores com integração de rede virtual. Por padrão, a integração de rede virtual permite conexões entre servidores na rede virtual. Você também pode optar por usar grupos de segurança de rede da rede virtual para personalizar o acesso.

pg_buffercache

A extensão pg_buffercache pode ser usada para estudar o conteúdo de shared_buffers. Usando essa extensão, você pode saber se uma determinada relação está armazenada em cache (em shared_buffers). Essa extensão pode ajudar você a solucionar problemas de desempenho (problemas de desempenho relacionados ao cache).

Essa extensão está integrada à instalação principal do PostgreSQL e é fácil de instalar.

CREATE EXTENSION pg_buffercache;

pg_cron

A extensão pg_cron é um agendador de trabalhos simples, baseado em cron, para o PostgreSQL que é executado dentro do banco de dados como uma extensão. A extensão pg_cron pode executar tarefas de manutenção agendadas em um banco de dados do PostgreSQL. Por exemplo, você pode executar um vácuo periódico de uma tabela ou remover trabalhos de dados antigos.

A extensão pg_cron pode executar vários trabalhos em paralelo, mas executa no máximo uma instância de um trabalho por vez. Se uma segunda execução for iniciada antes da conclusão da primeira, a segunda execução ficará fila e será iniciada assim que a primeira for concluída. Dessa forma, ela garante que os trabalhos sejam executados exatamente quantas vezes foram agendadas e não sejam executados simultaneamente com eles mesmos.

Certifique-se de que o valor definido para shared_preload_libraries inclua pg_cron. Esta extensão não dá suporte ao carregamento da biblioteca como efeito da execução de CREATE EXTENSION. Qualquer tentativa de executar CREATE EXTENSION se a extensão não tiver sido adicionada a shared_preload_libraries ou se o servidor não tiver sido reiniciado após ser adicionado resultará em um erro com o texto pg_cron can only be loaded via shared_preload_libraries e a dica Add pg_cron to the shared_preload_libraries configuration variable in postgresql.conf.

Para usar pg_cron, certifique-se de que a sua biblioteca tenha sido adicionada para ser carregada com a inicialização do servidor e de que ele tenha sido incluído na lista de permitidos e instalado em qualquer banco de dados a partir do qual você deseje interagir com a sua funcionalidade, usando os artefatos SQL criados por ele.

Exemplos

  1. Para excluir dados antigos no sábado às 3h30 (GMT).

    SELECT cron.schedule('30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$);
    
  2. Para executar o vácuo todos os dias às 10h00 (GMT) no banco de dados postgres padrão.

    SELECT cron.schedule('0 10 * * *', 'VACUUM');
    
  3. Para cancelar o agendamento de todas as tarefas do pg_cron.

    SELECT cron.unschedule(jobid) FROM cron.job;
    
  4. Para ver todos os trabalhos agendados no momento com pg_cron.

    SELECT * FROM cron.job;
    
  5. Para executar o vácuo todos os dias às 10h00 (GMT) no banco de dados test cron na conta de função azure_pg_admin.

    SELECT cron.schedule_in_database('VACUUM',' 0 10 * * * ', 'VACUUM', 'testcron',null,TRUE);
    

Mais exemplos

A partir do pg_cron versão 1.4, é possível usar as funções cron.schedule_in_database e cron.alter_job para agendar seu trabalho em um banco de dados específico e atualizar uma agenda existente, respectivamente.

A função cron_schedule_in_database permite o nome de usuário como um parâmetro opcional. Definir o nome de usuário como um valor não nulo requer o privilégio de superusuário do PostgreSQL e não tem suporte no servidor flexível do Banco de Dados do Azure para PostgreSQL. Os exemplos anteriores mostram a execução dessa função com um parâmetro opcional de nome de usuário omitido ou definido como nulo, o que executa o trabalho no contexto do usuário que está agendando o trabalho, que deve ter privilégios da função azure_pg_admin.

  1. Para excluir dados antigos no sábado às 3h30 (GMT) no banco de dados DBName.

    SELECT cron.schedule_in_database('JobName', '30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$,'DBName');
    
  2. Para atualizar ou alterar o nome do banco de dados do agendamento existente

    SELECT cron.alter_job(job_id:=MyJobID,database:='NewDBName');
    

pg_failover_slots

A extensão pg_failover_slots aprimora o servidor flexível do Banco de Dados do Azure para PostgreSQL ao operar com servidores habilitados para replicação lógica e alta disponibilidade. Ela aborda efetivamente o desafio dentro do mecanismo PostgreSQL padrão que não preserva slots de replicação lógica após um failover. A manutenção desses slots é fundamental para evitar pausas de replicação ou incompatibilidades de dados durante as alterações de função de servidor primário, garantindo a continuidade operacional e a integridade dos dados.

A extensão simplifica o processo de failover gerenciando a transferência, a limpeza e a sincronização necessárias de slots de replicação, fornecendo assim uma transição perfeita durante as alterações de função de servidor.

Você pode encontrar mais informações e instruções sobre como usar a extensão pg_failover_slots em sua página do GitHub.

Para usar a extensão pg_failover_slots, certifique-se de que a sua biblioteca tenha sido carregada com a inicialização do servidor.

pg_hint_plan

A extensão pg_hint_plan possibilita ajustar os planos de execução do PostgreSQL usando as chamadas "dicas" nos comentários SQL, como:

/*+ SeqScan(a) */

A extensão pg_hint_plan lê frases de dicas em um comentário do formulário especial fornecido com a instrução SQL de destino. O formulário específico começa com a sequência de caracteres "/*+" e termina com "*/". As frases de dica consistem em nomes de dica e parâmetros seguintes entre parênteses e delimitados por espaços. Novas linhas para legibilidade podem delimitar cada frase sugerida.

Exemplo:

/*+
 HashJoin(a b)
 SeqScan(a)
 */
    SELECT *
    FROM pgbench_branches b
    JOIN pgbench_accounts an ON b.bid = a.bid
    ORDER BY a.aid;

O exemplo anterior faz com que o planejador use os resultados de um seqscan na tabela a para combinar com a tabela b como um hashjoin.

Para usar a extensão pg_hint_plan, certifique-se incluir a extensão na lista de permitidos, carregar a sua biblioteca e instalar a extensão no banco de dados no qual você planeja usar a sua funcionalidade.

pg_prewarm

A extensão pg_prewarm carrega dados relacionais no cache. O pré-aquecimento dos caches significa que suas consultas têm melhores tempos de resposta na primeira execução após uma reinicialização. A funcionalidade de autoprewarm para o servidor flexível do PostgreSQL não está disponível atualmente no Banco de Dados do Azure.

pg_repack

No primeiro uso da extensão pg_repack, os usuários normalmente fazem a seguinte pergunta: pg_repack é uma extensão ou um executável do lado do cliente como psql ou pg_dump?

pg_repack é, na verdade, ambos. pg_repack/lib tem o código da extensão, incluindo o esquema e os artefatos SQL que ele cria, e a biblioteca C que implementa o código de várias dessas funções.

Por outro lado, pg_repack/bin tem o código do aplicativo cliente, que sabe como interagir com os elementos de programação implementados na extensão. Esse aplicativo cliente tem como objetivo facilitar a complexidade da interação com as diferentes interfaces apresentadas 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 ele está apontado. A extensão do lado do servidor por conta própria 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 usados como entrada para funções implementadas pela extensão etc.

Permissão negada para reempacotamento do esquema

Atualmente, como concedemos permissões para o esquema de reempacotamento criado por essa extensão, só fornecemos suporte à execução da funcionalidade pg_repack no contexto de azure_pg_admin.

Você pode notar que, se o proprietário de uma tabela, que não for azure_pg_admin, tentar executar pg_repack, ele acabará recebendo um erro como o seguinte:

NOTICE: Setting up workers.conns
ERROR: pg_repack failed with error: ERROR:  permission denied for schema repack
LINE 1: select repack.version(), repack.version_sql()

Para evitar esse erro, execute pg_repack do contexto de azure_pg_admin.

pg_stat_statements

A extensão pg_stat_statements oferece uma visão de todas as consultas executadas em seu banco de dados. Isso é útil para entender o desempenho da carga de trabalho da consulta em um sistema de produção.

A extensão pg_stat_statements é pré-carregada em shared_preload_libraries em cada instância do servidor flexível do Banco de Dados do Azure para PostgreSQL para fornecer um meio de rastrear as estatísticas de execução de instruções SQL.

Por motivos de segurança, insira a extensão pg_stat_statements à lista de permitidos e instale-a usando o comando CREATE EXTENSION.

A configuração pg_stat_statements.track, que controla quais instruções são controladas pela extensão, usa como padrão top, o que significa que todas as instruções emitidas diretamente pelos clientes são controladas. Dois outros níveis de rastreamento são none e all. Essa configuração é configurável como um parâmetro de servidor.

Há uma compensação entre as informações de execução de consulta que a extensão pg_stat_statements fornece sobre o desempenho do servidor à medida que registra cada instrução SQL. Se você não está usando ativamente a extensão pg_stat_statements, recomendamos que você defina pg_stat_statements.track como none. Alguns serviços de monitoramento de terceiros podem depender de pg_stat_statements para fornecer insights sobre o desempenho da consulta, portanto, confirme se esse é o seu caso.

postgres_fdw

A extensão postgres_fdw permite que você se conecte de uma instância do servidor flexível do Banco de Dados do Azure para PostgreSQL a outro ou outros bancos de dados no mesmo servidor. O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a conexões de entrada e saída para qualquer servidor PostgreSQL. O servidor de envio precisa permitir conexões de saída para o servidor de recebimento. Dessa forma, o servidor de recebimento precisa permitir conexões do servidor de envio por meio de seu firewall.

Se você planeja usar essa extensão, recomendamos a implantar seus servidores com integração de rede virtual. Por padrão, a integração de rede virtual permite conexões entre servidores na rede virtual. Você também pode optar por usar grupos de segurança de rede da rede virtual para personalizar o acesso.

pgstattuple

Ao usar a extensão pgstattuple para tentar obter estatísticas de tuplas de objetos mantidos no esquema pg_toast nas versões do Postgres 11 a 13, você receberá o erro "permissão negada para o esquema pg_toast".

Permissão negada para o esquema pg_toast

Os clientes que usam o PostgreSQL versões 11 a 13 no Banco de Dados do Azure para Servidor Flexível não podem usar a extensão pgstattuple em objetos dentro do esquema pg_toast.

No PostgreSQL 16 e 17, a função pg_read_all_data é concedida automaticamente a azure_pg_admin, permitindo que pgstattuple funcione corretamente. No PostgreSQL 14 e 15, os clientes podem conceder manualmente a função pg_read_all_data a azure_pg_admin para obter o mesmo resultado. No entanto, no PostgreSQL 11 a 13, a função pg_read_all_data não existe.

Os clientes não podem conceder diretamente as permissões necessárias. Se você precisar executar pgstattuple para acessar objetos no esquema pg_toast, prossiga para criar uma solicitação de suporte do Azure.

timescaleDB

A extensão timescaleDB é um banco de dados de série temporal empacotado como uma extensão para PostgreSQL. Ela fornece funções e otimizações analíticas orientadas para o tempo e escala o Postgres para cargas de trabalho de séries temporais. Saiba mais sobre o TimescaleDB, uma marca registrada da Timescale, Inc. O servidor flexível do Banco de Dados do Azure para PostgreSQL fornece a edição Apache-2 do TimescaleDB.

Instalar o TimescaleDB

Para usar timescaleDB, certifique-se de incluir a extensão na lista de permitidos, carregar a sua biblioteca e instalar a extensão no banco de dados no qual você planeja usar a sua funcionalidade.

Agora você pode criar uma hipertabela do TimescaleDB do zero ou migrar os dados de série temporal existentes no PostgreSQL.

Restaurar um banco de dados da Escala de tempo usando pg_dump e pg_restore

Para restaurar um banco de dados Timescale usando pg_dump e pg_restore, você deve executar dois procedimentos auxiliares no banco de dados de destino: timescaledb_pre_restore() e timescaledb_post restore().

Primeiro, prepare o banco de dados de destino:

--create the new database where you want to perform the restore
CREATE DATABASE tutorial;
\c tutorial --connect to the database
CREATE EXTENSION timescaledb;

SELECT timescaledb_pre_restore();

Agora, você pode executar pg_dump no banco de dados original e, em seguida, executar pg_restore. Após a restauração, lembre-se de executar o seguinte comando no banco de dados restaurado:

SELECT timescaledb_post_restore();

Para obter mais informações sobre o método de restauração com o banco de dados habilitado para Timescale, confira a documentação do Timescale.

Restaurando um banco de dados da Escala de tempo usando timescaledb-backup

Ao executar o procedimento SELECT timescaledb_post_restore(), você poderá ter permissões negadas ao atualizar o sinalizador timescaledb.restoring. Isso ocorre devido à permissão ALTER DATABASE limitada nos serviços de banco de dados de PaaS de nuvem. Nesse caso, você poderá executar um método alternativo usando a ferramenta timescaledb-backup para fazer backup e restaurar o banco de dados Timescale. O Timescaledb-backup é um programa que torna o despejo e a restauração de um banco de dados TimescaleDB mais simples, menos propenso a erros e mais eficiente.

Para fazer isso, siga estas etapas:

  1. Instale as ferramentas conforme detalhado aqui.

  2. Crie uma instância de servidor flexível e um banco de dados de destino do Banco de Dados do Azure para PostgreSQL.

  3. Habilite a extensão do Timescale.

  4. Conceda a função azure_pg_admin ao usuário que é usado por ts-restore.

  5. Execute ts-restore para restaurar o banco de dados.

Mais detalhes sobre esses utilitários podem ser encontrados aqui.

Extensões e atualização da versão principal

O servidor flexível do Banco de Dados do Azure para PostgreSQL oferece um recurso de atualização in-loco de versão principal, que executa uma atualização in-loco da instância de servidor flexível do Banco de Dados do Azure para PostgreSQL com apenas uma simples interação do usuário. A atualização de versão principal in-loco simplifica o processo de atualização do servidor flexível do Banco de Dados do Azure para PostgreSQL, minimizando a interrupção dos usuários e aplicativos que acessam o servidor. As atualizações de versões principais in-loco não dão suporte a extensões específicas, e há algumas limitações para a atualização de determinadas extensões.

As extensões anon, Apache AGE, dblink, orafce, pgaudit, postgres_fdw e timescaledb não têm suporte para todas as versões do servidor flexível do Banco de Dados do Azure para PostgreSQL ao usar o recurso de atualização da versão principal in-loco.