Partilhar via

Considerações com o uso de extensões e módulos

  • Artigo

Este artigo descreve algumas considerações especiais que você deve estar ciente ao usar determinadas extensões ou módulos em um servidor flexível do Banco de Dados do Azure para PostgreSQL.

Considerações genéricas com extensões

Para usar uma extensão em seu banco de dados do Azure para servidor flexível PostgreSQL, você precisa:

  • Permitir extensão. Se a extensão não for permitida, qualquer tentativa de executar CREATE EXTENSION, ALTER EXTENSION, DROP EXTENSIONou COMMENT ON EXTENSION falhar com um erro indicando que a extensão referida não é permitida.
  • Se a extensão implantar alguma biblioteca binária compartilhada que exija alocação e acesso à memória compartilhada e precisar ser carregada quando o servidor for iniciado, você também deverá seguir as instruções fornecidas em bibliotecas de carga.
  • Crie uma extensão nos bancos de dados nos quais você deseja que a extensão implante os objetos SQL distribuídos com essa extensão.
  • Extensão de gota. Quando você deseja remover do banco de dados no qual você executa o comando todos os objetos SQL distribuídos por essa extensão.
  • Atualizar extensões, para atualizar para sua versão mais recente todos os artefatos SQL implantados por uma extensão que já está instalada.
  • Veja as extensões instaladas e suas versões correspondentes.

Se você receber algum erro ao executar os CREATE EXTENSIONcomandos , DROP EXTENSIONALTER EXTENSIONou COMMENT ON EXTENSION em seu servidor flexível do Banco de Dados do Azure para PostgreSQL, consulte a lista de possíveis erros e qual pode ser a causa de cada um desses erros.

Considerações genéricas com módulos

Para usar um módulo em seu Banco de Dados do Azure para servidor flexível PostgreSQL, você só precisa adicioná-lo ao shared_preload_libraries parâmetro do servidor, conforme descrito em bibliotecas de carga.

Os módulos não precisam ser permitidos. Esse é um requisito exclusivo para extensões.

Extensões com considerações específicas

A lista a seguir enumera todas as extensões com suporte que exigem considerações específicas quando usadas em um banco de dados do Azure para servidor flexível PostgreSQL:

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

A dblink extensão permite que você se conecte de uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL a outro ou outro banco 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 com o servidor de recebimento. Da mesma forma, o servidor de recebimento precisa permitir conexões do servidor de envio.

Se você planeja usar essa extensão, recomendamos 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 de rede virtual para personalizar o acesso.

pg_buffercache

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

Esta extensão é integrada com a instalação principal do PostgreSQL, e é fácil de instalar.

CREATE EXTENSION pg_buffercache;

pg_cron

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

A pg_cron extensão pode executar vários trabalhos em paralelo, mas executa no máximo uma instância de um trabalho de cada vez. Se uma segunda execução deve começar antes que a primeira termine, a segunda execução é enfileirada e iniciada assim que a primeira é concluída. Dessa forma, ele garante que os trabalhos sejam executados exatamente quantas vezes forem programadas e não sejam executados simultaneamente com eles mesmos.

Certifique-se de que o valor para o qual shared_preload_libraries está definido, inclui pg_cron. Esta extensão não suporta o carregamento da biblioteca como o efeito da execução de CREATE EXTENSION. Qualquer tentativa de executar CREATE EXTENSION se a extensão não foi adicionada ao shared_preload_libraries, ou o servidor não foi reiniciado depois de ser adicionado, resulta em um erro cujo texto diz pg_cron can only be loaded via shared_preload_libraries, e cuja dica é Add pg_cron to the shared_preload_libraries configuration variable in postgresql.conf.

Para usar pg_crono , certifique-se de carregar sua biblioteca compartilhada ao iniciar o servidor, ela está na lista permitida e está instalada em qualquer banco de dados a partir do qual você deseja interagir com sua funcionalidade, usando os artefatos SQL que ele cria.

Exemplos

  1. Para apagar dados antigos no sábado às 3:30 am (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 10:00 am (GMT) no banco de dados postgrespadrão.

    SELECT cron.schedule('0 10 * * *', 'VACUUM');

  3. Para desagendar todas as tarefas de pg_cron.

    SELECT cron.unschedule(jobid) FROM cron.job;

  4. Para ver todos os trabalhos atualmente agendados com pg_crono .

    SELECT * FROM cron.job;

  5. Para executar o vácuo todos os dias às 10:00 am (GMT) no banco de dados test cron sob a conta de azure_pg_admin função.

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

Mais exemplos

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

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

  1. Para apagar dados antigos no sábado às 3:30 am (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 da base de dados no agendamento existente

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

pg_hint_plan

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

/*+ SeqScan(a) */

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

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 uma seqscan tabela a para combinar com a tabela b como um hashjoinarquivo .

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

pg_prewarm

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

pg_repack

Os usuários iniciantes da extensão normalmente fazem a seguinte pergunta: Uma extensão ou um executável do lado do pg_repack cliente é pg_repack 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.

Permissão negada para reempacotamento de esquema

Atualmente, como concedemos permissões para o esquema de reempacotamento criado por essa extensão, oferecemos suporte apenas à funcionalidade de execução pg_repack a partir do contexto do azure_pg_admin.

Você pode notar que, se o proprietário de uma tabela, que não azure_pg_adminé, tentar executar pg_repack, eles acabam recebendo o seguinte erro:

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 a partir do contexto de azure_pg_admin.

pg_stat_statements

A extensão pg_stat_statements oferece uma visão de todas as consultas que são executadas em seu banco de dados. Essas informações são úteis para entender o desempenho da carga de trabalho de consulta em um sistema de produção.

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

Por motivos de segurança, você deve permitir a lista da extensão pg_stat_statements e instalá-la usando o comando CREATE EXTENSION.

A configuração pg_stat_statements.track, que controla quais instruções a extensão rastreia, assume como toppadrão , o que significa que todas as instruções emitidas diretamente pelos clientes são rastreadas. Os outros dois níveis de rastreamento são none e all. Esta definição é configurável como parâmetro do servidor.

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

postgres_fdw

A postgres_fdw extensão permite que você se conecte de uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL a outro ou outro banco 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 com o servidor de recebimento. Da mesma forma, o servidor de recebimento precisa permitir conexões do servidor de envio.

Se você planeja usar essa extensão, recomendamos 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 de rede virtual para personalizar o acesso.

pgstattuple

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

Permissão negada para o esquema pg_toast

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

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

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

Escala de tempoDB

A timescaleDB extensão é um banco de dados de séries temporais empacotado como uma extensão para PostgreSQL. Ele fornece funções analíticas orientadas ao tempo e otimizações e dimensiona o Postgres para cargas de trabalho de séries temporais. Saiba mais sobre TimescaleDB, uma marca registada da Timescale, Inc.

Instalar o TimescaleDB

Para usar timescaleDBo , certifique-se de permitir a lista de extensões, carregar sua biblioteca e instalar a extensão no banco de dados no qual você planeja usar sua funcionalidade.

Agora você pode criar uma hipertabela TimescaleDB do zero ou migrar dados de séries cronológicas existentes no PostgreSQL.

Para obter mais informações sobre como restaurar um banco de dados Timescale usando pg_dump e pg_restore, consulte a documentação Timescale.

Restaurar um banco de dados Timescale usando timescaledb-backup

Ao executar o procedimento, você pode obter permissões negadas ao atualizar o SELECT timescaledb_post_restore() sinalizador timescaledb.restoreing. A razão pela qual você recebe esse erro é devido à permissão limitada ALTER DATABASE nos serviços de banco de dados Cloud PaaS. Nesse caso, você pode executar um método alternativo usando a timescaledb-backup ferramenta para fazer backup e restaurar o banco de dados Timescale. 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 o fazer, siga estes passos:

  1. Instale as ferramentas conforme detalhado aqui.

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

  3. Habilite a extensão de escala de tempo.

  4. Conceda a azure_pg_admin função ao usuário que é usada pelo 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 de versão principal in-loco que executa uma atualização in-loco da instância flexível do servidor flexível do Banco de Dados do Azure para PostgreSQL, com apenas uma interação simples do usuário. A atualização da versão principal in-loco simplifica o processo de atualização flexível do servidor do Banco de Dados do Azure para PostgreSQL, minimizando a interrupção para usuários e aplicativos que acessam o servidor. As atualizações de versão principal in-loco não suportam extensões específicas e há algumas limitações para atualizar determinadas extensões.

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

Módulos com considerações específicas

A lista a seguir enumera todos os módulos com suporte que exigem considerações específicas quando usados em um banco de dados do Azure para servidor flexível PostgreSQL:

  • pg_failover_slots

pg_failover_slots

A pg_failover_slots extensão aprimora o Banco de Dados do Azure para servidor flexível PostgreSQL ao operar com replicação lógica e servidores habilitados para alta disponibilidade. Ele efetivamente aborda 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 alterações na função de servidor principal, 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 dos slots de replicação, proporcionando 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 pg_failover_slots extensão em sua página no GitHub.

Para usar a pg_failover_slots extensão, certifique-se de que sua biblioteca foi carregada quando o servidor foi iniciado.

Conteúdos relacionados