Savepoint https://savepoint.blog.br Soluções em PostgreSQL Mon, 08 Jun 2026 19:00:53 +0000 pt-BR hourly 1 https://wordpress.org/?v=7.0 https://savepoint.blog.br/wp-content/uploads/2023/12/simbolo_savepoint-150x150.png Savepoint https://savepoint.blog.br 32 32 43493209 A história das conferências nacionais de PostgreSQL no Brasil https://savepoint.blog.br/2026/06/05/a-historia-das-conferencias-nacionais-de-postgresql-no-brasil/ Sat, 06 Jun 2026 01:18:43 +0000 https://savepoint.blog.br/?p=15343 (Work in progress) São quase 20 anos de história, e eu queria só organizar algumas informações e fotos aqui. Já faz tempo que eu não sou kahuna do evento, tem uma nova geração maravilhosa fazendo história, mas… parte dessa história vem se perdendo e eu gostaria de resgatar um pouco disso aqui. O site da

The post A história das conferências nacionais de PostgreSQL no Brasil first appeared on Savepoint.

]]> (Work in progress)

São quase 20 anos de história, e eu queria só organizar algumas informações e fotos aqui. Já faz tempo que eu não sou kahuna do evento, tem uma nova geração maravilhosa fazendo história, mas… parte dessa história vem se perdendo e eu gostaria de resgatar um pouco disso aqui. O site da comunidade, o postgresql.org.br resistiu por muito tempo, com a honrosa contribuição do FAW, mas um dia se perdeu. Depois o site do pgconf.com.br também se perdeu, com as edições organizadas pela Timbira, e agora temos um novo site com as edições de 2025, 2024 e 2023. Todo o resto se perdeu. E tem muita história para contar. Então, se você tem um relato, fotos, palestra, etc, mande para mim, que eu adoraria adicionar aqui.

1a Conferencia Brasileira de PostgreSQL
PGCon Brasil 2007

  • Quando: 7 e 8 de dezembro de 2007,
  • Onde: São Paulo/SP (Auditório São Camilo, Pompeia)
  • Salas: 1 auditório
  • Público estimado: 150+
  • Oliveira de Padua Tempo Real Eventos
  • Outros organizadores:
    • Diogo Biazus
    • Euler Taveira
    • Fábio Telles Rodriguez
    • Fernando Ike
    • Isis Bussons
    • Kenia Milene Gallego
    • Leonardo Cezar
    • Rodrigo Marins
  • Key notes:
    • Josh Berkus
    • David Fetter – A Babel of Programming Languages
  • Outros palestrantes:
    • Diogo Biazus – Preciso armazenar arquivos no banco. O que fazer?
    • Euler Taveira – Sintonia em SQL
    • Fábio Telles – Fazendo um elefante passar debaixo da porta
    • Fernando Ike – PostgreSQL Tuning: Elefante mais rápido que um leopardo
    • Francisco Figueiredo Jr. – Npgsql: .Net Data Provider para o PostgreSQL
    • Leandro Dutra – Modelagem e Administração de Dados em PostgreSQL
    • Lucio Chiessi – Tim Studio e Tim Portal
    • Monica Tissiani De Toni Pereira – Recursos aplicados a distribuição de dados
  • Links:
  • Fotos

2a Conferencia Brasileira de PostgreSQL
PGCon Brasil 2008

  • Quando: 26 e 27 de Setembro de 2008
  • Onde: Campinas/SP (Auditório da Unicamp)
  • Salas: 1 auditório
  • Público estimado:
  • Palestras: 16
  • Kahunas:
    • Fábio Telles Rodriguez
    • Leonardo Cezar
  • Outros organizadores:
    • Dickson S. Guedes
    • Euler Taveira
    • Fernando Ike
    • Leandro Dutra
    • Rodrigo Gomes Santana
    • Rodrigo Marins
    • Sebastian SWC
    • Thiago Risso
  • Key notes:
    • Bruce Momjian – “PostgreSQL’s Path to the Future”
    • David Fetter
  • Outros palestrantes:
    • Dickson dos Santos Guedes – Replicação Síncrona – “Não existe almoço de graça!”
    • Diogo Biazus – PostgreSQL Br – “Passado, Presente e Futuro”
    • Eduardo Leal – “Utilizando o PostgreSQL em bancos de dados biológicos”
    • Euler Taveira – “Monitorando o PostgreSQL”
    • Fábio Telles – “PostgreSQL, o Elefante Encouraçado”
    • Fernando Ike – “skytools, pgbouncer, plproxy”
    • Leandro Dutra –
    • Wagner Corrêa Ramos – “Projeto de replicação multi-master com 143 servidores”
  • Relatos:

III Conferencia Brasileira de PostgreSQL
PGCon Brasil 2009

  • Quando: 24 e 25 de Outubro de 2009
  • Onde: Campinas/SP (Auditórios da Unicamp)
  • Salas: 2 auditórios e uma sala
    • 40 propostas na chamada de trabalhos
    • 1 mesa redonda
    • 4 tutoriais
    • 4 Hacker Talks
    • 14 palestras
    • 10 Lithning Talks
  • Kahunas:
    • Fábio Telles Rodriguez
    • Leonardo Cezar
  • Outros organizadores
    • Dickson Guedes
    • Diogo Biazus
    • Euler Taveira
    • Fernando Ike
    • Marcelo Costa
  • Banca avaliadora:
    • Fernando Ike
    • Leandro Gumarães Faria Corcete Dutra
    • Luis Fernando Bueno
  • Key notes
    • Bruce Momjian
      • Rapid Upgrades With PG_Migrator;
      • How To Get You PostgreSQL Patch Accepted;
    • Magnus Hagander
      • Secure PostgreSQL Deployment;
      • Using git to help you develop a PostgreSQL patch;
  • Outros palestrantes
    • Claudio C. Filho – Coordenação da mesa: Adoção de PostgreSQL pelo Governo Federal Brasileiro
    • Diogo Biazus – Monitoramento do PostgreSQL com collectd
    • Edson Ie – Alta disponibilidade com HadoopDB
    • Euler Taveira
      • Desenvolvendo sua extensão em C
      • pg_similarity: buscas aproximadas
    • Evandro Silvestre – Acesse e utilize os Medadados do PostgreSQL sem medo
    • Fabiano Machado Dias e Eduardo Wolak – Usando PostgreSQL na Regra de Negócio de um ERP
    • Fábio Telles – Tudo o que você queria saber sobre o uso de discos em servidores PostgreSQL mas tinha vergonha de perguntar
    • Fernando Ike – Ele veio e o que tem de bom
    • Flávio Gurgel – PostgreSQL em ambiente financeiro de alta criticidade
    • Francisco Figueiredo Jr. – Introdução ao Npgsql -.Net Data Provider para PostgreSQL
    • George Rodrigues – O uso do PostgreSQL e PostGIS para o cadastro geocodificado de acidentes
    • João Cosme Jr. – Particionando os dados e balanceando a carga com o PLProxy
    • Leandro Dutra – O elefante arborícola: consultas recursívas com espressões comuns de tabelas
    • Luis Fernando Bueno – Análise Espacial com PostGIS
    • Maiano Alejandro Reingart e Emanuel Calvo Franco – Introducint PyReplica: a simple and customizabre replication solution
    • Sérgio Lifschitz – Proposta de índices hipotéticos no PostgreSQL
    • Roberto Mello – PL/pgSQL para diversão e lucro
  • Relatos

PGBR 2010

  • Onde: Brasília/DF

Evento cancelado

IV Conferencia Brasileira de PostgreSQLPGBR 2011

  • Quando
  • Onde:

The post A história das conferências nacionais de PostgreSQL no Brasil first appeared on Savepoint.

]]> 15343 Sobre o PGConf.Brasil 2025 https://savepoint.blog.br/2025/09/06/sobre-o-pgconf-brasil-2025/ https://savepoint.blog.br/2025/09/06/sobre-o-pgconf-brasil-2025/#respond Sat, 06 Sep 2025 14:34:04 +0000 https://savepoint.blog.br/?p=14435 Nos dias 3, 4 e 5 de setembro de 2025, em João Pessoa, PB, o PGConf.Brasil brilhou pela primeira vez no nordeste. Este foi o segundo evento organizado pela “Associação PostgreSQL Brasil” que mostrou claramente que o PostgreSQL continua vivo e vibrante no Brasil. E mais uma vez, a Savepoint esteve lá! Palestra: Métricas e

The post Sobre o PGConf.Brasil 2025 first appeared on Savepoint.

]]> Nos dias 3, 4 e 5 de setembro de 2025, em João Pessoa, PB, o PGConf.Brasil brilhou pela primeira vez no nordeste. Este foi o segundo evento organizado pela “Associação PostgreSQL Brasil” que mostrou claramente que o PostgreSQL continua vivo e vibrante no Brasil. E mais uma vez, a Savepoint esteve lá!

Palestra: Métricas e ajustes no PostgreSQL

Nesta palestra apresentamos alguns pontos-chave para monitorar e ajustar o PostgreSQL:

  • Scripts
  • Inspeção no catálogo
  • Ajustes no SO
  • Ajustes globais no PostgreSQL
  • Ajustes individuais objetos
  • Ajustes em consultas

The post Sobre o PGConf.Brasil 2025 first appeared on Savepoint.

]]> https://savepoint.blog.br/2025/09/06/sobre-o-pgconf-brasil-2025/feed/ 0 14435 Meu Postgres não conecta: troubleshooting de conexões https://savepoint.blog.br/2024/12/16/meu-postgres-nao-conecta-troubleshooting-de-conexoes/ https://savepoint.blog.br/2024/12/16/meu-postgres-nao-conecta-troubleshooting-de-conexoes/#respond Mon, 16 Dec 2024 18:43:36 +0000 https://savepoint.blog.br/?p=8554 Resolva erros de conexão no Postgres com este guia prático: verifique serviço, rota, permissões e configurações essenciais.

The post Meu Postgres não conecta: troubleshooting de conexões first appeared on Savepoint.

]]> Introdução

Nesse artigo, vamos explorar problemas comuns ao tentar se conectar com seu servidor Postgres. Há diversas possibilidades de problemas enfrentados, então veremos cenários mais comuns e como solucioná-los da maneira mais simples e rápida possível.

Roteiro:

  • O postgres está no ar?
  • Temos rota para conectar?
  • O pg_hba.conf e o postgresql.conf estão conectados devidamente?
  • Eu tenho permissão para me conectar?
  • Meu usuário existe?
  • O banco de dados existe?
  • A senha está correta?


Verifique sempre os logs da sua aplicação e, se possível, tente estabelecer uma conexão com o banco de dados utilizando o psql, que é o client oficial do PostgreSQL. Faça isso para eliminar qualquer possibilidade de erro em outra camada da sua aplicação e para poder ver claramente os erros que acontecem durante a conexão. Claro que para isso você vai precisar instalar o client do PostgreSQL no seu servidor de aplicação ou desktop, dependendo do caso. Sempre teste a conexão a partir do mesmo lugar da aplicação. Dependendo da origem da conexão, rotas, firewalls, VPNs, entre outras variáveis na sua rede podem mudar. Vamos mostrar aqui vários exemplos de erros que acontecem durante a conexão e simulá-los sempre utilizando o psql.

Recebi uma mensagem dizendo que o banco de dados não está no ar!

Na maioria das vezes, o erro que você vai receber quando tem um problema de conexão é este aqui:

psql shell: mensagem de erro por banco de dados fora do ar
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?


Apesar de a mensagem dar a entender que o seu banco de dados não está no ar, o motivo desse aviso pode variar um pouco:

  1. Você pode ter digitado o endereço do servidor ou a porta incorretamente;
  2. Você pode não ter uma rota na rede até o servidor;
  3. Pode haver um firewall bloqueando o caminho até o servidor;
  4. O banco de dados pode realmente não estar no ar; 
  5. O parâmetro listen_address pode estar desativado para esse IP.

A primeira coisa a fazer numa tentativa falha de conexão com o banco de dados, como a exibida anteriormente, é checar se o serviço do banco está disponível, ou seja, no ar. 

É possível verificar o status desse serviço com diversos comandos, que já abordamos por aqui, mas, para relembrar, veja alguns deles (se executados como usuário root, pode ser necessário utilizar o comando sudo antes, caso esteja logado com outro usuário):

  • ps -faux | grep postgres (este método é o mais confiável e funciona para qualquer ambiente Linux/Unix):
Debian shell: processos postgres
# ps -faux | grep postgres
root     1820618  0.0  0.1   3876  1832 pts/0    S+   14:41   0:00          \_ grep postgres
999      3358569  0.0  1.4 220064 14652 ?        Ss   Jul23   7:16  \_ postgres
999      3358637  0.0  3.1 220352 31392 ?        Ss   Jul23   0:05      \_ postgres: checkpointer
999      3358638  0.0  0.7 220216  7452 ?        Ss   Jul23   1:07      \_ postgres: background writer
999      3358640  0.0  0.7 220192  6904 ?        Ss   Jul23   1:13      \_ postgres: walwriter
999      3358641  0.0  0.4 221656  4024 ?        Ss   Jul23   1:45      \_ postgres: autovacuum launcher
999      3358642  0.0  0.4 221644  4020 ?        Ss   Jul23   0:03      \_ postgres: logical replication launcher
999        82547  0.0  1.0  11828 10184 ?        Sl   Aug20   4:02      \_ postgres:
999      1800988 99.5 27.7 308912 272700 ?       Sl   Oct16 1170:12          \_ postgres:


Caso o banco não esteja no ar, não aparecerão os diversos processos do serviço postgres, aparecendo, em geral, apenas o processo da própria busca do comando grep.

  • systemctl status postgresql (funciona para sistemas Linux modernos que usam o systemd configurados corretamente com o PostgreSQL. Porém, nos sistemas baseados em Red Hat, é necessário colocar -<número_versão> após postgresql, por exemplo: systemctl status postgresql-13): 
Debian shell: consulta do status do serviço postgres
# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2024-04-09 18:41:03 UTC; 5 months 0 days ago
    Process: 439735 ExecReload=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 171728 (code=exited, status=0/SUCCESS)
        CPU: 1ms

Sep 04 19:32:13 debian-teste systemd[1]: Reloading postgresql.service - PostgreSQL RDBMS...
...

Se o banco de dados estiver fora do ar, a seção ‘Active’ exibirá ‘inactive (dead)’, também indicando desde quando o serviço está nesse estado, conforme o exemplo. Há a possibilidade de o comando systemctl não estar disponível, se o servidor foi inicializado sem o systemd, e se for esse o caso, deverão ser utilizadas as outras alternativas demonstradas.

Uma última observação importante é que se o PostgreSQL estiver sendo manipulado sem o comando systemctl, pode ser que este método apresente informações incorretas, portanto, pode não ser uma boa ideia confiar nele.

  • pg_lsclusters (para sistemas baseados em Debian):
Debian shell: consulta do serviço postgres
# pg_lsclusters
Ver Cluster     Port Status Owner    Data directory                     Log file
16  main        5432 online postgres /var/lib/postgresql/16/main        /var/log/postgresql/postgresql-16-main.log
16  novocluster 5433 online postgres /var/lib/postgresql/16/novocluster /var/log/postgresql/postgresql-16-novocluster.log


Aqui, se o serviço estiver fora do ar, aparecerá ‘down’ no lugar de ‘online’, com as letras geralmente na cor vermelha, para indicar que não está funcionando. 

  • pg_ctlcluster <sua_versao> <nome_cluster> status (apenas para sistemas baseados em Debian):
Debian shell: consulta do serviço postgres
# pg_ctlcluster 16 main status
pg_ctl: server is running (PID: 433805)
/usr/lib/postgresql/16/bin/postgres "-D" "/var/lib/postgresql/16/main" "-c" "config_file=/etc/postgresql/16/main/postgresql.conf"


No caso de o banco estar fora do ar, o retorno será ‘pg_ctl: no server running’.

  • sc query postgresql-x64-<número_versão> (para Windows):
Windows shell: consulta do serviço postgres
C:\Windows\System32>sc query postgresql-x64-16

NOME_DO_SERVIÇO: postgresql-x64-16
    TIPO                       : 10  WIN32_OWN_PROCESS
    ESTADO                     : 4  RUNNING
                                (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
    CÓDIGO_DE_SAÍDA_DO_WIN32   : 0  (0x0)
    CÓDIGO_DE_SAÍDA_DO_SERVIÇO : 0  (0x0)
    PONTO_DE_VERIFICAÇÃO       : 0x0
    AGUARDAR_DICA              : 0x0

Aqui, a mudança para o banco fora do ar seria no ‘ESTADO’, diferente de ‘RUNNING’.

Como você pode ver, nos nossos exemplos, todos os comandos retornaram resposta positiva quanto ao estado do serviço do banco, que está no ar. Mas e se não estivesse, o que poderia ser feito? Como já citamos em artigos anteriores, no Linux é possível gerenciar o estado do seu banco de dados também com o utilitário systemctl:

  • Para subir, poderíamos utilizar o comando (que não tem saída):
    systemctl start postgresql

    E assim checar novamente o status do banco por um dos meios mencionados anteriormente.

    Em Windows, o comando para iniciar é: net start postgresql-x64-16 


Observação: se você iniciou o serviço, verifique se ele realmente subiu. Se não subir, verifique os logs do PostgreSQL para entender o motivo. Se o banco de dados estiver no ar, verifique novamente se a conexão funciona, primeiro localmente, depois remotamente.

Temos rota para conectar?

Depois de checar o status do serviço do PostgreSQL, caso ainda não tenha conseguido conectar, pode ser interessante checar a rota de conexão com o banco de dados. 
Algumas das mensagens de erros comuns para esse tipo de situação são:

psql shell: mensagem de erro por conexão recusada
psql: error: could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?
psql shell: mensagem de erro por conexão falha
psql: error: connection to server at "192.168.0.1", port 5432 failed: Connection timed out        
Is the server running on that host and accepting TCP/IP connections?

Podemos conferir o status da rota consultando a conectividade de rede entre o cliente e o servidor PostgreSQL por meio de algumas ferramentas comuns:

  • Ping: verifica se o servidor está acessível a partir do cliente. O comando ping <ip-do-servidor> pode ser usado para verificar a resposta do servidor. Se o servidor não responder, isso pode indicar problemas de rede, como bloqueio por firewall ou roteamento incorreto. O comando ping está disponível tanto em Windows quanto em Linux e funciona de forma similar. É um bom comando para ver se um servidor está no ar, mesmo sem saber a porta que será utilizada. No entanto, alguns servidores têm o “ping” bloqueado intencionalmente por motivos de segurança, por isso ele nem sempre é a forma mais recomendada de verificar se o servidor remoto está acessível. 
Debian shell: teste de conexão via comando ping
$ ping 159.89.241.130
PING 159.89.241.130 (10.0.0.240) 56(84) bytes of data.
64 bytes from 159.89.241.130: icmp_seq=1 ttl=64 time=0.081 ms
64 bytes from 159.89.241.130: icmp_seq=2 ttl=64 time=0.127 ms
64 bytes from 159.89.241.130: icmp_seq=3 ttl=64 time=0.063 ms
64 bytes from 159.89.241.130: icmp_seq=4 ttl=64 time=0.058 ms
64 bytes from 159.89.241.130: icmp_seq=5 ttl=64 time=0.054 ms
64 bytes from 159.89.241.130: icmp_seq=6 ttl=64 time=0.062 ms
  • Porta: em todos os demais exemplos, você vai precisar saber em qual porta o PostgreSQL está rodando. A porta padrão é a 5432, mas ela pode ser substituída por outra conforme a necessidade. Uma maneira confiável de verificar a porta em uso é conectar-se ao banco de dados localmente via psql e executar o comando SHOW port:
psql shell: consulta de porta
postgres=# SHOW port;
 port
------
 5432
(1 row)

No caso de sistemas baseados em Debian, também é possível usar o comando pg_lsclusters:

Debian shell: consulta de porta
# pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
16  main    5432 online postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.log
  • Nmap: o Nmap foi desenvolvido na década de 1990 como uma forma de descobrir serviços e portas utilizadas numa rede. Se você não tiver acesso local ao servidor, para verificar qual é a porta utilizada, ou se o seu administrador de redes estiver indisponível, você pode utilizar o Nmap, que faz isso para você. Alguns administradores podem não gostar muito de alguém varrendo a rede local e cutucando de porta em porta do servidor para saber se alguma está aberta. Existem ambientes com defesas contra esse tipo de ação, por ser utilizada por pessoas com más intenções querendo invadir um servidor. Esteja avisado!
Debian shell: retorno do comando nmap
$ nmap 159.89.241.130
Starting Nmap 7.93 ( https://nmap.org ) at 2024-12-11 15:10 -03
Nmap scan report for 159.89.241.130
Host is up (0.12s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
3/tcp    filtered compressnet
22/tcp   open     ssh
5432/tcp open     postgresql

Nmap done: 1 IP address (1 host up) scanned in 14.55 seconds
  • Telnet: é um protocolo desenvolvido na década de 1960, que embora ninguém mais pense em usar com a sua finalidade original, é utilizado por algumas pessoas  para testar conexões entre computadores, por ser amplamente conhecido e fácil de usar, estando disponível em qualquer sistema operacional. O comando telnet <ip-do-servidor> 5432 pode ser aplicado para testar se a porta está acessível. Se a conexão for bem-sucedida, você verá uma mensagem confirmando a conexão (antes, pode ser necessário instalar o pacote do Telnet). Provavelmente, o Telnet não estará instalado por padrão. Você também pode utilizar as próximas opções da nossa lista. Recomendamos!
Debian shell: retorno do comando telnet
$ telnet 159.89.241.130 5432
Trying 159.89.241.130...
Connected to 159.89.241.130.
Escape character is '^]'.
  • Netcat: similar ao Telnet, o comando nc -vz <ip-do-servidor> 5432 pode ser usado para verificar se a porta está aberta e acessível (também pode ser necessário instalar o pacote antes):
Debian shell: retorno do comando netcat
$ nc -vz 159.89.241.130 5432
Connection to 159.89.241.130 5432 port [tcp/postgresql] succeeded!

Não tenho rota para o servidor, pode ser um firewall no caminho

Se você sabe que o PostgreSQL está no ar, sabe em qual porta ele roda, usou um dos aplicativos citados para tentar verificar e mesmo assim não conseguiu chegar ao banco de dados, você provavelmente está sendo bloqueado por alguma regra de segurança do firewall.

Para verificar se o firewall local está ativo, podemos utilizar os seguintes comandos:

  • Para sistemas baseados em Debian/Ubuntu (usando UFW): sudo ufw status
  • Para sistemas baseados em Red Hat/CentOS (usando firewalld): sudo firewall-cmd --list-all


Aqui, a resposta pode ser firewall ativo ou não (active/inactive), e caso não esteja ativo, é improvável que ele cause alguma dificuldade de conexão. Se estiver ativo, podemos ainda checar se a porta do lado do servidor está aberta com os comandos a seguir:

  • Para sistemas baseados em Debian/Ubuntu (usando UFW):
    • Verificar a porta: sudo ufw status | grep 5432
  • Abrir a porta (se necessário): sudo ufw allow 5432/tcp

  • Para sistemas baseados em Red Hat/CentOS (usando firewalld):
    • Verificar: sudo firewall-cmd --list-ports | grep 5432
  • Abrir:
    sudo firewall-cmd --zone=public --add-port=5432/tcp --permanent
    sudo firewall-cmd --reload


Geralmente, não é necessário abrir portas específicas no firewall do cliente para conexões de saída. No entanto, se houver restrições, você pode precisar permitir conexões de saída para a porta 5432:

  • Para sistemas baseados em Debian/Ubuntu (usando UFW):
    sudo ufw allow out to any port 5432
  • Para sistemas baseados em Red Hat/CentOS (usando firewalld):
    sudo firewall-cmd --zone=public --add-port=5432/tcp --permanent
    sudo firewall-cmd --reload

E se o firewall não for local?

Vejamos:

  • O banco de dados está no ar;
  • Você sabe a porta correta;
  • Não existe nenhum firewall local ativo;
  • Ainda assim você não tem rota até o banco de dados.


Nesse momento, pode haver algum problema de rota, firewall etc. no meio do caminho. Você vai precisar conversar com o administrador de redes para ajudar nisso. Foge um pouco do escopo deste artigo entrar nesses meandros, pois existem muitas variáveis que dependem da arquitetura da rede, da segurança, do uso de VPN etc. 

O pg_hba.conf e o postgresql.conf estão configurados devidamente?

Conforme abordado no último artigo, o pg_hba.conf é o arquivo que dita as regras de autenticação do banco de dados, o que significa que a sua configuração correta impacta totalmente em uma conexão bem-sucedida. Caso tenha algum problema ou impedimento nessas configurações, você deverá receber um retorno como este:

psql shell: mensagem de erro no pg_hba.conf
psql: error: connection to server at "192.168.0.1" (::1), port 5432 failed: FATAL:  no pg_hba.conf entry for host "::1", user "postgres", database "postgres", SSL off


Certificar-se de que o seu usuário e IP têm permissão de conexão no banco de dados correto no arquivo é um passo fundamental em caso de erro no acesso remoto, bem como seu usuário (ou grupo de usuários).

Além disso, no arquivo de configurações do PostgreSQL, o postgresql.conf, existe um parâmetro que é imprescindível para permitir conexões externas, o listen_addresses, que por padrão vem com o valor de localhost, significando que o servidor escuta do endereço local. É possível fazer restrições aqui, para maior segurança, podendo permitir IPs específicos, por exemplo:

postgresql.conf: definindo valores para parâmetro listen_adresses
listen_addresses = '192.168.1.100, localhost'

Então é necessário ter certeza de que está autorizado nas regras de ambos os arquivos.
Caso haja algum ajuste para permitir a conexão, o PostgreSQL deverá ser recarregado ou reiniciado, para que as novas configurações sejam aplicadas. Isso pode ser feito com os seguintes comandos:

  • Para recarregar (sem interromper conexões atuais, o suficiente para mudanças no pg_hba.conf): systemctl reload postgresql
  • Para reiniciar o banco (caso tenha alterado o parâmetro listen_addresses): systemctl restart postgresql


O banco de dados existe?

Outra possível causa de falha de conexão é o banco de dados que você está tentando acessar não existir. Nessa situação, temos a seguinte mensagem de erro:

psql shell: mensagem de erro sobre banco de dados inexistente
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  database "banco1" does not exist


Caso tenha esse retorno e queira verificar se digitou corretamente o nome do banco de dados ou se ele está presente no servidor apontado, você pode verificar isso localmente com um terminal psql (como usuário administrador) e listar todos os bancos de dados disponíveis com o comando \l. Esse e outros comandos básicos do psql podem ser relembrados no artigo Utilização do psql.

Esta é a nossa listagem de bancos:

psql shell: listando todos os bancos de dados
postgres=# \l
                                                    List of databases
    Name    |  Owner   | Encoding | Locale Provider | Collate |  Ctype  | ICU Locale | ICU Rules |   Access privileges
------------+----------+----------+-----------------+---------+---------+------------+-----------+-----------------------
 aplicacao1 | postgres | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           |
 postgres   | postgres | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           |
 template0  | postgres | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           | =c/postgres          +
            |          |          |                 |         |         |            |           | postgres=CTc/postgres
 template1  | postgres | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           | =c/postgres          +
            |          |          |                 |         |         |            |           | postgres=CTc/postgres
(4 rows)


Se o banco de dados que você está tentando acessar estiver listado, ele existe. Caso contrário, se necessário, você pode criá-lo com o comando CREATE DATABASE:

psql shell: comando para criar nova base de dados
CREATE DATABASE <nome_do_banco> OWNER <nome_do_usuario>;

Meu usuário existe?

Outra questão fundamental na hora de resolver problemas de conexão é garantir que o usuário que está tentando se conectar ao PostgreSQL realmente existe no banco de dados. Se o usuário não estiver devidamente criado ou não tiver as permissões corretas, a conexão falhará.

A mensagem de erro para essa ocasião é:

psql shell: mensagem de erro sobre usuário inexistente
psql: error: FATAL: role "my_username" does not exist

Para verificar se o usuário existe, você pode utilizar o comando SQL \du no terminal interativo psql, que lista todos os usuários (também chamados de “roles” no PostgreSQL):

psql shell: consultando todos os usuários
postgres=# \du
                                List of roles
    Role name    |                         Attributes
-----------------+------------------------------------------------------------
 admin_pagila    | Create role
 ana             |
 app1_admin      | Create role, Create DB
 app1_user1      |
 app1_user2      |
 app2_admin      | Create role, Create DB
 app2_user1      |
 app2_user2      |
 dba             | Superuser
 fabio           |
 ludmila         |
 meu_usuario     | Superuser
 postgres        | Superuser, Create role, Create DB, Replication, Bypass RLS


Se o seu usuário estiver nessa lista, ele existe. Caso não esteja, você precisará criá-lo com o comando CREATE ROLE, que pode ser visto com detalhes no artigo Utilização de SQL básico:

psql shell: comando para criar um novo usuário, com permissão de login e definição de senha
CREATE ROLE <nome_do_usuário_ou_grupo> LOGIN PASSWORD '<senha>';

Não se esqueça de garantir as permissões necessárias para que esse usuário possa se conectar.

Eu tenho permissão para me conectar?

Mesmo se a configuração no pg_hba.conf e postgresql.conf estiver correta, o seu usuário existir e o banco de dados também, você ainda poderá encontrar outros problemas. É possível que o usuário não tenha privilégios suficientes para realizar a conexão ou para acessar objetos específicos dentro do banco. Se for o caso de não haver permissão para login, você deverá ver uma mensagem parecida com esta:

psql shell: mensagem de erro relacionada a falta de permissão de login
psql: error: connection to server on at 192.168.0.10 failed: FATAL:  role "fabio" is not permitted to log in


Isso pode ser facilmente resolvido concedendo esse privilégio com o comando:

ALTER ROLE <usuário ou grupo> WITH LOGIN;

Agora, se houver falta de permissão para se conectar com o banco, essa deverá ser a mensagem de erro visualizada:

psql shell: mensagem de erro relacionada a falta de permissão de conexão com o banco
psql: error: connection to server at 192.168.0.10, port 5432 failed: FATAL: permission denied for database "postgres"
DETAIL: User does not have CONNECT privilege.


Podemos resolver isso com o comando GRANT, que vimos detalhadamente no artigo O mínimo sobre segurança que você precisa saber. Em um resumo rápido, existe o privilégio CONNECT, que especificamente trata de permissão de conexão com o banco, que pode ser fornecido com o seguinte comando:

GRANT CONNECT ON DATABASE <nome do banco> TO <usuario>;

Isso e muito mais pode ser visto de forma detalhada no artigo citado.

A senha está correta?

Mesmo que o banco de dados e o usuário estejam configurados corretamente, uma senha incorreta pode ser um obstáculo. Se você suspeita que a senha do seu usuário está errada ou precisa ser redefinida, há algumas formas de corrigir isso. Este é o erro para esse caso:

psql shell: mensagem de erro para senha incorreta
psql: error: connection to server at "localhost" (::1), port 5432 failed: FATAL:  password authentication failed for user "user3"


No PostgreSQL, não há um comando direto para visualizar senhas, já que elas são armazenadas de forma segura. No entanto, se o arquivo pg_hba.conf estiver configurado para um método de autenticação que exija senha (como md5 ou scram-sha-256), a senha deve estar correta para que a conexão seja estabelecida.

Caso precise alterar a senha de um usuário, você pode fazê-lo através do psql, com um usuário com permissões de superusuário, executando o comando ALTER USER para realizar a alteração:

psql shell: comando para alterar a senha de um usuário
ALTER USER <nome_do_usuario> WITH PASSWORD '<nova_senha>';

Agora, a nova senha será usada nas próximas tentativas de conexão. Se o problema estava sendo causado por uma senha incorreta, ele será resolvido.

Conclusão

Quando você instala o PostgreSQL pela primeira vez em um servidor, é fundamental configurar o postgresql.conf e o pg_hba.conf corretamente, uma vez que a instalação padrão não vem configurada para permitir conexões remotas. Depois disso, você talvez precise criar novos usuários, bancos de dados, senhas etc. Por fim, a rede onde você roda o PostgreSQL deve permitir o acesso remoto ao servidor naquela porta. 

Além disso, muitas coisas podem dar errado nesse caminho. Não caia na tentação de burlar os mecanismos de segurança! Se você entender o significado de cada mensagem de erro que apresentamos aqui, rapidamente você conseguirá chegar lá. Mas lembre-se: sempre verifique o que a mensagem de erro diz, pois isso será fundamental para entender onde e como agir para resolver o problema. 

The post Meu Postgres não conecta: troubleshooting de conexões first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/12/16/meu-postgres-nao-conecta-troubleshooting-de-conexoes/feed/ 0 8554 Savepoint no PGConf.Brasil 2024 https://savepoint.blog.br/2024/11/11/savepoint-no-pgconf-brasil-2024/ https://savepoint.blog.br/2024/11/11/savepoint-no-pgconf-brasil-2024/#respond Mon, 11 Nov 2024 12:39:00 +0000 https://savepoint.blog.br/?p=13937 Nos dias 7 e 8 de novembro de 2024, aconteceu em Belo Horizonte–MG a PGConf.Brasil 2024, o maior evento do PostgreSQL da América Latina. Foram dois dias de palestras em 2 auditórios simultâneos. Foram dois dias de palestras, networking, troca de experiências e muito conteúdo técnico sobre o banco de dados open-source que mais cresce

The post Savepoint no PGConf.Brasil 2024 first appeared on Savepoint.

]]> Nos dias 7 e 8 de novembro de 2024, aconteceu em Belo Horizonte–MG a PGConf.Brasil 2024, o maior evento do PostgreSQL da América Latina. Foram dois dias de palestras em 2 auditórios simultâneos. Foram dois dias de palestras, networking, troca de experiências e muito conteúdo técnico sobre o banco de dados open-source que mais cresce no mundo. E para deixar tudo ainda melhor, a Savepoint teve a oportunidade de contribuir diretamente na organização, patrocínio e com duas palestras técnicas.

Palestra 1 – Encontrando uma agulha no JSON

  • Diferenças entre json e jsonb e por que jsonb é melhor para buscas
  • Principais operadores e funções para extrair dados de JSON no PostgreSQL
  • Como filtrar dados dentro de JSON usando operadores como @>, ?, ?|, ?& e JSONPath
  • Demonstração de consultas práticas
  • Importância de índices GIN em colunas jsonb

Palestra 2: Arquitetura e Estruturas Internas do PostgreSQL

  • Processos, diretórios e arquivos típicos do PostgreSQL
  • Como visualizar metadados físicos e lógicos 
  • Automatização de tarefas administrativas
  • Caso de uso: “como achar o arquivo em disco que está corrompido”
  • Visualizar privilégios

Participar do PGConf.Brasil é sempre uma aventura: palestras interessantes, muito networking, cervejas e histórias para se contar e ouvir. Em 2024 o evento foi sensacional e este foi o primeiro evento organizado 100% pela comunidade após um hiato de vários anos. Pela foto abaixo você pode ter uma ideia de que o evento bombou, foi um enorme sucesso. Estamos orgulhosos de participar de mais um evento tão relevante para a comunidade de PostgreSQL do Brasil e do mundo. Agradecemos a todos que se empenharam na organização, que patrocinaram o evento, que compartilharam conhecimento no melhor espírito do Software Livre, e claro, a todos os que vieram prestigiar o evento.

Esperamos reencontrá-los em 2025!

The post Savepoint no PGConf.Brasil 2024 first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/11/11/savepoint-no-pgconf-brasil-2024/feed/ 0 13937 pg_hba.conf https://savepoint.blog.br/2024/10/16/pg_hba-conf/ https://savepoint.blog.br/2024/10/16/pg_hba-conf/#respond Wed, 16 Oct 2024 17:12:28 +0000 https://savepoint.blog.br/?p=8535 Aprenda a configurar o arquivo pg_hba.conf no PostgreSQL para controlar acessos, definir métodos de autenticação e garantir a segurança do seu banco de dados.

The post pg_hba.conf first appeared on Savepoint.

]]> Introdução

O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação e acesso ao banco de dados, determinando quem pode se conectar, de onde e como essas conexões são autenticadas. Neste artigo, exploraremos as diversas opções de configuração disponíveis no pg_hba.conf, desde os métodos de autenticação até a especificação de IPs, usuários e grupos. Também abordaremos os modelos de autenticação mais comuns, como TRUST, password, md5 e scram-sha-256, além de métodos específicos como ident e peer. Ao final, você será capaz de configurar esse arquivo para garantir um ambiente seguro e eficiente para suas aplicações.

Roteiro:

  • Modelo de autenticação
    • TYPE (tipos de conexão)
      • local
      • host
      • hostssl
    • DATABASE (banco de dados)
    • USER (usuários ou grupos de usuários)
    • ADDRESS (endereços)
    • METHOD (método)
    • OPTIONS (opções)
    • Exemplos
    • Considerações importantes
  • Ident file

Modelo de autenticação

O modelo de autenticação define como a autenticação será realizada e gerenciada, verificando a identidade dos usuários do banco de dados de diferentes formas. No PostgreSQL, o principal modelo é baseado no arquivo pg_hba.conf. Ele pode estar localizado em diferentes locais, dependendo do seu ambiente:

  • /var/lib/pgsql/<versão>/data/ nos ambientes Linux Red Hat e derivados (como CentOS);
  • /etc/postgresql/<versão>/<cluster>/pg_hba.conf nos ambientes Linux Debian e derivados (como Ubuntu);
  • C:\Program Files\PostgreSQL\<versão>\data\pg_hba.conf em Windows;
  • Se você criou o seu cluster de dados em um diretório específico e não está utilizando o Linux Debian, o pg_hba.conf deverá estar nesse diretório, que chamamos de $PGDATA (que é a variável de ambiente que contém essa localização).

O pg_hba.conf tem como características regras específicas que suportam vários métodos de autenticação, que podem ainda ser aplicados de forma seletiva.

A estrutura básica do pg_hba.conf é (em cada linha):

Arquivo pg_hba.conf: estrutura padrão
TYPE  DATABASE  USER  ADDRESS  METHOD [OPTIONS]

Sendo que  TYPE se refere ao tipo de conexão, DATABASE, ao banco de dados  ao qual a regra se aplica, USER, a usuário ou grupo de usuários, ADDRESS, ao endereço IP ou intervalo (range) de IPs, METHOD  ao método de autenticação, e OPTIONS a algumas opções que podem existir de acordo com o método escolhido, respectivamente.
Além disso, no pg_hba.conf, as linhas de regras são divididas por seções, sendo uma para conexões locais, outra para IPv4, outra para IPv6 e mais uma para replicações.
Apenas para lembrar, é tradição no universo Linux/Unix (de onde o PostgreSQL surgiu) usar o caractere ‘#‘ para marcar comentários no início da linha.

Confira um exemplo de conteúdo do pg_hba.conf:

Arquivo pg_hba.conf: exemplo de conteúdo
# DO NOT DISABLE!
# If you change this first entry you will need to make sure that the
# database superuser can access the database using some other method.
# Noninteractive access to all databases is required during automatic
# maintenance (custom daily cronjobs, replication, and similar tasks).
#
# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

TYPE (tipos de conexão)

O PostgreSQL suporta diversos tipos de conexão, cada um com suas próprias características e casos de uso, que determinam como os clientes podem se conectar ao servidor de banco de dados. Entre os principais e mais utilizados, estão:

  • local: conexões feitas através de Unix sockets no mesmo sistema onde o servidor PostgreSQL está rodando, ou seja, conexões locais, portanto, não sendo necessário passar a informação da coluna ADDRESS;
  • host: conexões TCP/IP tanto locais quanto remotas não criptografadas, ou seja, sem criptografia SSL;
  • hostssl: para conexões TCP/IP seguras, ou seja, criptografadas via SSL. É o que recomendamos utilizar e teremos um artigo especial dedicado a ele.

Existem ainda as opções mais incomuns: hostnossl (sem SSL), hostgssenc (com criptografia GSSAPI) e hostnogssenc (sem criptografia GSSAPI).

DATABASE (banco de dados)

Para isolar as regras de autenticação, deve-se especificar a qual banco a linha com as instruções se refere, sendo possível utilizar all para aplicação em todos os bancos. Além disso, há a opção samerole, que é particularmente útil em ambientes com multitenancy, onde diferentes usuários ou grupos precisam acessar seus próprios bancos de dados sem interferir em outros. Com samerole, o Postgres permite que um usuário se conecte apenas a bancos de dados cujo nome coincide com uma role (grupo) da qual ele é membro. Assim, é possível definir que cada usuário tenha acesso apenas aos bancos relacionados ao seu papel, reforçando a segurança e o isolamento entre bancos de dados de diferentes usuários.

USER (usuários ou grupos de usuários)

É possível especificar usuários individuais do PostgreSQL no pg_hba.conf pelo campo USER ou, ainda, usar all para corresponder a todos os usuários, assim como para os bancos de dados.
Podemos também indicar grupos de usuários com o prefixo +, por exemplo, +admins, o que torna fácil o processo de gerenciar permissões de vários usuários simultaneamente. É importante lembrar que não são grupos do sistema operacional, mas, sim, roles definidas no PostgreSQL.
No contexto do PostgreSQL, um “grupo de usuários” é, na verdade, uma role à qual outras roles (usuários) recebem grants (privilégios). Isso permite agrupar vários usuários sob uma mesma role, facilitando o gerenciamento de permissões e acessos em ambientes mais complexos.
Além disso, também podemos informar nomes de usuário como expressões regulares, indicando com o prefixo /, e também é possível gerenciar os usuários, com nome ou expressões regulares, em um arquivo separado, que deve ser mencionado com o prefixo @. Há ainda o caso de replicação, que trata-se de uma conexão usada para sincronizar dados entre servidores, e que deve ser indicada nessa coluna com a palavra-chave replication.

ADDRESS (endereços)

O campo ADDRESS no pg_hba.conf permite especificar quais endereços podem se conectar:

  • Subnet: permite conexões de uma faixa de IPs, por exemplo:
    • 192.168.1.1/32 ou fe80::7a31:c1ff:fa34:9eb3/128 – permite apenas um IP específico;
    • 127.0.0.1 ou ::1/128 - (ipv6) – permite apenas conexões locais;
    • 192.168.1.0/24 – permite todos os IPs classe C, de 192.168.1.0 a 192.168.1.255;
    • 192.168.0.0/16 – permite todos os IPs classe B, de 192.168.0.0 a 192.168.255.255;
    • 192.0.0.0/8 – permite todos os IPs classe A, de 192.0.0.0 a 192.255.255.255;
    • 0.0.0.0/0 ou ::0/0 (ipv6) – permite qualquer IP (não recomendamos usar esta configuração em ambiente de produção).
  • IP-mask: permite a definição de uma faixa de IPs, semelhante a anterior, mas em vez de usar a subnet, colocamos o IP e a máscara de IPs:
    • 192.168.1.0 ou 255.255.255.0 – permite todos os IPs classe C, de 192.168.1.0 a 192.168.1.255;
    • 192.168.0.0 ou 255.255.0.0 – permite todos os IPs classe B, de 192.168.0.0 a 192.168.255.255.
  • Hostname: além de endereços IP, podemos utilizar um hostname, no qual o PostgreSQL realiza várias verificações para garantir a correspondência entre o hostname especificado e o cliente. Lembrando que qualquer lentidão na resolução de nomes pelo DNS irá provocar uma lentidão no processo de conexão em si.
    • Hostname específico: é só colocá-lo, como exemplo.com;
    • Subdomínios: necessário colocar o prefixo “.” antes do hostname, e assim qualquer endereço com esse subdomínio será autorizado, como em .exemplo.com permitiria conexão de sub.exemplo.com, app.exemplo.com etc. (mas não o próprio exemplo.com).
  • Também podemos utilizar all para permitir a conexão de qualquer IP, samehost para permitir qualquer IP do próprio servidor e samenet para permitir qualquer IP em qualquer sub-rede à qual o servidor esteja conectado.

METHOD (método)

Os métodos de autenticação no PostgreSQL são as diferentes maneiras que o banco de dados usa para verificar e realizar a autenticação, indo desde a exigência de senhas até a confiança total e permissão absoluta. Os principais são:

  • trust: permite conexões sem nenhuma autenticação, ou seja, se o seu IP for contemplado na lista de endereços autorizados, não será necessário fornecer senhas, por isso é adequado apenas para ambiente de testes e desenvolvimento local ou com redes totalmente isoladas e confiáveis endereçando apenas um IP local ou um IP único confiável;
  • password / md5 / scram-sha-256: é exigida uma senha no momento da conexão, que varia entre essas três opções com diferentes níveis de segurança:
    • password: senha em texto simples, sem criptografia durante a transmissão pela rede;
    • md5: usa hash MD5 para criptografar a senha durante a transmissão, o que torna o processo um pouco mais seguro, mas seu uso está sendo descontinuado em favor do próximo método considerado mais seguro;
    • scram-sha-256: usa o método SCRAM (Salted Challenge Response Authentication Mechanism) como hash SHA-256, o que o torna a opção baseada em senha mais segura, já que seu protocolo de autenticação não transmite a senha real, e sua criptografia é considerada muito forte.

É importante saber que o tipo de encriptação padrão da senha (md5 ou scram-sha-256) é definido pelo parâmetro password_encryption, que significa que todos os seus usuários criados com senha, ou com a senha alterada, vão tê-la com a criptografia apontada por esse parâmetro. O nosso padrão é scram-sha-256, porém fizemos alterações para exemplificar diferentes cenários;

  • ident: usa o serviço de identificação do sistema operacional (Ident ou identd) para autenticar, confiando na informação que o SO passa, por isso requer que o cliente esteja em um servidor ident (mais comum em ambientes Linux, em que o serviço Ident já vem ativado por padrão); 
  • peer: confia nas informações de usuários do SO local, ou seja, diferente do ident, não precisa de um serviço externo para isso e só funciona para redes locais. É esse o método de autenticação que costumamos usar para acessar o psql com usuário postgres (estando conectado ao usuário postgres do SO);
  • Além desses, o PostgreSQL suporta vários outros métodos, incluindo:
    • reject: rejeita todas as conexões, podendo ser usado para filtrar e impedir grupos; 
    • sspi: autenticação nativa do Windows;
    • ldap: para autenticação via servidores LDAP;
    • radius: para autenticação via servidores RADIUS;
    • cert: usa certificados SSL do cliente para autenticação.

OPTIONS (opções)

Além de todas as configurações que vimos, é possível ainda inserir mais opções para o método de autenticação, que devem ter o formato de nome=valor, e servem para especificar opções adicionais para o método escolhido. Algumas delas são:

  • clientcert: além das opções específicas de cada método de autenticação, existe essa opção geral, que pode ser usada em qualquer entrada do tipo hostssl. Essa opção tem dois valores possíveis: verify-ca e verify-full, sendo que o primeiro exige que o cliente apresente um certificado SSL válido e confiável, e o segundo, além de exigir um certificado válido, também verifica se o Common Name (CN) no certificado do cliente corresponde ao nome de usuário ou a um mapeamento aplicável. Isso fornece um nível extra de segurança;
  • clientname: quando você está usando autenticação com certificado de cliente (usando o método cert ou a opção clientcert), você pode usar essa opção para especificar qual parte das credenciais do certificado do cliente deve ser comparada com o nome de usuário, sendo as subopções clientname=CN, em que o nome de usuário será comparado com o Common Name (CN) do certificado, e clientname=DN, em que o nome de usuário será comparado com o Distinguished Name (DN) completo do certificado, conforme o formato RFC 2253;
  • include, include_if_exists e include_dir: essas opções permitem definir suas regras de autenticação em um arquivo separado, sendo necessário passar o local do arquivo entre aspas simples. A diferença entre essas opções é que a primeira apenas checa o local do arquivo informado e tenta substituir as regras, a segunda faz isso apenas se o arquivo existir, caso contrário será exibida uma mensagem indicando que o arquivo não foi lido, e a última reconhece todos os arquivos de um diretório.

Exemplos

Conexão local de todos os usuários com peer

Arquivo pg_hba.conf: exemplo de configuração de conexão
local		all		all		peer

Este é o caso que possibilita o acesso ao psql pelo usuário postgres do SO, pulando a etapa de fornecimento de senha (acessamos o banco também chamado postgres):

Debian shell: exemplo de acesso ao psql sem inserção de senha
postgresdebian:~$ psql -U postgres -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=#

Além desse usuário, poderíamos repetir esse tipo de acesso com qualquer outro usuário que existisse tanto no banco de dados quanto no SO, claro, com o mesmo nome nos dois lugares:

Debian shell: acessando o psql sem inserção de senha
ludmila@debian:~$ psql -U ludmila -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=>

Além disso, conforme explicado, podemos aplicar as regras por banco de dados, então, se fosse especificado o método de conexão peer apenas para o banco postgres, não seria possível acessar sem senha em outros bancos.

Conexão host com IP específico e senha sem criptografia

Arquivo pg_hba.conf: exemplo de configuração de conexão
host		all		all		192.168.1.10/32		password

Como você pode notar, foi solicitada a senha para acessar o banco de outro IP:

Debian shell: acessando o psql com senha
fabio@debian-2:~$ psql -h 64.23.248.23 -p 5432 -U fabio -d postgres
Password for user fabio:
psql (16.4 (Debian 16.4-1.pgdg120+1), server 16.2 (Debian 16.2-1.pgdg120+2))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Mas, se a tentativa de acessar fosse feita da rede local com o mesmo usuário fabio, considerando que temos no mesmo arquivo a linha de regras exemplificadas anteriormente, este seria o resultado:

Debian shell: acessando o psql sem inserção de senha (com peer)_
fabio@debian:~$ psql -U fabio -d postgres
psql (16.2 (Debian 16.2-1.pgdg120+2))
Type "help" for help.

postgres=>

Conexão host para grupo de usuários com IP específico e trust

Arquivo pg_hba.conf: exemplo de configuração de conexão
host	    all	 +groupname	      192.168.1.20/32	trust

Esse cenário permite que os usuários pertencentes ao grupo editors se conectem de um IP específico sem a necessidade de informar senha. No nosso caso, o usuário ana está neste grupo:

Debian shell: acessando o psql sem inserção de senha
ana@debian-2:~$ psql -h 64.23.248.23 -p 5432 -U ana -d postgres
psql (16.4 (Debian 16.4-1.pgdg120+1), server 16.2 (Debian 16.2-1.pgdg120+2))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=>

Conexão host para bancos de dados com o mesmo proprietário (samerole)

Arquivo pg_hba.conf: exemplo de configuração de conexão
host    samerole    all     192.168.1.0/24    md5

Com essa configuração, se o usuário user1 tentar acessar o banco de dados que ele mesmo possui, a senha será solicitada, porém, se ele tentar acessar um banco que pertence a outro usuário, como user2, ele não conseguirá, pois a regra só se aplica aos bancos que possuem o mesmo proprietário.

Considerações importantes

  • As regras são aplicadas na ordem em que aparecem no arquivo;
  • As primeiras regras têm prioridade, então coloque as mais restritivas no início;
  • Após modificar o pg_hba.conf, recarregue as configurações com o comando systemctl reload postgresql;
  • Se não funcionar, deve-se checar os logs do banco ou então consultar a tabela pg_hba_file_rule do catálogo para entender onde está o erro dentro do pg_hba.conf ;
Debian shell: logs do banco de dados exibindo erro no pg_hba.conf
$ tail postgresql-16-main.log
2024-11-13 17:29:31.029 UTC [141035] LOG:  received SIGHUP, reloading configuration files
2024-11-13 17:29:31.037 UTC [141035] LOG:  invalid connection type "hoost"
2024-11-13 17:29:31.037 UTC [141035] CONTEXT:  line 126 of configuration file "/etc/postgresql/16/main/pg_hba.conf"
2024-11-13 17:29:31.037 UTC [141035] LOG:  /etc/postgresql/16/main/pg_hba.conf was not reloaded
Debian shell: consulta na tabela pg_hba_file_rules com registro de erro
postgres=# select * from pg_hba_file_rules ;
 rule_number |              file_name              | line_number | type  |   database    | user_name  |  address  |                 netmask                 |  auth_method  | options |              error
-------------+-------------------------------------+-------------+-------+---------------+------------+-----------+-----------------------------------------+---------------+---------+---------------------------------
           1 | /etc/postgresql/16/main/pg_hba.conf |         118 | local | {all}         | {postgres} |           |                                         | peer          |         |
           2 | /etc/postgresql/16/main/pg_hba.conf |         125 | local | {all}         | {all}      |           |                                         | trust         |         |
             | /etc/postgresql/16/main/pg_hba.conf |         126 |       |               |            |           |                                         |               |         | invalid connection type "hoost"
           3 | /etc/postgresql/16/main/pg_hba.conf |         128 | host  | {all}         | {all}      | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         |
           4 | /etc/postgresql/16/main/pg_hba.conf |         131 | local | {replication} | {all}      |           |                                         | peer          |         |
           5 | /etc/postgresql/16/main/pg_hba.conf |         132 | host  | {replication} | {all}      | 127.0.0.1 | 255.255.255.255                         | scram-sha-256 |         |
           6 | /etc/postgresql/16/main/pg_hba.conf |         133 | host  | {replication} | {all}      | ::1       | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | scram-sha-256 |         |
(7 rows)
  • Teste as configurações em um ambiente de desenvolvimento antes de aplicá-las em produção.

Ident file

O ident file é um arquivo utilizado pelo PostgreSQL para mapear nomes de usuários do sistema operacional para nomes de usuários do banco de dados. Ele é útil quando você usa o método de autenticação ident, que verifica a identidade do usuário que está tentando se conectar ao banco de dados com base no nome de usuário do sistema operacional.

Para fazer essa autenticação baseada nos usuários do SO, o PostgreSQL consulta o ident file para mapear o nome de usuário do SO para o nome de usuário do banco de dados.

Esse arquivo geralmente é chamado pg_ident.conf e está localizado no mesmo diretório que o arquivo pg_hba.conf (/etc/postgresql/<versão>/<cluster>/pg_hba.conf para sistemas de base Linux). 

Seu conteúdo é simples, com cada linha contendo três colunas:

  1. Mapa de identidade: nome de um grupo de mapeamento definido;
  2. Nome de usuário do SO: nome do usuário no sistema operacional;
  3. Nome de usuário do banco: nome do usuário no banco de dados que corresponde ao usuário do SO. 

Após feita a configuração do arquivo pg_ident.conf, para utilizá-lo basta selecionar como método de autenticação no pg_hba.conf o ident e, então, como última opção da linha de regra, informar o nome do mapa definido no ident file. Exemplo:

Arquivo pg_ident.conf: exemplo de conteúdo
mymap   seu_usuario_os   seu_usuario_db

Nesse caso, mymap é o nome do seu mapeamento, seu_usuario_os é o nome do usuário no sistema operacional, e seu_usuario_db é o nome do usuário no banco de dados.

Para aplicar isso no pg_hba.conf, poderíamos incluir essa linha nas regras do arquivo:

Arquivo pg_hba.con:f: exemplo de configuração com ident file
host   all	all   192.168.1.10/32   ident   mymap

Sendo que ident é o método escolhido, e a opção extra mymap refere-se ao mapeamento que queremos utilizar (considerando que podemos mapear vários usuários no ident file).

Conclusão

O pg_hba.conf é uma peça fundamental na definição de políticas de acesso ao banco de dados. Ele é relativamente simples de configurar e tem uma sintaxe bastante intuitiva se compararmos com outros bancos de dados por aí. No entanto, conhecer as opções disponíveis é uma condição indispensável para administrar um ambiente de produção de forma minimamente segura. 

Por padrão, as instalações do PostgreSQL vêm apenas habilitadas para permitir conexões locais, o que gera uma certa frustração em novatos. Algumas pessoas, na pressa de colocar o banco de dados no ar, acabam utilizando o método TRUST ou colocando faixas de IPs abertas para o mundo todo com 0.0.0.0/0, o que deixa o servidor completamente vulnerável a ataques. Na mesma linha, você deve utilizar o ALL para usuários, e nomes de bancos de dados devem ser utilizados com moderação. Aqui vale a regra do “menor privilégio possível”. Você deve sempre colocar as regras mais restritas possíveis para permitir que as aplicações e os usuários acessem o banco de dados com segurança. 

Outra tendência forte é utilizar conexões com criptografia SSL para todas as conexões que não forem locais, evitando possíveis ataques de pessoas que ficam escutando o tráfego da sua rede. Isso é tão importante hoje que escrevemos um artigo só sobre isso, que você poderá conferir mais adiante. Portanto, seja cuidadoso e crie regras com prudência. Lembre-se, você pode alterá-las e adicionar quantas linhas forem necessárias depois; e recarregar o arquivo pg_hba.conf sem precisar reiniciar o serviço do PostgreSQL, apenas dando um RELOAD.

The post pg_hba.conf first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/10/16/pg_hba-conf/feed/ 0 8535 Tuning de SO (no Linux) https://savepoint.blog.br/2024/10/09/tuning-de-so-no-linux/ https://savepoint.blog.br/2024/10/09/tuning-de-so-no-linux/#respond Wed, 09 Oct 2024 15:20:35 +0000 https://savepoint.blog.br/?p=8528 Aprenda técnicas de Tuning no Linux para otimizar o PostgreSQL: ajustes em systemctl, sistemas de arquivos, sysctl.conf e mais para desempenho superior.

The post Tuning de SO (no Linux) first appeared on Savepoint.

]]> Introdução

Tuning refere-se ao processo de ajustar e otimizar o desempenho de um sistema, software ou aplicação. A otimização do sistema operacional é uma etapa crucial para maximizar o desempenho e a eficiência do banco de dados PostgreSQL. Por meio do ajuste de algumas configurações do Linux, é possível melhorar a capacidade de resposta, a estabilidade e a escalabilidade dos serviços. 

Este artigo vai explorar áreas fundamentais para o tuning de sistemas Linux, focando em aspectos-chave como gerenciamento de serviços, sistemas de arquivos, particionamento e parâmetros de configuração do kernel, que impactam diretamente no uso do PostgreSQL.

Roteiro:

  • Systemctl
  • Sistemas de arquivos
  • Particionamento
  • Montagem de discos
  • sysctl.conf 
  • Huge pages
  • Transparent Huge Pages (THP)
  • Limits

Systemctl 

O systemctl é uma ferramenta poderosa para o gerenciamento de serviços no Linux, sendo parte integrante do systemd, o sistema de inicialização e gerenciamento de processos mais utilizado nas distribuições Linux modernas. 

Para DBAs que gerenciam o PostgreSQL, entender como configurar o serviço para iniciar e parar automaticamente durante o boot é essencial para garantir a disponibilidade contínua do banco de dados.

Habilitando a inicialização automática

Para garantir que o serviço do PostgreSQL seja iniciado automaticamente após a reinicialização do sistema, utilizamos o comando systemctl enable. Esse comando cria links simbólicos nos diretórios apropriados, configurando o serviço para ser iniciado durante o processo de boot.

Debian shell: habilitando inicialização automática
sudo systemctl enable postgresql

Se por algum motivo você precisar desativar essa configuração, impedindo que o serviço inicie automaticamente, o comando systemctl disable pode ser utilizado:

Debian shell: desabilitando inicialização automática
sudo systemctl disable postgresql

Iniciando e parando serviços manualmente

Além da configuração automática, também é importante saber como iniciar ou parar manualmente o serviço do PostgreSQL. Para iniciá-lo manualmente, você pode usar o seguinte comando:

Debian shell: iniciando a inicialização aumtomática manualmente
sudo systemctl start postgresql

Já se precisar parar o serviço, o comando é:

Debian shell: parando a inicialização aumtomática manualmente
sudo systemctl stop postgresql

Verificando o status do serviço

Para garantir que o serviço está funcionando corretamente, você pode verificar o status atual do PostgreSQL com o comando abaixo:

ShellSession
sudo systemctl status postgresql

Esse comando retorna informações detalhadas, como se o serviço está ativo, inativo ou se houve falhas recentes, facilitando a administração do sistema.

Sistemas de arquivos

A escolha e a configuração do sistema de arquivos são fundamentais para o desempenho e a confiabilidade de um banco de dados PostgreSQL. Cada sistema de arquivos tem características específicas que podem impactar diretamente na forma como o PostgreSQL gerencia seus dados, especialmente em termos de I/O (entrada/saída) e recuperação em caso de falhas. Confira a seguir alguns dos principais tipos.

EXT4

O EXT4 é o mais recente e mais utilizado sistema de arquivo no Linux, tendo sido criado para superar seu antecessor, o EXT3. Ele é conhecido pela sua robustez e capacidade em termos de confiabilidade e velocidade. Algumas características desse sistema são:

  • Utiliza journaling (mantém um registro das alterações antes de serem aplicadas ao sistema de arquivos, o que ajuda a proteger os dados em caso de falhas de energia ou outras interrupções inesperadas), facilitando a recuperação e minimizando a possibilidade de corrupção de dados;
  • Amplamente compatível com diferentes versões do Linux;
  • Oferece um bom desempenho geral, especialmente para operações de leitura e escrita comuns em ambientes de banco de dados;
  • É escalável, sendo capaz de lidar com volumes de até 1 exabyte e arquivos de até 16 terabytes, atendendo a diversos casos de uso.

XFS

O XFS é um sistema de arquivos mais antigo, porém também de alto desempenho e criado principalmente para lidar com grandes conjuntos de dados, sendo altamente escalável. As características dele são:

  • Como citado, é otimizado para desempenho em sistemas com grandes quantidades de dados;
  • Especialmente eficaz em ambientes em que operações de I/O intensivas são comuns, como em servidores de banco de dados;
  • Também pode suportar sistemas de arquivos de até 16 terabytes;
  • Assim como o EXT4, o XFS também utiliza journaling para proteger a integridade dos dados. No entanto, o XFS possui um sistema de journaling mais sofisticado, que é projetado para minimizar o impacto no desempenho durante a recuperação de falhas.

Outros sistemas de arquivos

Existem inúmeros sistemas de arquivos disponíveis para o Linux, alguns utilizados em situações específicas, nem sempre adequadas para o uso com bancos de dados, por exemplo,  sistemas de arquivos em cluster (como CFS, OCFS, UFS etc.) ou compartilhados (como CFS, OCFS ou GFS2). Outros sistemas são obsoletos, como o EXT2 e o EXT3, que deram lugar ao EXT4. Há também o ReiserFS, que já foi muito utilizado, mas é mais eficiente ao lidar com muitos arquivos pequenos, o que não é performático ao tratar com bancos de dados. Por fim, temos sistemas de arquivos mais modernos, como o BTRFS e o ZFS, que possuem vantagens interessantes, mas nos testes que conhecemos não oferecem uma performance e estabilidade tão boa quanto o EXT4 e o XFS, além de exigirem mais conhecimento para ajustar corretamente.

Na prática, a diferença em termos de performance e segurança é mínima. Um tem pequenas vantagens aqui e ali sobre o outro, mas você pode escolher aquele que se sinta mais confortável de usar. 

O EXT4 é o sistema de arquivos padrão na maioria das distribuições Linux, incluindo o Debian e o Red Hat, mas todos costumam ter suporte para o XFS também.

Particionamento

O particionamento de discos no Linux é uma prática essencial para otimizar o desempenho, a organização e a segurança dos dados em servidores que hospedam bancos de dados. 

Particionar adequadamente o disco pode ajudar a isolar diferentes tipos de dados, melhorar a eficiência de I/O e facilitar a recuperação de dados em caso de falhas.

Existem alguns motivos pelos quais é interessante isolar um servidor de banco de dados em uma partição própria. Alguns deles são:

  • Proteção contra falta de espaço em disco: se o banco de dados ficar na mesma partição do SO, em caso de falta de espaço, você pode ficar sem acesso ao servidor e precisar dar um boot no modo de recuperação, que é um processo bem delicado;
  • Desempenho: ao separar diferentes partes do banco de dados e do SO, você consegue fazer algumas otimizações de desempenho específicas para cada um. Além disso, você pode lidar com diferentes tipos de discos, com maior desempenho ou maior volume, para utilizar em lugares específicos;
  • Proteção contra perda de dados: se você armazenar os dados do servidor em um conjunto de discos, o WAL e seus arquivos de log em outro e tiver um backup físico em outro local, a perda completa dos discos onde os tablespaces estão não resultará em perda de dados. Separar os tablespaces do WAL e seus arquivos de log, além de manter um backup físico em um local separado (outro servidor, disco, fita etc.), é uma política de segurança eficaz para evitar perda de dados.

Quando você utiliza o PostgreSQL num servidor Linux dedicado, você tem diferentes opções de particionamento. Veja aqui algumas opções mais comuns:

  • / (root ou raiz): todo Linux deve ter uma partição dedicada ao SO na raiz. Essa partição em geral não precisa ser muito grande, algo em torno de 20 GB num servidor dedicado costuma ser mais do que o suficiente;
  • /boot: a maioria das distribuições Linux costuma reservar uma pequena partição para o kernel do Linux. Isso já vem por padrão na sua distribuição, você não precisa se preocupar com isso. Apenas não altere nada aí;
  • /data (ou outro nome de diretório a sua escolha): num ambiente de produção, o local de armazenamento do seu banco de dados PostgreSQL (também temos a mania de chamá-lo pelo nome da variável de ambiente $PGDATA) deve ser criado numa partição separada. Essa partição deve ter um tamanho suficientemente grande para acomodar todos os dados pelos próximos anos (pelo menos 3 anos) e ainda ter uma folga de 20% de espaço livre. Nós ensinamos como fazer a instalação num diretório diferente do padrão nos nossos artigos sobre instalação do PostgreSQL no Debian e no Red Hat; 
  • Logs: alguns servidores de produção podem gerar uma quantidade enorme de logs, especialmente se algum erro estranho começar a acontecer de repente ou se você quiser fazer um DEBUG das operações no banco de dados e logar todos os comandos executados nele. Isso pode ocupar um grande espaço em disco e também gerar muito I/O. Separar uma partição só para os logs do PostgreSQL e ajustar o parâmetro log_directory resolve a questão de forma elegante;
  • Backup e archives: você jamais deve guardar os seus backups e archives no mesmo disco físico do seu banco de dados. Na verdade, você não deveria sequer guardar eles no mesmo servidor. O certo seria armazenar esses arquivos num servidor de backup ou num serviço de block storage na nuvem, como a S3;
  • Tablespaces: todo banco de dados relacional armazena os dados em tablespaces. O PostgreSQL já cria por padrão dois tablespaces (o pg_default e o pg_global), que ficam dentro do diretório de dados do PostgreSQL: o $PGDATA. Logo, a maioria das pessoas jamais se preocupa com isso. No entanto, se você tiver discos com capacidades e velocidades distintas, talvez seja melhor separar um tablespace para utilizar apenas uma parte dos dados nesse disco diferente. Já se você tiver discos idênticos, em geral a melhor opção é sempre juntá-los num RAID.

Logical Volume Manager

Muitas pessoas optam no dia a dia pelo uso do LVM2 para juntar diferentes discos em uma única partição e permitir a adição de novos discos no servidor sem ter que desmontar a partição atual. Em troca, você tem uma pequena perda de performance e um aumento na complexidade para gerenciar os discos. Se você tem um profissional competente para lidar com isso, e a flexibilidade é um fator importante para você, usar o LVM2 pode ser uma boa opção. Aqui não vamos demonstrar o seu uso, mas fica a dica como referência.

Montagem de partições

Depois de particionar (utilizando o fdisk ou o cfdisk) e formatar a partição do seu disco (com o mkfs) usando o seu sistema de arquivos predileto (recomendamos anteriormente o EXT4 ou o XFS), chegou a hora de montar as suas partições. Para isso, você deve editar o arquivo /etc/fstab, que contém as configurações de montagem de sistemas de arquivos no Linux. Algumas recomendações são:

  • Utilizar UUIDs (Identificadores Únicos Universais) em vez de nomes de dispositivos: é vantajoso porque UUIDs são imutáveis, mesmo que você adicione ou remova discos no sistema, memória etc., eles não vão mudar de forma inesperada, evitando falhas na montagem de sistemas de arquivos e até na inicialização do servidor;
  • Utilizar a opção noatime para montagem do disco: impede que o sistema atualize a data de acesso aos arquivos toda vez que eles são lidos, reduzindo a carga de I/O no disco e melhorando o desempenho, especialmente em servidores de banco de dados.

Para encontrar os UUIDs das suas partições, você pode consultar o diretório by-uuid:

Debian shell: consultando UUIDs
# ls -lha /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 Aug 26 17:06 .
drwxr-xr-x 8 root root 160 Aug 26 16:55 ..
lrwxrwxrwx 1 root root  10 Mar 28 06:01 0bcbad84-23f8-485b-9d66-513bb480a5cb -> ../../vda1
lrwxrwxrwx 1 root root   9 Aug 26 16:50 2024-03-27-15-36-35-00 -> ../../vdb
lrwxrwxrwx 1 root root  11 Mar 28 06:01 DB24-2355 -> ../../vda15
lrwxrwxrwx 1 root root  10 Aug 26 17:06 e59345d7-ea63-4625-98bf-037d425caa50 -> ../../sda1

Aqui, vamos montar a partição sda1. No diretório /data, adicionamos a última linha do nosso arquivo /etc/fstab:

Debian shell: montando a partição
# /etc/fstab: static file system information
UUID=0bcbad84-23f8-485b-9d66-513bb480a5cb / ext4 rw,discard,errors=remount-ro,x-systemd.growfs 0 1
UUID=DB24-2355 /boot/efi vfat defaults 0 0
UUID=e59345d7-ea63-4625-98bf-037d425caa50 /data ext4 noatime 0 0

Nesse exemplo,  a nova partição será montada em /data com o sistema de arquivos ext4, com a opção noatime e “0 0” representando não inclusão no backup automático e não verificação pelo fsck na inicialização.

sysctl.conf

O arquivo sysctl.conf é uma ferramenta essencial para ajustar diversos parâmetros do kernel Linux. Para DBAs que administram servidores PostgreSQL, ajustar as configurações no sysctl.conf pode ajudar a otimizar o desempenho, a eficiência de I/O e a segurança do sistema.

Por ele, podemos mexer em diversas configurações, como:

  • Rede
  • Memória
  • Processos
  • Segurança

Esse arquivo está localizado em /etc/sysctl.conf, e esses parâmetros definem configurações que podem ser aplicadas durante a inicialização do sistema e também em tempo real. Para manipular esses parâmetros, existem duas opções:

  1. Alterar as linhas do arquivo utilizando um editor de texto, como vi ou nano. As alterações feitas diretamente no arquivo são permanentes;
  2. Utilizar os comandos do sysctl. Nesse caso, as alterações são aplicadas apenas para a sessão atual e retornarão ao padrão após o encerramento da sessão.

Além dessas opções, uma abordagem mais moderna e modular é utilizar arquivos de configuração separados no diretório /etc/sysctl.d/. Por exemplo, você pode criar um arquivo chamado /etc/sysctl.d/xx_postgresql.conf para ajustes específicos do PostgreSQL (o xx representa algum número, que servirá para organizar e aplicar as configurações dos arquivos em ordem alfanumérica). Isso permite uma organização mais clara e evita a necessidade de modificar o sysctl.conf principal diretamente.

Configurações gerais que melhoram a performance

  • vm.dirty_ratio = 10: limita a quantidade de memória que o sistema pode usar para guardar dados modificados que ainda não foram salvos no disco. Quando chega a 10%, o sistema começa a gravar esses dados no disco;
  • vm.dirty_background_ratio = 5: quando 5% da memória está cheia de dados não salvos, o sistema começa a gravar esses dados no disco, mas de forma mais tranquila e em segundo plano;
  • vm.overcommit_ratio = 95: informa a partir de qual porção da memória disponível (incluindo a RAM física e o swap em disco) o mecanismo de Out Of Memory Killer (OOM Killer para os íntimos) começará a ser utilizado. O valor padrão é de 50%, que consideramos muito baixo, por isso recomendamos utilizar 95%;
  • vm.overcommit_memory = 2: com essa configuração, o sistema operacional faz algumas checagens adicionais antes de matar um processo por falta de memória usando o OOM Killer. Esse é o nível mais seguro para se utilizar com o PostgreSQL;
  • vm.swappiness = 1: diz ao sistema para usar a memória RAM o máximo possível antes de começar a usar a área de swap (memória em disco), o que ajuda a manter o desempenho rápido.

Para aplicar as mudanças feitas diretamente no arquivo sysctl.conf ou no personalizado dentro do /etc/sysctl.d/, você pode usar o comando sysctl -p. Esse comando recarrega as configurações do sysctl.conf, aplicando as novas definições sem a necessidade de reiniciar o sistema. 

Já para aplicar temporariamente na sessão atual, você pode usar o comando sysctl diretamente, seguido do parâmetro e do valor que deseja configurar. Essas mudanças serão temporárias e durarão até que o sistema seja reiniciado ou a sessão atual seja encerrada.

Exemplo:

Debian shell: ajustando parâmetros de performance
sudo sysctl vm.dirty_ratio=10
sudo sysctl vm.dirty_background_ratio=5
sudo sysctl vm.overcommit_memory=2
sudo sysctl vm.overcommit_ratio=95
sudo sysctl vm.swappiness=1

Huge pages

É um recurso do Linux que permite ao sistema operacional lidar com páginas (blocos) de memória maiores que o padrão de 4 KB. Com páginas maiores, o sistema precisa gerenciar menos páginas, o que reduz o trabalho do processador e melhora o desempenho. Em servidores com 32 GB de RAM ou mais, recomendamos configurar as huge pages.

O PostgreSQL pode ser configurado para utilizar as huge pages, o que é indicado para controle total sobre a alocação de memória e a utilização mais eficiente da RAM. Para configurar o uso das huge pages, basta seguir estes passos:

  • Checar o parâmetro shared_buffers (parâmetro que define a quantidade de RAM para armazenar dados temporários): basta rodar o comando abaixo no psql:
SQL: consultando o parâmetro shared_buffers
SHOW shared_buffers;
  • Calcular o número de huge pages necessárias: precisamos definir o número de páginas, que pode ser calculado com base no valor de shared_buffers + 10%, dividido pelo tamanho da página. Então, o valor das huge pages deve ser = (shared_buffers(em MB) * 1,1)/ 2.

Exemplo: 
shared_buffers = 16 GB
hugepages = (16 * 1024 *1,1) / 2 = 9011

  • Aplicar o valor obtido: para isso, basta editar a linha GRUB_CMDLINE_LINUX no arquivo /etc/default/grub:
Debian shell: aplicando novos valores em parâemtros no arquivo grub
GRUB_CMDLINE_LINUX="... hugepages=9011 hugepagesz=2M transparent_hugepage=never"

É possível também ajustar o valor das huge pages no sysctl, mas em alguns casos (principalmente em servidores com mais de 256 GB de RAM) essa configuração pode falhar, como quando o SO não consegue alocar uma área contínua para as páginas após o boot. Logo, é mais seguro configurar as huge pages sempre no boot loader, nesse caso, o grub, que é o mais utilizado.

  • Atualizar a alteração: é necessário executar como root ou sudo o comando update-grub e depois reiniciar o servidor com reboot.
Debian shell: atualizando o servidor pós alterações em parâmetros
sudo update-grub
sudo reboot

Transparent Huge Pages

Transparent Huge Pages é uma funcionalidade do kernel Linux que automaticamente gerencia e aloca as huge pages, ajudando o sistema a usar a memória de forma mais eficiente. O ajuste aqui também é recomendado para servidores com bastante RAM, de 32 GB ou mais.

Vantagem: usar páginas maiores facilita o trabalho do sistema ao gerenciar a memória, evita o desperdício de espaço e pode deixar programas que usam muita memória mais rápidos.

Desvantagem: o uso de páginas maiores pode causar problemas se o sistema precisar frequentemente converter páginas menores em páginas grandes. Esse processo de conversão pode gerar atrasos e sobrecarga adicional, especialmente em cargas de trabalho intensivas, o que pode prejudicar o desempenho em vez de melhorá-lo. 

Praticamente todos os bancos de dados relacionais, incluindo o PostgreSQL, sofrem uma piora na performance quando usam o THP, logo, é padrão desabilitá-lo.

Configuração:

Para ver se o THP está ativado, você pode usar este comando:

Debian shell: checando THP
~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Nessa saída, vemos que a funcionalidade está ativa de forma geral no sistema (pelo always selecionado). As outras duas opções representam:

  • madvise: só é ativado para programas que solicitam explicitamente o uso de páginas grandes, através de uma chamada ao sistema madvise. Esse é um modo intermediário, no qual o THP não é usado em todas as situações, mas apenas quando recomendado;
  • never: o THP está desativado.

Se você quiser desativar o THP temporariamente (até reiniciar o sistema), use o seguinte comando:

Debian shell: desativando THP temporariamente
echo "never" | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

Já para desativá-lo permanentemente, o que traz um desempenho e uma performance mais consistentes e ideais para um servidor de banco de dados, basta adicionar o script abaixo no arquivo /etc/rc.local:

Debian shell: desativando THP permanentemente
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
    echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
    echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

Limits

São configurações que determinam o uso máximo de recursos do sistema para processos e usuários. Os limits ajudam a controlar o consumo de recursos e a evitar que um único processo ou usuário sobrecarregue o sistema.

Anteriormente, os limits de recursos eram configurados diretamente no arquivo /etc/security/limits.conf. No entanto, as versões mais recentes do sistema operacional Linux permitem que essas configurações sejam organizadas em arquivos específicos dentro do diretório /etc/security/limits.d/, o que facilita a gestão e a organização das configurações.

Por exemplo, no caso do PostgreSQL, o arquivo /etc/security/limits.d/90-postgresql.conf pode ser utilizado para definir os limits de recursos específicos para o usuário postgres. Esses arquivos são organizados e aplicados por ordem alfanumérica, o que significa que faz diferença escolher um número (como o 90) no momento de nomear seu arquivo.

Exemplo de configuração

Um parâmetro comum a ser configurado quando utilizamos grandes bancos de dados é o nofile, que define o número máximo de arquivos que um processo pode abrir ao mesmo tempo. No PostgreSQL, essa configuração é crucial para evitar erros relacionados ao excesso de arquivos abertos. Alguns dos erros comuns relacionados a esse parâmetro são:

Debian shell: erro de carga de arquivos
LOG: out of file descriptors: Too many open files in system; release and retry 
PANIC: could not open file (...): Too many open files in system

Para resolver, basta ajustar o parâmetro nofile dentro do arquivo 90-postgresql.conf:

Debian shell: ajustando parâmetro nofile
postgres soft nofile 65535
postgres hard nofile 65535

Na primeira linha, definimos o soft limit ou limite suave (valor que o sistema mantém, mas que pode ser alterado pelo próprio usuário, sem ultrapassar o hard limit) para o número de arquivos abertos pelo usuário postgres, como 65.535 arquivos.

Já na segunda linha, foi definido o hard limit ou limite rígido (valor que só pode ser alterado por usuários com permissões elevadas) para o número de arquivos abertos pelo usuário postgres, também como 65.535 arquivos. Esse valor costuma ser adequado para a maioria dos bancos de dados grandes.

Conclusão

Apesar da eficiência natural do PostgreSQL, ambientes críticos e pesados beneficiam-se muito de pequenos ajustes no Linux e melhoram o desempenho, a segurança e o bom uso dos recursos do hardware. 

Quanto mais você conhecer o tipo de carga do seu banco de dados, melhor poderá ajustar a arquitetura do seu servidor e as configurações do Linux. Este artigo mostra as opções mais comuns, utilizadas em todos os servidores de produção com os quais trabalhamos e recomendadas após uma longa experiência no assunto. No entanto, situações extremas podem se beneficiar de ajustes específicos que fogem do escopo deste artigo. De qualquer forma, com as sugestões apresentadas aqui, você certamente estará em boas mãos na maior parte dos casos.

The post Tuning de SO (no Linux) first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/10/09/tuning-de-so-no-linux/feed/ 0 8528 Escolhendo hardware para o seu servidor PostgreSQL https://savepoint.blog.br/2024/09/30/postgresql-hardware/ https://savepoint.blog.br/2024/09/30/postgresql-hardware/#respond Mon, 30 Sep 2024 22:36:22 +0000 https://savepoint.blog.br/?p=8517 Introdução Agora que já falamos sobre cenários e seus tipos de cargas de dados, chegou o momento de sermos mais específicos e falarmos sobre hardware. A escolha do hardware correto é crucial para a performance e a segurança de um servidor de banco de dados. Neste artigo, abordaremos os aspectos mais importantes do hardware para bancos

The post Escolhendo hardware para o seu servidor PostgreSQL first appeared on Savepoint.

]]> Introdução

Agora que já falamos sobre cenários e seus tipos de cargas de dados, chegou o momento de sermos mais específicos e falarmos sobre hardware. A escolha do hardware correto é crucial para a performance e a segurança de um servidor de banco de dados. 
Neste artigo, abordaremos os aspectos mais importantes do hardware para bancos de dados, considerando diferentes cenários de uso: aplicações web, OLTP e Data Warehouse.
Um ponto importante antes de começar a fuçar em diferentes possibilidades é, ao falar de bancos de dados em produção, ter uma postura um pouco mais conservadora. Ninguém gosta de arriscar demais quando falamos em bancos de dados. O prejuízo que se tem no caso de um desastre é alto demais. Então, lembre-se disso ao fazer as suas escolhas. Em ambientes de produção, evite a última moda, o lançamento mais recente, a tecnologia disruptiva, até que ela tenha sido testada e aprovada amplamente pelo mercado. Escolha componentes conhecidos, de fornecedores confiáveis e com robustez comprovada, sempre.

Roteiro:

  • Diferenças entre ambientes (teste, homologação e produção)
  • CPU
  • Memória RAM
  • Disco & Cia
  • Rede
  • Aspectos importantes de hardware para banco de dados
  • Hardware para cenários específicos

Diferenças entre ambientes (testes, homologação e produção)

A escolha do hardware para servidores de bancos de dados varia significativamente de acordo com o ambiente em que ele vai rodar. Apesar de cada equipe usar um nome diferente, geralmente os ambientes são resumidos em três categorias:

  • Testes ou desenvolvimento: algumas pessoas desenvolvem no seu próprio desktop ou possuem um servidor menor para testes e desenvolvimento. Geralmente, utilizam um hardware bem menor com menos poder de fogo e sem muitos requisitos de segurança. Aqui, o mais importante é a flexibilidade de subir novos ambientes para novas tarefas. É muito comum precisar subir um ambiente de teste novo isolado para desenvolver uma funcionalidade específica. O uso de contêineres também é bem comum;
  • Homologação ou QA: aqui os requisitos de desempenho geralmente são importantes. É comum utilizar uma cópia recente da base de produção, com o mesmo volume de dados, na hora de homologar uma nova funcionalidade ou simular um erro encontrado por um usuário. Nesse caso, não queremos apenas saber se alguma coisa funciona ou não, queremos saber se o desempenho é satisfatório, medir a velocidade, fazer testes com carga mais próxima possível da realidade, para evitar sustos na hora de colocar em produção. Por outro lado, os requisitos de segurança do hardware também não são importantes, de forma que não há uma preocupação com alta disponibilidade do hardware, por exemplo;
  • Produção: aqui é o nosso ponto focal do artigo. Precisamos tanto de desempenho como de segurança. Aí é que entra o problema da tríade: custo, segurança e desempenho. Você não consegue ter os três ao mesmo tempo, precisa escolher apenas dois! Focaremos boa parte do nosso artigo especificamente nesse ambiente, que é o mais crítico de todos e onde os custos chamam a atenção. Portanto, é importante saber onde investir o seu limitado orçamento para tirar o melhor proveito possível dele. 

CPU

O primeiro ponto em que se pensa quando vamos adquirir um servidor (seja on premise ou na nuvem) para rodar um banco de dados em produção é a CPU. Talvez esse não seja o item mais importante de todos (vamos falar sobre isso adiante), mas certamente costuma ser o primeiro a ser lembrado.

Desempenho 

Do ponto de vista do desempenho, há três pontos importantes para se observar:

  • Velocidade do clock da CPU. Quanto maior a velocidade da CPU, mais rapidamente ela vai processar as solicitações dos usuários do banco de dados. Isso é especialmente importante em ambientes com cálculos complexos como IA, Data Science e BI;
  • Número de processadores/cores/threads. Se você está num ambiente OLTP ou Web, entenda que cada requisição de usuário vai ocupar uma CPU. Se você possuir várias dezenas de requisições ao mesmo tempo, vai precisar de várias CPUs para processá-las rapidamente. Se o número de requisições for maior que a quantidade de CPUs disponíveis, as requisições vão ficar numa fila de espera e a aplicação terá de ficar aguardando. Num ambiente de Data Science ou BI, o PostgreSQL também poderá quebrar consultas complexas e pesadas em pedaços menores e utilizar uma CPU para cada um desses pedaços, paralisando a solicitação. Dessa forma, possuir mais CPUs irá agilizar solicitações complexas e pesadas através desse tipo de recurso;
  • Quantidade de cache L1, L2 e L3. Memória é sempre um bom investimento. A memória interna da CPU é mais rápida que a memória RAM externa que você mesmo instala no servidor. Bancos de dados costumam trabalhar com grandes volumes de dados, e geralmente quanto mais RAM, mais rápido você consegue processar as informações. Operações internas de consultas, como ordenações, hash joins etc., se beneficiam muito de um bom cache na CPU.

Segurança

Do ponto de vista da segurança, o mais importante é evitar processadores utilizados em desktops. Servidores de produção quase sempre operam em regime 24/7, não são desligados nunca. Então, processadores desenvolvidos para servidores têm uma vida útil maior e são feitos para rodar com carga ininterruptamente. Se você utilizar um processador de desktop para rodar no seu servidor 24/7, provavelmente a vida útil dele será menor do que a esperada. A mesma questão se aplica a outros componentes, como memória, discos etc.

CPUs para servidores de produção no mercado hoje

Existem três grandes fornecedores de CPU para servidores no mercado:

  • A Intel, fornecedora mais tradicional de CPUs. Esqueça as linhas i3, i5, i7 e i9 da Intel. Em servidores, ela oferece a linha Xeon, que domina o mercado de servidores há uns bons anos. Esses servidores são considerados robustos e rápidos, possuem versões com diferentes velocidades de clock, quantidades de cache e cores. No momento em que este artigo foi escrito, a linha Xeon está na sua 6a geração e possui processadores com até 144 cores, 3.2 GHz de frequência e 108 MB de cache (vale lembrar que existem vários tipos de cache dentro de uma CPU);
  • A AMD é a segunda fornecedora mais conhecida de CPUs, sendo mais popular no mercado de desktops, mas, de uns anos para cá, ela também tem se mostrado competitiva no segmento de servidores. Assim como a Intel, a AMD possui a linha Ryzen e Athlon para desktops, mas no segmento de servidores, vamos olhar para a linha EPYC. Os processadores EPYC, no momento em que este artigo foi escrito, estão na sua 4ª geração, e a Série 9004 possui hoje modelos com até 128 cores, 4.4 GHz de frequência e até 1 GB de cache L3;
  • A ARM é uma fabricante líder em processadores para dispositivos embarcados, mas que passou a ser muito utilizada na AWS, devido ao seu baixo custo e baixo consumo de energia, o que pesa consideravelmente quando pensamos num datacenter com milhares de servidores. A linha Neoverse N1 e N2 é dedicada a servidores com até 128 cores.

Memória RAM

Para manipular os dados do seu banco de dados, as informações contidas nas suas tabelas precisam estar na memória RAM antes de serem processadas pela CPU. Num cenário ideal, seria possível guardar todos os dados de todas as tabelas do seu banco de dados na RAM. Assim, todas as operações seriam muito mais rápidas. Infelizmente, isso não é possível na maioria das vezes. Hoje em dia, consideramos que um banco de dados com alguns TBs é de tamanho médio, e um servidor com 1 TB de RAM, embora seja possível e existam modelos assim no mercado, possui um custo nada acessível. Dessa forma, investir em memória costuma ser um ótimo benefício, pois quanto mais o seu banco de dados couber na RAM, maior a chance de você não precisar acessar o disco, que é muito mais lento.

DDR DIMM

A RAM é vendida em módulos com chips colados em ambos os lados de uma pequena placa, chamada de DIMM (Dual In-line Memory Module). Existem vários modelos de memória RAM no mercado com diferentes características. A primeira e mais comum é a velocidade delas. No momento em que este artigo foi escrito, as memórias costumam utilizar o padrão DDR (Double Data Rate), que hoje estão na sua 5a geração, conhecidas como DDR5, lançadas em 2023 com velocidades entre 4000 MT/s e 8000 MT/s. O padrão DDR4, lançado em 2014, ainda se encontra no mercado e tem velocidades 1600 MT/s e 3200 MT/s. O padrão DDR6 tem lançamento previsto para 2026.

UDIMM, RDIMM e LRDIMM

Existem também os padrões UDIMM, RDIMM e LRDIMM, que se diferenciam pelos mecanismos internos de buffer.

  • Memórias UDIMM não possuem buffer (Unbuffered DIMM) e são mais baratas, mas consomem mais energia e são mais instáveis. Além disso, não é possível utilizar grandes quantidades de RAM UDIMM na mesma máquina. Logo, as memórias UDIMM são mais baratas e mais comuns de se encontrar em desktops. Não utilizamos memórias UDIMM em servidores de produção;
  • Memórias RDIMM possuem buffer (Registred DIMM), são mais estáveis e podem utilizar vários módulos de memória na mesma máquina com velocidades maiores também. São as mais comuns de se encontrar em servidores. É esse tipo de memória que você deve utilizar no seu ambiente de produção nos dias de hoje;
  • Memórias LRDIMM (Load Reduced DIMM) e outras versões proprietárias de fabricantes específicos prometem melhorias e tecnologias específicas para melhorar o desempenho ou o consumo de energia. 

ECC

Memórias em servidores de bancos de dados devem sempre utilizar o padrão ECC (Error Checking and Correcting). Memórias sem ECC têm lá seus mecanismos de detecção de erros, mas não são tão eficientes quanto as que usam ECC. Esse é o padrão mais confiável hoje, utilizado e aprovado pelo mercado há um bom tempo. Não arrisque! Falhas de memória sem ECC podem levar a falhas catastróficas no seu banco de dados.

Discos ou armazenamento não volátil

Os discos são dispositivos de armazenamento fundamentais para servidores de banco de dados, responsáveis por guardar e acessar dados de forma eficiente. Eles variam em tipo, desempenho e capacidade, influenciando diretamente a performance do banco de dados. Os discos são provavelmente o componente que você vai escolher com mais cuidado ao montar um servidor de banco de dados. Possivelmente, será a parte mais cara dele também. O problema fundamental é que, normalmente, as pessoas pensam em discos apenas pela sua capacidade. Aqui temos que pensar não apenas na capacidade (e espaço para acomodar o banco de dados, espaço para ele crescer nos próximos anos, backups etc.), mas também no desempenho, na segurança etc. Bancos de dados exigem muito dos discos, gravam constantemente, lêem o tempo todo e, se qualquer coisa der errado, o prejuízo é ainda maior do que se qualquer outro componente do servidor falhasse, pois pode envolver, além da indisponibilidade do banco de dados, a perda de dados. 

Ao pensar na “persistência dos dados”, temos que pensar em todo o conjunto envolvido no processo: 

  • Storages externos
  • Controladoras de discos
  • RAID
  • Discos
  • Particionamento de discos

Storages

Em vez de armazenar os dados do seu banco dentro do servidor, você pode ter discos físicos locais dentro do servidor apenas para o sistema operacional e armazenar todos os dados num servidor externo dedicado apenas para lidar com isso, conhecido como storage. Existem diversos tipos no mercado. Os mais caros e poderosos utilizam uma rede separada, a SAN (Storage Area Network), com uma tecnologia específica, como a Fibre Channel ou a InfiniBand, ou o protocolo TCP/IP com o iSCSI. Nesse caso, você terá que utilizar duas placas adaptadoras para se comunicar com essa rede, conhecidas como HBA (Host Bus Adapter). Então existem duas possibilidades: é possível se conectar diretamente no storage, o que chamamos de DAS (Direct Attached Storage), ou numa SAN, utilizando switches e cabos especiais para conectar todos os servidores em um ou mais storages. Toda essa rede utiliza uma arquitetura chamada fabric, onde todos os componentes da rede têm redundância: HBAs, cabos, switches.
Outra opção mais simples, mais barata e bem menos robusta, segura e veloz é utilizar um NAS (Network Attached Storage), que é um storage plugado numa rede TCP/IP normal e que utiliza protocolos como o NFS (Network File System) no Linux. O NAS é uma ótima opção para armazenamento de grandes volumes de dados que não precisam de muita confiabilidade e desempenho. Esse não é o caso dos nossos bancos de dados em produção. Não o utilize em ambientes críticos.

Storages são componentes caros e complexos. Podem ter o tamanho de um simples servidor 4U num rack ou podem ocupar 2, 4, 8 racks full size inteiros. Quando você compra um brinquedinho desses, faz um contrato de suporte com o seu fornecedor por três a cinco anos. Seu equipamento será monitorado remotamente pelo fornecedor. Quando um disco falhar, ele irá bater na sua porta no dia seguinte com um técnico trazendo um disco novo debaixo do braço e vai trocar esse disco sem paralisar a sua operação. Sim, tudo utilizando hot swap e, claro, a tecnologia RAID, que vamos comentar a seguir. Quando acabar o período de contrato do suporte, você vai comprar um novo storage e substituir completamente o antigo, colocando-o para fazer coisas menos nobres, como no ambiente de homologação. Nenhum fornecedor de storage renova o contrato de suporte depois de vencido esse prazo de três a cinco anos. Entende como funciona? Além disso, um storage tem várias vantagens, como oferecer uma quantidade absurda de cache de gravação e leitura, baterias internas e redundantes que garantem o seu funcionamento em caso de falha de energia elétrica, controladoras robustas, capacidade de acomodar centenas de discos físicos e agregá-los de diferentes formas e, por fim, software caríssimo que oferece formas facilitadas de monitoramento, backup etc.

RAID

Técnica que combina múltiplos discos físicos para aumentar a performance e/ou confiabilidade. Diferentes níveis de RAID (como RAID 0, 1, 5, 10) oferecem variações entre tolerância a falhas, velocidade e capacidade de armazenamento. Aqui está um resumo sobre os mais populares:

  • JBOD (Just a Bunch of Disks): é o que existia antes do RAID. Você colocava vários discos no servidor, e cada um aparecia com pelo menos uma partição separada. Você tinha que distribuir os dados em tablespaces mapeados para cada disco e sair distribuindo índices e tabelas em tablespaces distintos. Um verdadeiro show de horror e um trabalho interminável. Ninguém mais usa isso, ufa!;
  • RAID 0: aumenta o desempenho ao dividir os dados entre vários discos (conhecido como striping), mas não oferece proteção contra falhas. Se um disco falhar, todos os dados são perdidos. Ninguém usa RAID 0 no nível de hardware em produção. Não faça isso, sério! O risco é enorme. No entanto, na nuvem, é comum utilizar RAID 0 por software, uma vez que já se supõe que exista algum tipo de RAID (que ninguém sabe direito qual é) no hardware do fornecedor. Veja que estamos falando de um cenário bem específico, ok?;
  • RAID 1: duplica os dados em dois discos (espelhamento). Se um disco falhar, o outro tem uma cópia idêntica dos dados, oferecendo alta segurança, mas sem aumento de desempenho em leitura. Utilizamos o RAID 1 normalmente quando temos apenas dois discos idênticos. Em outros casos, utilizamos o RAID 10;
  • RAID 5: distribui os dados e a paridade (informação usada para recuperar dados) entre três ou mais discos. Oferece um certo equilíbrio entre desempenho de leitura, capacidade e segurança. No entanto, para gravação, o RAID 5 tem uma perda considerável de performance, não sendo recomendado para ambientes OLTP. A segurança do RAID 5 também é muito questionável, pois quando um dos discos falha, ao substituir por um novo, é comum que um segundo disco falhe junto. No entanto, se você tiver que lidar com um volume muito grande de dados estáticos e/ou históricos (em que você faz muita leitura e pouca gravação), um bom RAID 5 pode ser uma opção como um segundo RAID, separando os dados mais críticos em um RAID 1 ou RAID 10, por exemplo;
  • RAID 6: é como o RAID 5, porém requer pelo menos quatro discos, já que os dados são gravados em dois deles. Suporta falha em dois discos sem perder dados. Apesar de ser um pouco mais seguro que o RAID 5, possui os mesmos problemas que o RAID 5 em termos de desempenho;
  • RAID 10 ou RAID 1 + 0: é uma junção do RAID 0 com o RAID 1. Assim você tem a segurança do espelhamento do RAID 1 com a velocidade da distribuição de dados do RAID 0. Você precisa de, no mínimo, quatro discos para fazer um RAID 10 e deve aumentar o número de discos sempre em números pares: 6, 8, 10, 12 etc. 

Se você tem um servidor muito pequeno, comece com um RAID 1. Se tem um servidor maior, pense no RAID 10. Se tem um volume muito grande de dados, pense numa combinação entre RAID 1 ou 10 com um RAID 5 ou 6.

Importante frisar que a técnica RAID não substitui backups de rotina, pois não protege contra todos os tipos de falha, como erros humanos, e não oferece histórico de versões.

Controladoras de disco

Trata-se de hardware dedicado que gerencia a comunicação entre o servidor e os discos. Controladoras RAID são específicas para implementar diferentes níveis de RAID, garantindo melhor desempenho e segurança dos dados. Se você utiliza um storage, ele já deve ter uma excelente controladora de discos embutida, então não precisa se preocupar com isso. Se está na nuvem, menos ainda. Mas se você vai guardar todos os seus discos físicos dentro do seu servidor… precisa, sim, pensar na controladora que vai utilizar. Todo servidor, em geral, tem uma controladora de discos embutida na placa-mãe. Essa controladora embutida é limitada em número de discos suportados, possibilidade de fazer RAID, cache e uso de bateria embutida.
Cada controladora suporta uma interface específica de discos. Desktops utilizavam discos SATA (Serial ATA), e servidores utilizavam o SCSI, Fibre Channel ou Serial Attached SCSI, até que os discos mecânicos passaram a dar lugar aos discos de estado sólido, os SSDs. Hoje em dia, quase ninguém usa mais discos mecânicos, e tudo isso virou de cabeça para baixo. Existem N formatos de discos SSDs e soluções que foram nascendo e morrendo com o tempo. Vale lembrar que os discos SSDs em servidores são bem diferentes dos discos utilizados em desktops. Servidores de grande porte utilizam os discos NVMe (Non Volatile Memory Express), que se conectam através do barramento PCI Express e substituem a arquitetura utilizada em discos mecânicos, a AHCI. 

Atualmente, boa parte das soluções se concentram em placas PCI Express com várias memórias SSD agrupadas e algumas capacidades embutidas de RAID e cache. Processadores para servidores de topo de linha também possuem controladoras embutidas NVMe com capacidade de gerenciar dezenas de discos SSDs. Hoje em dia, se você não vai utilizar um storage externo e quer utilizar vários discos SSDs, é melhor entrar em contato com o seu fornecedor de servidores e conversar com ele sobre as soluções disponíveis. 

Discos mecânicos

São um tanto ultrapassados, mas ainda utilizados em lugares onde se precisa de muito volume, pouco desempenho e baixo custo. Esse não costuma ser o lugar em que são utilizados bancos de dados. Apenas evite!

Discos SSD

Já faz um tempinho (2008) quando cantamos a bola de que os SSDs iriam substituir os discos magnéticos mesmo em servidores de bancos de dados; 15 anos depois, eles viraram padrão de mercado.

É um termo amplo que abrange qualquer dispositivo de armazenamento que tenha uma presença física tangível, incluindo discos magnéticos (HDDs), discos de estado sólido (SSDs), discos ópticos (como CDs e DVDs) e outros tipos de mídia de armazenamento. O termo “disco físico” é frequentemente usado para diferenciar esses dispositivos de discos virtuais ou na nuvem, que não têm uma presença física direta acessível ao usuário.

Discos magnéticos

É um tipo específico de tecnologia de armazenamento, em que os dados são gravados em discos revestidos com material magnético. O HDD (Hard Disk Drive) é o exemplo mais comum de disco magnético. Esses discos são conhecidos por sua capacidade de armazenar grandes volumes de dados a um custo relativamente baixo, mas têm desempenho de leitura e escrita mais lento em comparação com outras tecnologias, como os SSDs.

Discos SSD

Discos SSD definitivamente não são todos iguais. Uma enorme variedade de opções e formatos estão disponíveis no mercado. Temos três questões para se avaliar sobre discos: capacidade, desempenho e segurança. Capacidade é a parte mais simples. Diz respeito ao volume de dados que ele é capaz de armazenar. Nenhum mistério até aí. Velocidade já é um negócio mais manhoso, pois tem várias métricas diferentes. A primeira é a velocidade de transferência, quantos MB/s você consegue transferir. Mas não é tão simples. Essa capacidade muda se o acesso for sequencial ou aleatório. Também muda muito se for para leitura ou escrita. Outro ponto é o número de operações por segundo, medido por IOPS. Esse é um dos principais índices para medir o desempenho de um disco SSD. Novamente, varia bastante quando você está lendo ou gravando. Existem algumas outras métricas, mas essas são as principais.
Quando falamos de segurança em discos SSD, você precisa entender uma coisa importante: cada bit de um disco SSD suporta uma quantidade limitada de ciclos de gravação. Assim, quanto mais vezes você gravar no seu disco, menor será a sua vida útil. Sendo assim, quando você compra um disco SSD, ele vem com uma medida de MTBF (Mean Time Between Failures). Esses testes são feitos em um regime específico de trabalho, então esses números podem mudar muito se você pegar um SSD projetado para ser utilizado em um desktop e rodar um banco de dados 24/7 nele. Ele vai abrir o bico muito antes do esperado e vai deixar você na mão. É por isso que discos SSD para servidores são classificados em três tipos:

  • Read intensive, em que o disco vai suportar operações de leitura 24/7 por um bom tempo, mas não vai durar muito tempo se você fizer muitas operações de gravação. Você deve evitar o uso desse tipo de disco em bancos de dados de produção;
  • Mixed use, que possui um desempenho melhor em gravação e uma durabilidade maior em ambientes com um volume razoável de escritas. Esse tipo é adequado para bancos de dados em produção em casos genéricos, mas pode ser insuficiente para ambientes OLTP, que sofrem muitas operações de gravação;
  • Write intensive: esse é o tipo de disco mais caro e com melhor desempenho e durabilidade em operações de gravação. São ideais para bancos de dados em operação crítica e ambientes OLTP pesados.

Discos na nuvem

Os discos na nuvem referem-se a soluções de armazenamento fornecidas por provedores de serviços em nuvem, como AWS, Azure ou Google Cloud. Esses discos são virtuais, ou seja, não há um hardware físico específico vinculado ao usuário. Eles oferecem alta flexibilidade, escalabilidade e fácil integração com outras soluções na nuvem. Além disso, são frequentemente replicados em diferentes locais geográficos para garantir alta disponibilidade e durabilidade dos dados.
Discos na nuvem são ideais para cenários em que a elasticidade e a gestão simplificada são importantes. Cada fornecedor de nuvem possui diferentes opções de discos ou “block storage” que você pode utilizar em diversas situações. Você vai ter que estudar um pouco sobre cada um e escolher o que melhor lhe atende de acordo com o seu ambiente, mas dificilmente vai saber que tipo de hardware está sendo utilizado embaixo do capô.

Aspectos importantes de hardware para bancos de dados

Para garantir a eficiência e a performance de um banco de dados, é essencial considerar os seguintes componentes de hardware:

  • CPU (Processador)
    • Número de núcleos: mais núcleos permitem processar mais transações simultaneamente;
    • Frequência: processadores com alta frequência são melhores para tarefas que requerem alto desempenho por núcleo.
  • Memória RAM
    • Quantidade: deve ser suficiente para manter os dados frequentemente acessados na memória, reduzindo a necessidade de acesso ao disco;
    • Velocidade: RAM mais rápida melhora o tempo de resposta das operações.
  • Armazenamento
  • SSDs: oferecem alta velocidade de leitura e escrita, essencial para a performance do banco de dados;
  • IOPS (Operações de Entrada/Saída por Segundo): alta IOPS é crucial para sistemas com alta carga de transações.
  1. Rede
    • Largura de banda: necessária para suportar múltiplos acessos simultâneos;
    • Latência: baixa latência garante respostas rápidas.

Claro que a priorização desses componentes vai variar de acordo com o cenário e o tipo de carga de banco de dados, que exploraremos adiante.

Hardware para cenários específicos

OLTP

  • Processador: você vai precisar de muitos núcleos para dar conta de muitas conexões simultâneas. Processadores rápidos com mais cache também vão ajudar no processamento de transações complexas, típicas de ambientes OLTP;
  • Memória RAM: quanto mais memória melhor, sempre. Quanto mais porcentagem do banco couber na RAM, melhor. Muitas conexões simultâneas também consomem memória para fazer suas operações de consulta, então seja generoso na quantidade de RAM;
  • Armazenamento: discos SSD NVMe Write intensive ou mixed use com RAID 1 ou RAID 10 são as melhores opções. 

Web

  • Processador: ambientes web costumam lidar com uma quantidade absurda de requisições simultâneas. Foque aqui em ter muitas cores;
  • Memória RAM: aqui você com certeza quer cachear a maior parte do seu banco. Mais uma vez seja generoso na quantidade;
  • Armazenamento: aqui você deve ter uma quantidade menor de gravações em geral, discos SSD NVMe com RAID 1, 5 ou 10 do tipo read intensive ou mixed use devem resolver bem.

Data Warehouse / BI / Data Science

  • Processador: você precisa de mais cores para paralelizar as consultas, mas preste mais atenção na velocidade deles, pois esse tipo de carga costuma exigir cálculos mais complexos;
  • Memória RAM: esse tipo de ambiente costuma trabalhar com bases enormes, logo, vai precisar de uma boa quantidade de RAM para acompanhar;
  • Armazenamento: aqui a velocidade de gravação não é tão importante, você pode, às vezes, trabalhar com RAID 5 e discos read intensive ou mixed use. Vale a pena notar a frequência e o volume de cargas periódicas que você faz nesse ambiente para dosar melhor a importância das operações de gravação.

Conclusão

Aqui, apenas pincelamos algumas considerações sobre hardware na hora de montar o seu servidor. É claro que não temos uma fórmula mágica. Cada caso é um caso. Além disso, estamos falando de tecnologias em constante evolução, o que vale hoje pode não valer mais amanhã. Mesmo assim, lembre-se de ser conservador e se preocupe com a qualidade dos componentes, pensando em utilizar um hardware mais seguro, com fontes redundantes, ventoinhas redundantes, nobreaks, geradores de energia e até ar-condicionado redundantes.
Segurança é um tema extenso e complexo, mas começa em decisões simples como a de escolher componentes feitos para aguentar o tipo de carga que você espera, em vez de achar que qualquer desktop um pouco melhor vai dar conta do recado.

The post Escolhendo hardware para o seu servidor PostgreSQL first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/09/30/postgresql-hardware/feed/ 0 8517 Tipos de cargas dos bancos de dados https://savepoint.blog.br/2024/09/16/tipos-de-cargas-dos-bancos-de-dados/ https://savepoint.blog.br/2024/09/16/tipos-de-cargas-dos-bancos-de-dados/#respond Mon, 16 Sep 2024 14:32:16 +0000 https://savepoint.blog.br/?p=8513 Introdução Cargas de dados referem-se aos diferentes tipos de operações e transações que um banco de dados deve processar. Essas cargas variam conforme o tipo de aplicação e o uso do banco de dados, influenciando a forma como os dados são armazenados, acessados e manipulados. Compreender os diferentes tipos de cargas de dados ajuda a

The post Tipos de cargas dos bancos de dados first appeared on Savepoint.

]]> Introdução

Cargas de dados referem-se aos diferentes tipos de operações e transações que um banco de dados deve processar. Essas cargas variam conforme o tipo de aplicação e o uso do banco de dados, influenciando a forma como os dados são armazenados, acessados e manipulados. Compreender os diferentes tipos de cargas de dados ajuda a otimizar o desempenho e a eficiência do sistema, já que através disso surge a possibilidade de tomar as melhores escolhas em relação a hardware e parâmetros de otimização do seu banco, tornando-o mais rápido e eficiente. Então, neste artigo veremos:

  • Tipos de cargas
    • OLTP
    • DW
    • WEB
    • Mixed
    • Desktop

Tipos de cargas

OLTP (Online Transaction Processing ou Processamento de Transação Online)

Características

  • Alta concorrência (muitas conexões simultâneas) e baixa latência: precisa ser rápido e acontece muitas vezes e ao mesmo tempo;
  • Alto volume de pequenas transações: inserção, atualização ou exclusão de pequenas quantidades de dados;
  • Necessita de alta disponibilidade e consistência: deve estar sempre disponível para transações a qualquer momento, garantindo que os dados estejam sempre corretos e íntegros, mesmo em caso de falhas;
  • Também pode incluir rotinas de transações longas e complexas.

Recursos de hardware importantes

  • CPU: processadores de alta performance com muitos núcleos para lidar com múltiplas transações simultâneas;
  • Memória: quantidade suficiente de RAM para manter os dados frequentemente acessados em memória;
  • Disco: armazenamento SSD veloz para garantir acesso rápido aos dados e alta IOPS (Input/Output Operations Per Second);
  • Rede: conectividade de rede rápida e confiável para suportar múltiplos acessos simultâneos.

Exemplos de sistema OLTP

  • Sistemas bancários: processamento de transações financeiras, como depósitos, retiradas, transferências de fundos, pagamentos de contas e consultas de saldo;
  • E-commerce (lojas virtuais): transação de compra, como adição ao carrinho, finalização de compra, atualização de estoque, processamento de entradas de pedidos;
  • Sistema de reservas: reservas de passagens aéreas, hotéis, aluguel de carros e ingressos para eventos, garantindo disponibilidade em tempo real e atualizações instantâneas.

Data Warehouse (DW)

Características

  • Focado em consultas complexas e análise de dados: o principal aqui é leitura, pois guarda dados históricos que são consultados com certa frequência;
  • Integração de dados: consolida dados de diferentes fontes em um formato consistente;
  • Não volatilidade dos dados: diferente do OLTP, aqui os dados inseridos não são alterados ou apagados, proporcionando uma visão estável (e histórica) da informação;
  • Prioriza leituras e agregações: justamente para consulta de dados históricos, conforme citamos, permitindo análises de tendências ao longo do tempo;
  • Tolerância à latência maior em comparação ao OLTP.

Quando falamos sobre DW, existem outros termos que se relacionam e são frequentemente vistos:

  • Data lake: armazena dados brutos e não processados, incluindo dados estruturados, semiestruturados e não estruturados. A diferença para o DW é que lá temos dados processados e estrutura fixa. Os propósitos também se diferem: o datalake armazena grandes volumes de dados variados para análise futura, sendo adequado para big data, machine learning e análises avançadas, enquanto o DW atende mais a análises de negócios, geração de relatórios e suporte à tomada de decisões estratégicas;
  • Data frame: uma estrutura de dados em memória e tabular, semelhante a uma tabela em uma base de dados ou a uma planilha em Excel, com linhas e colunas. É comumente utilizado em linguagens de programação como Python (com pandas) e R para manipulação, análise e visualização de dados; é fácil de usar para operações de filtragem, agregação e transformação de dados.
  • Data mart: subconjunto de um DW, focado em um departamento específico ou área de negócio, como vendas, marketing ou finanças. Então, diferente de um DW que abrangeria toda a organização que guarda os dados, o datamart é focado e limitado a um departamento.

Recursos de hardware importantes

  • CPU: processadores poderosos para lidar com consultas complexas e operações de agregação;
  • Memória: grande quantidade de RAM para suportar grandes conjuntos de dados em operações analíticas;
  • Disco: armazenamento de grande capacidade e alta performance, preferencialmente SSDs;
  • Rede: conectividade robusta para transferência eficiente de grandes volumes de dados.

Exemplos de uso de um DW

Um Data Warehouse pode atender empresas de diversos setores que necessitam consultar e analisar seus dados históricos. Confira algumas das áreas em que essa estrutura é frequentemente utilizada:

  • Finanças: bancos e instituições financeiras utilizam DWs para consolidar dados de transações, analisar riscos, detectar fraudes e gerar relatórios de conformidade regulatória;
  • Varejo: empresas de varejo empregam DWs para analisar padrões de compras, gerenciar inventários, personalizar campanhas de marketing e monitorar o desempenho das vendas;
  • Saúde: organizações de saúde usam DWs para consolidar registros de pacientes, analisar tratamentos e resultados clínicos e gerar relatórios para pesquisa e conformidade regulatória.

Web

Características

  • Muita leitura: é destinado a aplicações web que envolvem transações rápidas (como consultas) durante a navegação do usuário;
  • Alta concorrência (muitas conexões simultâneas): por atender a usuários online, lida com transações de vários usuários ao mesmo tempo;
  • Necessidade de escalabilidade: é crucial que a infraestrutura seja escalável para lidar com picos de acesso sem comprometer a performance ou a disponibilidade do sistema.

Recursos de hardware importantes

  • CPU: processadores com bom desempenho multi-core para lidar com múltiplas requisições simultâneas;
  • Memória: quantidade moderada a alta de RAM para suportar cache de sessões e dados frequentemente acessados;
  • Disco: armazenamento SSD para melhorar o tempo de resposta;
  • Rede: alta largura de banda e baixa latência para garantir tempo de resposta rápido.

Exemplos de sistemas web

  • Redes sociais: onde usuários interagem simultaneamente com postagens, atualizações de status, fotos e vídeos, gerando um grande volume de transações e consultas;
  • Streaming: onde usuários acessam conteúdo (vídeos, música) sob demanda, resultando em alta demanda de acesso durante horários de pico;
  • Portais de notícias: sites que experimentam picos de acesso durante eventos de grande importância ou notícias de última hora.

Mixed (misturado)

Características

  • Combina características de diferentes tipos de carga: OLTP e DW, por exemplo;
  • Envolve tanto transações rápidas quanto consultas complexas: rápidas como inserções, atualizações e exclusões de dados e complexas como análise e recuperação de dados históricos;
  • Otimiza recursos e custo: o objetivo aqui é usar de forma eficiente os recursos computacionais e de armazenamento, adaptando-se dinamicamente às necessidades da carga de trabalho mista para reduzir custos operacionais.

Recursos de hardware importantes

  • CPU: processadores com muitos núcleos e alta frequência para suportar diversidade de operações;
  • Memória: grande quantidade de RAM para suportar tanto operações transacionais quanto analíticas;
  • Disco: armazenamento SSD de alta capacidade para suportar tanto leitura quanto escrita intensivas;
  • Rede: alta capacidade de rede para lidar com diferentes tipos de carga de dados.

Exemplos de sistemas mixed

  • Sistemas ERP (Enterprise Resource Planning ou Gestão empresarial): sistemas que suportam processos empresariais como finanças, recursos humanos, cadeia de suprimentos e vendas. Eles lidam com transações diárias (como pedidos de compra, faturamento) e consultas analíticas (relatórios financeiros, análise de vendas);
  • Aplicações CRM (Customer Relation Management ou Gerenciamento de relação com o cliente): ferramentas que gerenciam interações com clientes, incluindo vendas, marketing e suporte ao cliente. Elas processam transações de atualização de dados do cliente e também consultas para análise de comportamento e tendências de vendas.

Desktop

Características:

  • Uso doméstico e individual: voltado para um único usuário ou um pequeno grupo de usuários em um ambiente residencial;
  • Gerenciamento de dados: inclui armazenamento e gerenciamento de dados localmente ou na nuvem para suportar atividades pessoais, como processamento de texto, planilhas, gerenciamento de fotos e vídeos, entre outros;
  • Pode ser utilizado para ambiente de testes e desenvolvimento.

Recursos de hardware importantes:

  • Processador: múltiplos núcleos e alta frequência para multitarefas, processamento complexo e jogos;
  • Memória: no mínimo 8 GB de RAM para executar diversos programas sem lentidão;
  • Disco: armazenamento SSD para melhorar o tempo de resposta.

Exemplos de uso de desktop

  • Usuários comuns: qualquer um que queira usar um computador para as mais diversificadas tarefas, como trabalho, jogos etc.
  • Programadores: profissionais que trabalham com um desktop individual e tanto desenvolvem programas quanto rodam testes nele.

Conclusão

Vimos que existem diversos tipos de cargas de dados que podem ser utilizadas com diversas finalidades. Na hora de montar um servidor de banco de dados, é importante conhecer sobre seu negócio, para saber como seu banco será utilizado e, assim, escolher a carga mais adequada, impactando positivamente no funcionamento e na performance do seu sistema/aplicação.

Além disso, recomendamos o site TPC, que traz diversos testes de benchmarking, das mais variadas situações de cargas de dados, o que pode ser útil para pesquisas de recursos antes de fazer algum investimento.

The post Tipos de cargas dos bancos de dados first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/09/16/tipos-de-cargas-dos-bancos-de-dados/feed/ 0 8513 Catálogo do sistema (pg_catalog) https://savepoint.blog.br/2024/09/09/catalogo-do-sistema-pg_catalog/ https://savepoint.blog.br/2024/09/09/catalogo-do-sistema-pg_catalog/#respond Mon, 09 Sep 2024 16:27:59 +0000 https://savepoint.blog.br/?p=8501 Introdução O pg_catalog é um schema especial no PostgreSQL que guarda todos os segredos do seu banco de dados. Quer saber como suas tabelas são organizadas? Lá podemos encontrar essa e outras respostas. Neste artigo, vamos dar uma olhada nesse recurso, descobrindo como ele funciona, o que você pode encontrar nele e como pode ser

The post Catálogo do sistema (pg_catalog) first appeared on Savepoint.

]]> Introdução

O pg_catalog é um schema especial no PostgreSQL que guarda todos os segredos do seu banco de dados. Quer saber como suas tabelas são organizadas? Lá podemos encontrar essa e outras respostas.

Neste artigo, vamos dar uma olhada nesse recurso, descobrindo como ele funciona, o que você pode encontrar nele e como pode ser útil para você.

Roteiro:

  • O que é o pg_catalog?
  • Principais tabelas e views do cátalogo;
  • Exemplos de junções de tabelas do catálogo;
  • Information schema;
  • Objetos físicos e lógicos;
  • Objetos globais e locais.

O que é?

Como dito anteriormente, o pg_catalog é um schema interno e padrão do PostgreSQL que guarda o catálogo do sistema, que nada mais é do que um conjunto de tabelas que contém metadados sobre o banco de dados. Essas tabelas registram informações cruciais, como a estrutura das tabelas, índices, tipos de dados, usuários e permissões.

Todos os bancos de dados do PostgreSQL possuem essas tabelas, pois, no momento da criação de um novo banco, elas são copiadas de um template (modelo), que vem dos bancos padrão template0 e template1 (existem dois desses, pois em um é possível fazer modificações, e no outro, não, o que garante uma cópia de segurança do template).

Abaixo seguem visualizações de consultas dos bancos de dados existentes, em que podemos ver o template0 e template1. Primeiro, vamos consultar de uma forma já ensinada no artigo de psql, com o comando \l (as três últimas colunas da saída foram ocultadas para melhor visualização):

psql shell: consultando os bancos de dados pelo comando \l
postgres@postgres# \l
                                   List of databases
     Name      |    Owner     | Encoding | Locale Provider | Collate |  Ctype  |   
---------------+--------------+----------+-----------------+---------+---------+
 aplicacao     | app_admin    | UTF8     | libc            | C.UTF-8 | C.UTF-8 |             
 pagila        | admin_pagila | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 postgres      | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 template0     | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 template1     | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 | 
(5 rows)

Agora, vamos consultar pela tabela pg_database, a qual compõe o catálogo do sistema:

psql shell: consultando os bancos de dados pela tabela pg_database
[local]: postgres@postgres=# SELECT datname FROM pg_database;
  datname
-----------
 postgres
 template1
 template0
 pagila
 aplicacao
(5 rows)

Apesar de, na prática, parecerem comandos diferentes, por baixo dos panos ambos fazem a mesma coisa, que é a consulta da tabela pg_database. Para observar isso, podemos ativar a variável ECHO_HIDDEN, que mostra as consultas realizadas nos comandos do psql. Para ativar, basta rodar:

psql shell: ativando a variável ECHO_HIDDEN
[local]: postgres@postgres=# \set ECHO_HIDDEN on

E, então, executar o \l novamente e, assim, vermos o que é feito de forma oculta para nos trazer a listagem de banco de dados:

psql shell: consultando os bancos de dados com o comando \l e visualizando a query executada
[local]: postgres@postgres=# \l
********* QUERY **********
SELECT
  d.datname as "Name",
  pg_catalog.pg_get_userbyid(d.datdba) as "Owner",
  pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
  CASE d.datlocprovider WHEN 'c' THEN 'libc' WHEN 'i' THEN 'icu' END AS "Locale Provider",
  d.datcollate as "Collate",
  d.datctype as "Ctype",
  d.daticulocale as "ICU Locale",
  d.daticurules as "ICU Rules",
  pg_catalog.array_to_string(d.datacl, E'\n') AS "Access privileges"
FROM pg_catalog.pg_database d
ORDER BY 1;
**************************
                                                      List of databases
   Name    |    Owner     | Encoding | Locale Provider | Collate |  Ctype  | 
 ---------+--------------+----------+-----------------+---------+----------+
 aplicacao | app_admin    | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 pagila    | admin_pagila | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 postgres  | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 | 
 template0 | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
 template1 | postgres     | UTF8     | libc            | C.UTF-8 | C.UTF-8 |
(5 rows)

A variável ECHO_HIDDEN também pode ser usada dessa forma para os diversos outros comandos do psql, possibilitando a visibilidade da importância dos dados presentes nas tabelas do catálogo do sistema. Recomendamos que teste sem moderação!

Principais tabelas e views do catálogo

pg_authid

Essa tabela armazena informações sobre os usuários de autenticação (no PostgreSQL utilizamos o termo “roles” em inglês tanto para usuários como para grupos de usuários). Ela contém detalhes como nome de usuário, tipo de papel (usuário ou grupo), senha criptografada (se aplicável) e outras informações relacionadas à autenticação e a permissões de acesso. Você pode acessar a documentação dessa tabela por aqui. Entre as principais colunas, temos:

  • rolname: nome do usuário ou grupo de usuários;
  • rolsuper: indica se o usuário tem privilégios de superusuário;
  • rolcreaterole: indica se o usuário tem o privilégio para criar outros usuários ou grupos;
  • rolcreatedb: indica se o usuário pode criar bancos de dados;
  • rolcanlogin: mostra se o usuário pode efetuar login como um usuário ou se apenas se comporta como um grupo de usuários;
  • rolreplication: indica se o usuário pode ser usado para replicação de dados.

pg_roles

Essa view do sistema também usa dados da tabela pg_authid para fornecer informações sobre todas as roles (usuários e grupo de usuários) do banco de dados, a diferença é a ocultação completa da senha (na outra vemos ela criptografada). A documentação oficial pode ser acessada aqui.

pg_database

Essa tabela contém uma linha para cada banco de dados no sistema PostgreSQL. Ela armazena várias informações importantes sobre cada banco, incluindo seu nome, dono e configurações específicas. Sua documentação oficial pode ser encontrada aqui. As principais colunas são:

  • datname: nome do banco de dados;
  • datdba: OID (Object Identifier ou Identificador de Objeto) do dono do banco de dados (esse OID fica na tabela pg_authid, que vimos anteriormente);
  • encoding: codificação de caracteres do banco de dados;
  • datctype: tipo de caracteres padrão do banco de dados;
  • datistemplate: indica se o banco de dados pode ser usado como um template (modelo), conforme os bancos template0 e template1;
  • datallowconn: indica se conexões ao banco de dados são permitidas, uma vez que, por padrão, não são permitidas conexões no template0;
  • datconnlimit: limite máximo de conexões ao banco de dados;
  • dattablespace: OID da tablespace em que o banco está;
  • datacl: lista de controle de acesso do banco de dados.

pg_namespace 

Essa tabela armazena informações sobre os schemas no banco de dados. Os schemas são usados para organizar objetos como tabelas, índices, funções etc. no PostgreSQL, fornecendo uma estrutura lógica de organização e controle de permissões como se fosse pastas no banco de dados. A documentação oficial pode ser conferida aqui. As colunas dessa tabela são:

  • oid: identificador do schema;
  • nspname: nome do schema;
  • nspowner: OID do usuário dono do schema (faz ponte com a tabela pg_authid);
  • nspacl: lista o controle de acesso do schema.

pg_class

Nessa tabela, temos diversas informações sobre tabelas e outros objetos similares (como views, índices etc.). É possível ver uma descrição de cada coluna dessa tabela aqui na documentação oficial. Algumas das colunas que destacamos são:  

  • oid: número identificador do objeto;
  • relname: nome do objeto;
  • relnamespace: OID (identificador) do schema ao qual esse objeto pertence (referência pg_namespace);
  • relowner: OID do dono do objeto (referência pg_authid);
  • relfilenode: número identificador do arquivo físico que armazena o objeto em questão (que geralmente é igual ao OID, citado no início da lista. Citaremos adiante um caso em que eles não são iguais);
  • reltablespace: OID do tablespace onde o objeto está armazenado. Se for 0, o objeto está no tablespace padrão do banco de dados (referência pg_tablespace);
  • relpages: número de páginas de disco usado pelo objeto (cada página tem por padrão 8 kb, e se o objeto for maior do que isso, ocupará múltiplos desse valor em número de páginas. Por exemplo, um objeto de 36 kb ocupará 5 páginas, não 4,5);
  • reltuples: número de linhas na tabela;
  • relkind: uma letra que indica o tipo do objeto:
    • r = tabela, 
    • i = índice 
    • s = sequência etc.
  • relacl: lista de controle de acesso do objeto, ou seja, mostra os usuários e suas permissões de acesso ao objeto;
  • reloptions: opções de ajustes para otimização de objetos.

pg_attribute

Armazena informações sobre cada atributo, ou seja, a coluna, de todas as tabelas do banco de dados, incluindo nome das colunas, tipo de dados, restrições etc. A documentação oficial está aqui. Suas principais colunas são:

  • attrelid: o OID da tabela ao qual essa coluna pertence (referência pg_class);
  • attname: o nome da coluna;
  • attypid: o OID do tipo de dado dessa coluna (referência pg_type);
  • attnotnull: indica se a coluna foi definida como ‘NOT NULL’;
  • atthasdef: indica se a coluna tem valor padrão definido.

pg_type

Nessa tabela, encontramos informações sobre os tipos de dados do banco, que podem ser de tabelas, colunas etc. Sua documentação está nessa página. As principais colunas são:

  • typname: nome do tipo de dado;
  • typnamespace: OID do schema que contém o tipo de dado em questão (referência pg_namespace);
  • typlen: tamanho em bytes do tipo de dado;
  • typtype: indica o tipo de dado, ou seja, muda conforme o objeto ao qual está se referenciando, sendo b para tipo base, c para tipo composto (o caso das tabelas), d para domínio etc.

pg_constraints

Essa tabela armazena informações sobre as restrições (constraints) definidas em diferentes objetos do banco de dados, como tabelas. As restrições são regras que impõem integridade de dados e outras condições para garantir que os dados no banco de dados estejam consistentes e de acordo com as regras de negócio. A documentação oficial está aqui. Principais colunas:

  • conname: nome da constraint;
  • connamespace: OID do esquema ao qual a constraint pertence (referente a pg_namespace);
  • contype: tipo da restrição, como PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK etc.;
  • conrelid: OID da tabela à qual a restrição está associada (referente a pg_class).

pg_proc

Essa tabela armazena informações sobre as funções e os procedimentos (functions e procedures em inglês) definidos no banco de dados. Sua documentação está aqui. Algumas das principais colunas são:

  • proname: nome da função;
  • prolang: linguagem na qual a função é escrita (referente a pg_language);
  • prorettype: tipo de retorno da função (referente a pg_type);
  • proargtypes: tipos dos argumentos da função (referente a pg_type).

pg_sequence

Armazena informações sobre as sequências definidas no banco de dados. Sequências são objetos especiais usados para gerar números únicos e sequenciais, frequentemente utilizados para colunas de chave primária artificiais. A documentação pode ser achada aqui. Suas colunas são:

  • seqrelid: OID (identificador) do objeto da sequência em questão (referente a pg_class);
  • seqtypid: tipo de dados da sequência, por exemplo, integer, bigint etc. (referente a pg_type);
  • seqstart: valor inicial da sequência;
  • seqincrement: incremento da sequência;
  • seqcache: número de valores da sequência a serem cacheados (colocados em cache);
  • seqcycle: indica se a sequência cicla ao atingir o valor máximo/mínimo (t para TRUE/f para FALSE).

pg_stats

Essa view fornece um acesso mais amigável às estatísticas armazenadas na tabela pg_statistic, que conta com estatísticas sobre o conteúdo de cada coluna de cada tabela do banco. Essas estatísticas são usadas pelo otimizador de consultas para gerar planos de execução eficientes. A documentação oficial está nesta página, já a página da pg_statistic você encontra aqui. As principais colunas da pg_stats são:

  • schemaname: nome do esquema da tabela;
  • tablename: nome da tabela;
  • attname: nome da coluna;
  • avg_width: largura média dos valores da coluna (em bytes);
  • most_common_vals: valores mais comuns na coluna;
  • most_common_freqs: frequências dos valores mais comuns.

pg_settings

Essa view nos permite visualizar parâmetros de tempo de execução do servidor, ou seja, nos permite visualizar e modificar parâmetros de configuração em tempo real. A documentação pode ser encontrada aqui. Além disso, temos um artigo antigo sobre configurações do PostgreSQL citando essa tabela, podendo ser interessante para ver exemplos.
Suas principais colunas são:

  • name: nome do parâmetro;
  • setting: valor atual do parâmetro;
  • category: grupo lógico do parâmetro;
  • short_desc: descrição resumida do parâmetro.

Exemplos de junção (JOIN) de tabelas do catálogo

Tabelas pg_database e pg_authid

Abaixo temos um exemplo que nos mostra os seguintes dados:

  • Tabela pg_database:
    • OID e nome do banco;
    • OID do usuário dono do banco.
  • Tabela pg_authid:
    • Nome do usuário em questão.
psql shell: consultando dados das tabelas pg_database e pg_authid
[local]: postgres@postgres=# SELECT 
d.oid, 
d.datname, 
d.datdba, 
a.rolname 
FROM pg_database d 
JOIN pg_authid a ON d.datdba = a.oid;

  oid  |      datname      | datdba |   rolname
-------+-------------------+--------+--------------
 18206 | readme_to_recover |     10 | postgres
 18203 | banco_tblspc      |     10 | postgres
     4 | template0         |     10 | postgres
     1 | template1         |     10 | postgres
     5 | postgres          |     10 | postgres
 16539 | aplicacao         |  16520 | app_admin
 17660 | pagila            |  17189 | admin_pagila
(7 rows)

Tabelas pg_class, pg_attribute e pg_type

Agora, vamos ver uma junção com os dados de tabelas, colunas da tabela e tipos de dados:

  • Tabela pg_class:
    • OID e nome do objeto;
    • OID do tipo de dado na tabela pg_type.
  • Tabela pg_attribute:
    • Número da coluna (posição dela em relação à tabela);
    • Nome da coluna.
  • Tabela pg_type:
    • Nome do tipo de dado;
    • Tipo de dado do dado, que varia conforme o objeto em questão. Aqui vamos utilizar a cláusula CASE WHEN para nomear os objetos tipo base explicitamente.
psql shell: consultando dados das tabelas pg_class, pg_attribute e pg_type
SELECT
    c.oid AS oid_tab,
    c.relname AS nome_tab,
    a.attnum AS num_col,
    a.attname AS nome_col,
    t.oid AS oid_tipo,
    t.typname AS nome_tipo,
    CASE
        WHEN t.typtype = 'b' THEN 'tipo base'
        END AS tipo
FROM pg_class c
JOIN pg_attribute a ON c.oid = a.attrelid
JOIN pg_type t ON a.atttypid = t.oid
WHERE 
c.relname = 'pg_class' 
AND a.attnum > 0
ORDER BY 
c.relname, 
a.attnum;

    oid_tab |   nome_tab  | num_col  |   nome_col  | oid_tipo |nome_tipo |   tipo
------------+-------------+------------+---------------------+----------+------------+
       1259 | pg_class    |        1 | oid         |       26 | oid      | tipo base
       1259 | pg_class    |        2 | relname     |       19 | name     | tipo base
       1259 | pg_class    |        3 |relnamespace |       26 | oid      | tipo base
       1259 | pg_class    |        4 | reltype     |       26 | oid      | tipo base
       1259 | pg_class    |        5 | reloftype   |       26 | oid      | tipo base
       1259 | pg_class    |        6 | relowner    |       26 | oid      | tipo base
       1259 | pg_class    |        7 | relam       |       26 | oid      | tipo base
       1259 | pg_class    |        8 | relfilenode |       26 | oid      | tipo base
       1259 | pg_class    |        9 |reltablespace|       26 | oid      | tipo base
       ...

information_schema

O information_schema é um schema padronizado definido pelo ISO que fornece uma maneira portável e independente do fornecedor do banco de dados para se obter informações sobre os objetos do banco de dados, assim como o pg_catalog, rodando, na verdade, em cima dele, utilizando-o como fonte de dados. Esse schema é também suportado por muitos outros sistemas de gerenciamento de banco de dados (SGBDs). A documentação oficial do PostgreSQL pode ser encontrada aqui.

Assim como através das tabelas do catálogo, aqui podemos listar todas as tabelas de um determinado schema utilizando uma tabela do information_schema:

psql shell: consultando dados do information_schema
localhost: dba@aplicacao=# SELECT 
table_schema, 
table_name 
FROM information_schema.tables 
ORDER BY table_schema;

    table_schema    |              table_name
--------------------+---------------------------------------
 information_schema | collations
 information_schema | information_schema_catalog_name
 information_schema | applicable_roles
 information_schema | domain_constraints
 information_schema | administrable_role_authorizations
 information_schema | collation_character_set_applicability
 information_schema | attributes
 information_schema | character_sets
 information_schema | column_udt_usage
 information_schema | check_constraint_routine_usage
 information_schema | column_column_usage
...

As principais diferenças entre o information_schema e o pg_catalog são:

  • Padrão: conforme citado, o information_schema segue o padrão ISO SQL e é compatível com diversos outros servidores, já o pg_catalog é específico do PostgreSQL;
  • Nomenclaturas: como o information_schema segue o padrão ISO SQL, é notável que seus objetos têm nomenclaturas mais simples e explícitas, diferente do pg_catalog, em que há termos mais técnicos e específicos do Postgres;
  • Nível de detalhe: o information_schema fornece uma visão mais simplificada dos metadados do banco, enquanto o pg_catalog traz informações mais específicas e de baixo nível sobre os objetos do banco de dados;
  • Informações sensíveis: no pg_catalog é possível encontrar informações sensíveis, por isso é um schema mais utilizado pelos DBAs, ao passo que o information_schema foi projetado para acesso público, ocultando informações sensíveis como senhas.

A seguir, está uma maneira de listar todas as tabelas do information_schema (informação que pode ser encontrada na documentação disponibilizada anteriormente) utilizando o pg_catalog:

psql shell: consultando informações do information_schema por tabelas do catálogo (pg_class e pg_namespace)
localhost: dba@aplicacao=# SELECT 
c.relname AS table_name 
FROM pg_class c 
JOIN pg_namespace n ON n.oid = c.relnamespace 
WHERE 
n.nspname = 'information_schema' 
AND c.relkind = 'v' 
ORDER BY c.relname;

              table_name
---------------------------------------
 administrable_role_authorizations
 applicable_roles
 attributes
 character_sets
 check_constraint_routine_usage
 check_constraints
 collation_character_set_applicability
 collations
 column_column_usage
 column_domain_usage
 column_options
 column_privileges
 column_udt_usage
 columns
 constraint_column_usage
 constraint_table_usage
 data_type_privileges
...

Objetos físicos e lógicos

Objetos físicos referem-se aos componentes do banco de dados que têm representação física no sistema de arquivos do PostgreSQL, ou seja, além de estarem presentes no banco, também são representados por arquivos em disco. Alguns dos principais objetos físicos são:

  • Tabelas (incluindo, portanto, as do catálogo);
  • Ínidices;
  • Tablespaces;
  • Databases etc.

Podemos encontrar esses objetos nas pastas nomeadas base e global, a depender de serem globais ou locais. Mas não se preocupe, no próximo tópico do artigo, explicaremos mais sobre objetos globais e locais.
Abaixo, seguem exemplos de arquivos de objetos, que são nomeados com números, presentes no diretório global no PGDATA: 

Debain shell: listando arquivos e diretórios do diretório global
$ ls -lha $PGDATA/global
total 644K
drwx------  2 postgres postgres 4.0K May 23 17:56 .
drwx------ 19 postgres postgres 4.0K Apr  9 18:41 ..
...
-rw-------  1 postgres postgres 8.0K May 16 14:44 1260
-rw-------  1 postgres postgres  24K Mar 27 15:39 1260_fsm
-rw-------  1 postgres postgres 8.0K Mar 27 15:49 1260_vm
-rw-------  1 postgres postgres 8.0K May 13 19:14 1261
-rw-------  1 postgres postgres  24K Mar 27 15:39 1261_fsm
-rw-------  1 postgres postgres 8.0K Apr 22 15:11 1261_vm
-rw-------  1 postgres postgres 8.0K Jun  4 19:45 1262
...
-rw-------  1 postgres postgres 8.0K Jun  4 19:45 pg_control
-rw-------  1 postgres postgres  524 Mar 27 15:39 pg_filenode.map
-rw-------  1 postgres postgres  29K May 23 17:56 pg_internal.init

A seguir, estão os arquivos dos objetos que se encontram no diretório base, também no PGDATA:

Debian shell: listando arquivos e diretórios do diretório base
# ls -lha $PGDATA/base
total 76K
drwx------ 11 postgres postgres 4.0K Jun  4 19:40 .
drwx------ 19 postgres postgres 4.0K Apr  9 18:41 ..
drwx------  2 postgres postgres 4.0K May 13 18:50 1
drwx------  2 postgres postgres 4.0K Apr  9 19:11 16398
drwx------  2 postgres postgres  12K Apr 15 18:50 16449
drwx------  2 postgres postgres  12K May 23 17:55 16539
drwx------  2 postgres postgres 4.0K May  8 13:46 16645
drwx------  2 postgres postgres  12K May 16 12:37 17660
drwx------  2 postgres postgres 4.0K Mar 27 15:39 4
drwx------  2 postgres postgres  12K May 23 18:05 5
drwx------  2 postgres postgres 4.0K May 23 17:55 pgsql_tmp

Já os objetos lógicos são abstrações que não têm uma representação física direta no sistema de arquivos, mas são gerenciadas pelo PostgreSQL. Alguns desses objetos são schemas, views, funções etc.

Objetos globais e locais

Objetos globais são aqueles que não pertencem a um banco de dados específico e podem ser acessados por qualquer banco de dados de uma instância no PostgreSQL. É possível encontrá-los no diretório global no PGDATA, que vimos antes: 

Debian shell: listando arquivos e diretórios do diretório global, com ênfase no arquivo 1262
$ ls -lha $PGDATA/global
total 644K
drwx------  2 postgres postgres 4.0K May 23 17:56 .
drwx------ 19 postgres postgres 4.0K Apr  9 18:41 ..
...
-rw-------  1 postgres postgres 8.0K May 16 14:44 1260
-rw-------  1 postgres postgres  24K Mar 27 15:39 1260_fsm
-rw-------  1 postgres postgres 8.0K Mar 27 15:49 1260_vm
-rw-------  1 postgres postgres 8.0K May 13 19:14 1261
-rw-------  1 postgres postgres  24K Mar 27 15:39 1261_fsm
-rw-------  1 postgres postgres 8.0K Apr 22 15:11 1261_vm
-rw-------  1 postgres postgres 8.0K Jun  4 19:45 1262
...
-rw-------  1 postgres postgres 8.0K Jun  4 19:45 pg_control
-rw-------  1 postgres postgres  524 Mar 27 15:39 pg_filenode.map
-rw-------  1 postgres postgres  29K May 23 17:56 pg_internal.init

É importante notar que os nomes dos arquivos não são números aleatórios: geralmente eles são o mesmo número OID do objeto em questão. Por exemplo, nesta saída temos o arquivo 1262 e, através de uma consulta a uma tabela do catálogo do sistema no psql, a pg_class (nela é possível encontrar informações de alguns objetos do banco de dados, como tabelas, índices, views etc.), e buscando pelo OID 1262, é possível descobrir que esse arquivo representa a tabela pg_database, conforme saída da consulta a seguir:

psql shell: consultando informações do objeto global 1262
postgres@postgres=# SELECT 
oid,
relname 
FROM pg_class 
WHERE oid = 1262;

 oid  |   relname
------+-------------
 1262 | pg_database
(1 row)

Nessa consulta, utilizamos as colunas relisshared e relkind como filtro para encontrar as tabelas do catálogo na tabela pg_class. Isso porque a coluna relisshared é de valor booleano, sendo verdadeira para indicar uma tabela global (do catálogo do sistema), e a coluna relkind traz o tipo de objeto, sendo ‘r’ representativo de tabelas. A seguir podemos ver outras tabelas globais do catálogo pela pg_class:

psql shell: consultando as tabelas do catálogo utilizando a tabela pg_class
postgres@postgres=# SELECT 
oid,
relname 
FROM pg_class 
WHERE 
relisshared 
AND relkind = 'r';

 oid  |        relname
------+-----------------------
 1260 | pg_authid
 6100 | pg_subscription
 1262 | pg_database
 2964 | pg_db_role_setting
 1213 | pg_tablespace
 1261 | pg_auth_members
 1214 | pg_shdepend
 2396 | pg_shdescription
 6000 | pg_replication_origin
 3592 | pg_shseclabel
 6243 | pg_parameter_acl
(11 rows)

Outro exemplo de objeto global são as tablespaces, que são locais de armazenamento que contêm dados de bancos PostgreSQL fora do diretório base, o PGDATA. Aqui criamos uma chamada novaTablespace e um banco de dados dentro dela, chamado banco_tblspc.

Além do local onde a tablespace foi criada, também podemos encontrá-la via link simbólico no caminho $PGDATA/pg_tblspc/: 

Debian shell: listando a tablespace criada
# ls -l $PGDATA/pg_tblspc/
total 0
lrwxrwxrwx 1 postgres postgres 26 Jun 11 17:22 18202 -> /var/lib/postgresql/tblspc

Dentro dela, temos mais um diretório, que abriga o nosso banco recém-criado:

Debian shell: listandso os diretórios da tablespace criada
# ls -lha $PGDATA/pg_tblspc/18202
drwx------ 3 postgres postgres 4.0K Jun 11 17:22 .
drwxr-xr-x 6 postgres postgres 4.0K Jun 11 17:34 ..
drwx------ 3 postgres postgres 4.0K Jun 11 17:34 PG_16_202307071

Então, chegamos no diretório oficial do banco, que vai abrigar os objetos criados nele:

Debian shell: listando dados do diretório do banco criado
# ls -lha $PGDATA/pg_tblspc/18202/PG_16_202307071/
total 12K
drwx------ 3 postgres postgres 4.0K Jun 11 17:34 .
drwx------ 3 postgres postgres 4.0K Jun 11 17:22 ..
drwx------ 2 postgres postgres 4.0K Jun 11 17:34 18203

O número que nomeia o arquivo do banco também é o OID desse objeto, o que facilita encontrá-lo na pg_database, por exemplo:

psql shell: consultando dados do objeto que representa o banco criado no catálogo do sistema
[local]: postgres@postgres=# SELECT * FROM pg_database WHERE oid = 18203;
-[ RECORD 1 ]--+-------------
oid            | 18203
datname        | banco_tblspc
datdba         | 10
encoding       | 6
datlocprovider | c
datistemplate  | f
datallowconn   | t
datconnlimit   | -1
datfrozenxid   | 722
datminmxid     | 1
dattablespace  | 18202
datcollate     | C.UTF-8
datctype       | C.UTF-8
daticulocale   | (null)
daticurules    | (null)
datcollversion | (null)
datacl         | (null)

E também podemos encontrar nossa tablespace na tabela pg_tablespace:

psql shell: consultando a tablespace criada no catálogo do sistema
[local]: postgres@postgres=# select * from pg_tablespace;
  oid  |    spcname     | spcowner | spcacl | spcoptions
-------+----------------+----------+--------+------------
  1663 | pg_default     |       10 | (null) | (null)
  1664 | pg_global      |       10 | (null) | (null)
 18202 | novatablespace |       10 | (null) | (null)
(3 rows)

Já os locais são objetos pertencentes a um banco de dados específico e só podem ser acessados dentro desse banco. Ficam no diretório base, no PGDATA. A seguir, podemos ver a listagem de arquivos desse diretório:

Debian shell: listando objetos locais no diretório base
# ls -lha $PGDATA/base
total 72K
drwx------ 10 postgres postgres 4.0K Jun  6 03:44 .
drwx------ 19 postgres postgres 4.0K Apr  9 18:41 ..
drwx------  2 postgres postgres 4.0K May 13 18:50 1
drwx------  2 postgres postgres  12K Apr 15 18:50 16449
drwx------  2 postgres postgres  12K May 23 17:55 16539
drwx------  2 postgres postgres 4.0K May  8 13:46 16645
drwx------  2 postgres postgres  12K May 16 12:37 17660
drwx------  2 postgres postgres 4.0K Mar 27 15:39 4
drwx------  2 postgres postgres  12K May 23 18:05 5
drwx------  2 postgres postgres 4.0K May 23 17:55 pgsql_tmp

Ao entrar nesse diretório, diferente da global em que já vemos os arquivos dos objetos, temos mais um nível de diretórios representando cada banco de dados existente na instância do PostgreSQL, e é dentro de cada um deles que estão armazenados os objetos locais do banco. É possível checar a qual banco de dados cada diretório é referente consultando a tabela pg_database, novamente usando os OIDs de cada objeto para identificá-los:

psql shell: consultando dados dos bancos de dados
postgres@postgres=# SELECT oid, datname FROM pg_database;
  oid  |  datname
-------+-----------
     5 | postgres
     1 | template1
     4 | template0
 17660 | pagila
 16539 | aplicacao
(5 rows)

Vamos listar os arquivos do diretório do banco criado há alguns artigos, o aplicacao, diretório 16539:

Debian shell: listando arquivos do diretório do objeto 16539
# ls -lha $PGDATA/base/16539/
total 7.9M
drwx------ 2 postgres postgres  12K May 23 17:55 .
drwx------ 8 postgres postgres 4.0K Jun  6 03:56 ..
-rw------- 1 postgres postgres 8.0K Apr 22 15:41 112
...
-rw------- 1 postgres postgres 8.0K May 10 12:49 16649
-rw------- 1 postgres postgres 8.0K May  8 17:43 16656
-rw------- 1 postgres postgres  16K May  8 17:43 16660
-rw------- 1 postgres postgres 8.0K May 16 12:14 16662
-rw------- 1 postgres postgres 8.0K May 16 12:14 16663
-rw------- 1 postgres postgres  16K May 16 12:14 16667
-rw------- 1 postgres postgres 8.0K May  8 17:43 16690
-rw------- 1 postgres postgres 8.0K May  9 13:44 16691
-rw------- 1 postgres postgres  16K May  8 17:43 16695
-rw------- 1 postgres postgres 8.0K May  8 17:43 16697
-rw------- 1 postgres postgres 8.0K May  8 17:43 16698
-rw------- 1 postgres postgres  16K May  8 17:43 16702
-rw------- 1 postgres postgres 8.0K May  8 17:43 16704
-rw------- 1 postgres postgres 8.0K May  8 17:43 16705
-rw------- 1 postgres postgres  16K May  8 17:43 16709
-rw------- 1 postgres postgres 8.0K Apr 22 15:41 174
-rw------- 1 postgres postgres 8.0K Apr 22 15:41 175
-rw------- 1 postgres postgres 8.0K May 16 12:39 18131
-rw------- 1 postgres postgres 8.0K May 16 12:39 18132
-rw------- 1 postgres postgres  16K May 16 12:39 18136
-rw------- 1 postgres postgres 8.0K May 16 12:44 18140
-rw------- 1 postgres postgres 8.0K May 16 12:44 18141
-rw------- 1 postgres postgres  16K May 16 12:44 18145
-rw------- 1 postgres postgres 8.0K May 16 14:39 18148
-rw------- 1 postgres postgres 8.0K May 16 14:39 18149
-rw------- 1 postgres postgres  16K May 16 14:39 18153
...
-rw------- 1 postgres postgres    3 Apr 22 15:40 PG_VERSION
-rw------- 1 postgres postgres  524 Apr 22 15:40 pg_filenode.map
-rw------- 1 postgres postgres 156K May 23 17:55 pg_internal.init

A consulta realizada para encontrar o objeto correspondente no catálogo do psql (conectando agora no próprio banco de dados aplicacao) foi:

psql shell: consultando dados dos objetos do banco aplicacao (16539)
dba@aplicacao=#  SELECT 
oid,
relname 
FROM pg_class 
WHERE NOT relisshared AND relkind = 'r' AND relname LIKE '%tabela%';

  oid  |   relname
-------+--------------
 18149 | tabela6_app1
 16691 | tabela1_app2
 16656 | tabela2_app1
 16663 | tabela3_app1
 16698 | tabela2_app2
 16705 | tabela3_app2
 16649 | tabela1_app1
 18132 | tabela4_app1
 18141 | tabela5_app1
(9 rows)

Aqui, podemos ver os OIDs de todas as tabelas desse banco, que também são identificáveis como arquivos na nossa consulta no diretório 16539 (banco aplicacao).
Entre os demais arquivos nesse diretório, temos outras tabelas do catálogo, índices, schemas etc.

Mas e quando os OIDs de tabelas não são iguais aos números que nomeiam seus arquivos? Um dos casos é quando utilizamos o comando TRUNCATE, que serve para remover todas as linhas de uma tabela e também pode mudar o relfilenode, já que o PostgreSQL pode optar por recriar fisicamente a tabela para otimização da operação.

Confira uma consulta dos dados da tabela na pg_class antes do TRUNCATE:

psql shell: consultando dados de uma tabela na pg_class
localhost: dba@aplicacao=# SELECT 
oid, 
relname, 
relfilenode 
FROM pg_class 
WHERE relname = 'tabela1_app1';

  oid  |   relname    | relfilenode
-------+--------------+-------------
 16649 | tabela1_app1 |       16649
(1 row)

Execução do TRUNCATE:

psql shell: executando TRUNCATE na tabela tabela1_app1
localhost: dba@aplicacao=# TRUNCATE TABLE aplicacao1.tabela1_app1;
TRUNCATE TABLE

Nova consulta dos dados da tabela na pg_class, após o TRUNCATE:

psql shell: consultando dados de uma tabela no pg_class após TRUNCATE
localhost: dba@aplicacao=# SELECT 
oid, 
relname, 
relfilenode 
FROM pg_class 
WHERE relname = 'tabela1_app1';

  oid  |   relname    | relfilenode
-------+--------------+-------------
 16649 | tabela1_app1 |       18204
(1 row)

Isso implica termos um novo arquivo para representar essa tabela no diretório do banco de dados, nomeado com a numeração do novo relfilenode:

Debian shell: listando arquivos do diretório do banco de dados após TRUNCATE (novo arquivo 18204)
$ ls -lha $PGDATA/base/16539/
total 7.9M
drwx------ 2 postgres postgres  12K Jun 11 18:28 .
drwx------ 8 postgres postgres 4.0K Jun  6 03:56 ..
...
-rw------- 1 postgres postgres    0 Jun 11 18:25 18204
...
-rw------- 1 postgres postgres    3 Apr 22 15:40 PG_VERSION
-rw------- 1 postgres postgres  524 Apr 22 15:40 pg_filenode.map
-rw------- 1 postgres postgres 156K Jun 11 18:27 pg_internal.init

Conclusão

Exploramos o pg_catalog, um componente crucial do PostgreSQL que armazena metadados essenciais para a administração do banco de dados. Compreender tabelas e views como pg_authid, pg_database e pg_class permite realizar auditorias, otimizações e controle de acessos com eficácia.

O uso de comandos como \l e a variável ECHO_HIDDEN desmistifica operações internas, proporcionando maior controle e entendimento. O pg_catalog é uma ferramenta poderosa que garante a integridade e a performance do seu sistema de banco de dados, o que é essencial para qualquer DBA ou desenvolvedor.

The post Catálogo do sistema (pg_catalog) first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/09/09/catalogo-do-sistema-pg_catalog/feed/ 0 8501 Arquivos, diretórios e processos no PostgreSQL https://savepoint.blog.br/2024/09/02/arquivos-diretorios-e-processos/ https://savepoint.blog.br/2024/09/02/arquivos-diretorios-e-processos/#respond Mon, 02 Sep 2024 18:11:23 +0000 https://savepoint.blog.br/?p=8486 Introdução No PostgreSQL, a organização de arquivos e diretórios, bem como a gestão de processos, são componentes fundamentais para entender o seu funcionamento. Este artigo fornecerá uma visão geral de como o PostgreSQL estrutura seus dados e controla seus processos. Roteiro: Arquivos e diretórios dos dados no PostgreSQL O PostgreSQL organiza seus dados e configurações

The post Arquivos, diretórios e processos no PostgreSQL first appeared on Savepoint.

]]> Introdução

No PostgreSQL, a organização de arquivos e diretórios, bem como a gestão de processos, são componentes fundamentais para entender o seu funcionamento. Este artigo fornecerá uma visão geral de como o PostgreSQL estrutura seus dados e controla seus processos.

Roteiro:

  • Arquivos e diretórios dos dados no PostgreSQL:
    • Binários
    • Arquivos de configuração
    • Arquivos de logs
    • Subdiretórios
  • Processos

Arquivos e diretórios dos dados no PostgreSQL

O PostgreSQL organiza seus dados e configurações em uma estrutura de diretórios específica. A localização desses diretórios pode variar dependendo da instalação, mas geralmente segue um padrão. O diretório principal que contém todos os dados do PostgreSQL é o Base Directory (também conhecido pela variável de ambiente $PGDATA), que é definido durante a inicialização do cluster PostgreSQL com o comando initdb. Para sistemas Linux, o endereço de PGDATA pode variar conforme a distribuição:

  • Debian: /var/lib/postgresql/<versão>/<nome_do_cluster>
  • Red Hat: /var/lib/pgsql/<versão>/data

Claro, você pode definir qualquer diretório/disco/partição para colocar seus dados, como demonstramos nos artigos anteriores sobre instalação. Portanto é uma boa ideia usar a variável de ambiente $PGDATA (que, a depender da distribuição, já vem setada para o usuário postgres) ou então descobrir esse diretório pelo comando no psql SHOW data_directory:

psql shell: consultando o diretório de dados
$ psql -c 'SHOW data_directory;'
       data_directory
-----------------------------
 /var/lib/postgresql/16/main
(1 row)

Nesse diretório, temos arquivos e subdiretórios importantes para o programa, que veremos a seguir.

Binários

Dentre os principais arquivos do PostgreSQL, temos os binários, que são executáveis responsáveis por iniciar e interagir com o banco de dados. Eles estão em diferentes diretórios, que mudam conforme o sistema operacional. Considerando essas três distribuições Linux, podemos encontrar os principais binários em:

  • Debian:
    • /usr/share/postgresql-common: contém arquivos e scripts comuns utilizados por várias versões do PostgreSQL, por exemplo, pg_ctlcluster e pg_createcluster;
    • /usr/lib/postgresql/<sua_versão>/bin: neste diretório, você pode encontrar os binários específicos da versão do PostgreSQL, como o próprio psql, os utilitários createdb, initdb etc.
  • Red Hat:
    • /usr/pgsql/<versão>/bin/: guarda binários e executáveis específicos de cada versão do PostgreSQL.
  • Instalação via compilação:
    • /usr/local/pgsql/bin/

Arquivos de configuração

  • postgresql.conf: principal arquivo de configuração do servidor PostgreSQL. Contém parâmetros para ajustar o desempenho, a segurança, o comportamento e outras opções do servidor. Em distribuições Debian e derivados, este arquivo está em outro local, num diretório que agrega todos os arquivos de configuração: /etc/postgresql/<versão>/<nome_do_cluster>;
  • pg_hba.conf: configurações de autenticação do host. Define quem pode conectar-se ao banco de dados e como as conexões são autenticadas. Assim como antes, em distribuições Debian e derivados, este arquivo fica em outro local;
  • pg_ident.conf: mapeamentos para autenticação do tipo ident no pg_hba.conf. Usado para mapear nomes de usuários do sistema operacional para nomes de usuários do PostgreSQL. Mais uma vez, em distribuições Debian e derivados, este arquivo fica em outro local, vide acima;
  • postgresql.auto.conf: armazena as configurações definidas dinamicamente através do comando ALTER SYSTEM SET, bem como outras configurações definidas automaticamente pelo próprio PostgreSQL. Você não deve editar este arquivo manualmente!;
  • PG_VERSION: contém a versão do PostgreSQL em uso no cluster (major version);
  • postmaster.pid: contém o ID do processo (PID) do servidor PostgreSQL em execução e outras informações, como diretório de dados do cluster, data de início do processo etc.;
  • postmaster.opts: arquivo que registra as opções de linha de comando usadas por último na inicialização do servidor PostgreSQL.

Arquivos de logs

Dentro do $PGDATA, temos outros diretórios importantes que guardam arquivos do PostgreSQL, como os arquivos de log. Normalmente, os logs ficam em $PGDATA/logs, mas em distribuições Debian e derivadas eles estão localizados em /var/log/postgresql, como podemos ver na saída abaixo. 

Debian shell: logs do PostgreSQL
# ls -lh /var/log/postgresql/*
total 6.6M
drwxrwxr-t  2 root     postgres 4.0K May 19 00:00 .
drwxr-xr-x 10 root     root     4.0K May  1 00:00 ..
-rw-r-----  1 postgres adm      123K May 23 09:40 postgresql-16-main.log
-rw-r-----  1 postgres adm      6.0M May 19 00:00 postgresql-16-main.log.1
-rw-r-----  1 postgres adm      254K May 12 00:00 postgresql-16-main.log.2.gz
-rw-r-----  1 postgres adm       18K May  5 00:00 postgresql-16-main.log.3.gz
-rw-r-----  1 postgres adm      125K Apr 28 00:00 postgresql-16-main.log.4.gz
-rw-r-----  1 postgres adm       27K Apr 21 00:00 postgresql-16-main.log.5.gz
-rw-r-----  1 postgres adm       36K Apr 14 00:00 postgresql-16-main.log.6.gz
-rw-r-----  1 postgres adm      1.1K Apr  7 00:00 postgresql-16-main.log.7.gz
-rw-r-----  1 postgres adm      2.0K Mar 31 00:00 postgresql-16-main.log.8.gz

Na verdade, você pode escolher outros lugares arbitrários para colocar seus logs, como em um disco separado (pode ser útil em servidores com muita carga), ajustando a variável log_directory. Abaixo vemos um exemplo da localização do diretório de logs na AWS RDS:

psql: consultando o diretório de logs em um banco AWS RDS
SHOW log_directory;
    log_directory
----------------------
 /rdsdbdata/log/error

O valor do log_directory pode ser absoluto, com o path completo ou relativo ao diretório do $PGDATA.

Subdiretórios

  • base/: contém um subdiretório para cada banco de dados individual no cluster;
    • Dentro desses subdiretórios de cada banco que são identificados com números (16390, por exemplo) temos com os dados de cada objeto no banco, como tabelas e índice. Estes arquivos possuem eventualmente outros com o mesmo número e um sufixo _fsm (free space map) e _vm (visibility map), que são essenciais para manutenção e otimização e controle de transações. Além disso, temos um diretório chamado pgsql_tmp com arquivos temporários como tabelas temporárias. Eventualmente é possível armazenar estes arquivos temporários em outros tablespaces, ajustando a configuração temp_tablespaces;
  • global/: contém tabelas e dados globais, como informações sobre usuários e grupos, por exemplo, as tabelas pg_database e pg_control;
    • Aqui também temos os arquivos _fsm e _vm, mas a nível global, ou seja, que se aplicam a todos os bancos de dados em um cluster;
  • pg_xlog/ ou pg_wal/: contém os arquivos de log de transação (WAL – Write-Ahead Logging), essenciais para a recuperação de dados;
  • pg_clog/ ou pg_commit_ts/: mantém informações sobre o estado das transações atuais;
  • pg_stat/: armazena dados estatísticos permanentes utilizados para otimização de consultas;
  • pg_stat_tmp/: armazena dados estatísticos temporários utilizados para otimização de consultas;
  • pg_tblspc/: pontos de montagem de tablespaces, que permitem a administração de locais de armazenamento adicionais.

Processos

PostgreSQL é um sistema de gerenciamento de banco de dados do tipo cliente-servidor. Diferente de outros modelos, ele utiliza uma arquitetura multiprocesso para rodar em um único host. Imagine uma equipe trabalhando em conjunto para cuidar do seu banco de dados: esse é o conceito por trás dessa arquitetura.

Essa “equipe” é composta por diversos processos, cada um com uma função específica:

  • postmaster (server process): o processo principal do PostgreSQL. É responsável por iniciar, parar e supervisionar todos os processos de servidor do PostgreSQL. Ele recebe conexão de apenas uma porta (a 5432 por padrão), porém podemos ter mais de uma instância do PostgreSQL rodando no mesmo servidor, especificando uma porta para cada instância. Podemos ter, por exemplo, um PostgreSQL na versão 16 na porta 5432 e outro na versão 15 na porta 5433;
  • postgres (backend process): cada conexão ao banco de dados é gerenciada por um processo postgres dedicado. Esse processo é responsável por receber e executar as consultas e comandos enviados pelos clientes, garantindo uma experiência personalizada para cada um;
  • autovacuum launcher (background process): processo responsável pela limpeza automática do banco de dados, removendo registros obsoletos gerados por operações de UPDATE e DELETE;
  • wal writer (background process): gerencia a gravação dos logs de transação (WAL) no disco, garantindo a durabilidade das transações, o que permite a recuperação do banco de dados;
  • wal sender (background process): responsável por enviar os registros do WAL (Write-Ahead Logging) do servidor primário para um ou mais servidores de réplica (standby). Este processo é fundamental para a replicação em tempo real e a alta disponibilidade;
  • wal receiver (background process): é executado em servidores de réplica e recebe os registros do WAL enviados pelo processo WAL sender do servidor primário;
  • statistics collector (background process): é responsável por coletar e agrupar estatísticas sobre a operação do banco de dados, como contagem de linhas lidas, inseridas, atualizadas ou deletadas;
  • logging collector (background process): coleta e armazena mensagens de log do servidor PostgreSQL em arquivos de log;
  • archiver (background process): copia os arquivos do WAL para um local de arquivamento seguro após eles serem preenchidos;
  • bgwriter (background process): é o “background writer”, que periodicamente escreve páginas sujas da memória para o disco, ajudando a manter a consistência dos dados;
  • checkpointer (background process): periodicamente cria pontos de verificação (checkpoints) que ajudam na recuperação de falhas;
  • IPC (background process): os processos do PostgreSQL se comunicam usando IPC (Inter-Process Communication), que inclui sinais (signals), memória compartilhada (shared memory) e semáforos (semaphores). Estes mecanismos permitem a coordenação entre os processos, garantindo a consistência e a integridade dos dados.

Abaixo segue o comando ps faux | grep postgres executado como root, que é um comando para mostrar todos os processos relacionados ao postgres, de todos os usuários, e sua saída:

Debian shell: consultando processos postgres
# ps faux | grep postgres
postgres  171711  0.0  1.7 217608 17460 ?        Ss   Apr09   7:52 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main -c config_file=/etc/postgresql/16/main/postgresql.conf
postgres  171712  0.0  7.8 218036 77644 ?        Ss   Apr09   0:02  \_ postgres: 16/main: checkpointer
postgres  171713  0.0  0.7 217756  7468 ?        Ss   Apr09   0:41  \_ postgres: 16/main: background writer
postgres  171715  0.0  0.6 217608  6796 ?        Ss   Apr09   0:44  \_ postgres: 16/main: walwriter
postgres  171716  0.0  0.7 219208  7108 ?        Ss   Apr09   1:45  \_ postgres: 16/main: autovacuum launcher
postgres  171717  0.0  0.4 219184  4340 ?        Ss   Apr09   0:02  \_ postgres: 16/main: logical replication launcher

Como um exemplo adicional, fizemos um teste com o pg_bench (com escala 10x maior do que a padrão, 50 clientes e quatro threads, com duração de 120 segundos) e rodamos, desta vez, o comando top -c, que fornece a visualização dinâmica e interativa dos processos. Este é um trecho da saída:

Debian shell: consultando processos com teste do pg_bench
# top -c
top - 18:01:38 up 57 days,  2:24,  2 users,  load average: 19.95, 5.63, 1.93
Tasks: 135 total,  32 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 64.7 us, 34.3 sy,  0.0 ni,  0.0 id,  1.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    961.0 total,     77.9 free,    505.3 used,    679.6 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    455.7 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1219997 postgres  20   0  239676   7792   6412 S  17.5   0.8   0:09.62 /usr/lib/postgresql/16/bin/pgbench -c 50 -j 4 -T 120 postgres
1220014 postgres  20   0  219816  84068  80660 R   2.3   8.5   0:00.92 postgres: 16/main: postgres postgres [local] idle in transaction
1220040 postgres  20   0  219820  82300  78888 S   2.0   8.4   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220050 postgres  20   0  219820  83928  80516 R   2.0   8.5   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220005 postgres  20   0  219816  80776  77376 R   1.7   8.2   0:00.90 postgres: 16/main: postgres postgres [local] COMMIT
1220007 postgres  20   0  219816  82044  78636 S   1.7   8.3   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220009 postgres  20   0  219816  82604  79204 R   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] idle
1220010 postgres  20   0  219816  82204  78804 S   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220011 postgres  20   0  219816  81988  78588 R   1.7   8.3   0:00.90 postgres: 16/main: postgres postgres [local] idle in transaction
1220012 postgres  20   0  219816  82944  79544 S   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220013 postgres  20   0  219816  83216  79800 R   1.7   8.5   0:00.90 postgres: 16/main: postgres postgres [local] idle in transaction
1220015 postgres  20   0  219816  84092  80692 S   1.7   8.5   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220017 postgres  20   0  219816  80868  77468 R   1.7   8.2   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220018 postgres  20   0  219816  83108  79708 R   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] idle in transaction
1220021 postgres  20   0  219816  83968  80568 S   1.7   8.5   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220022 postgres  20   0  219816  79704  76304 S   1.7   8.1   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220023 postgres  20   0  219816  82652  79252 R   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] idle in transaction
1220024 postgres  20   0  219820  82452  79036 S   1.7   8.4   0:00.90 postgres: 16/main: postgres postgres [local] UPDATE waiting
1220025 postgres  20   0  219820  80704  77292 R   1.7   8.2   0:00.90 postgres: 16/main: postgres postgres [local] COMMIT
1220026 postgres  20   0  219820  79340  75928 R   1.7   8.1   0:00.90 postgres: 16/main: postgres postgres [local] idle in transaction

O primeiro processo pgbench é o que está executando o teste de benchmarking e consome 17,5% da CPU, sendo o responsável pela maior carga no sistema.

Também é possível observar vários processos em estado R (running) ou S (sleeping), o que é esperado em um ambiente de testes. Também temos os status idle in transaction e UPDATE waiting, indicando que estão aguardando a conclusão de transações ou de operações de atualização.

Conclusão

O PostgreSQL tem uma organização relativamente simples de arquivos, diretórios e processos. Para o desenvolvedor ou usuário final do banco de dados, essas informações podem ser mera curiosidade, mas para quem pretende ser um DBA, a história é bem diferente. É fundamental entender o que cada um faz e onde fica cada informação. Enquanto tudo estiver funcionando bem, você provavelmente não vai se preocupar muito com isso, mas quando problemas ocorrerem, como falhas de hardware, bugs etc., entender esses conceitos básicos será fundamental para resolver os problemas. 
Mais informações podem ser encontradas na documentação oficial, aqui.

No próximo artigo, vamos entender um pouco melhor como os objetos do banco são organizados logicamente no catálogo interno e fisicamente nos diretórios $PGDATA/base, $PGDATA/global e $PGDATA/pg_tblspace.

The post Arquivos, diretórios e processos no PostgreSQL first appeared on Savepoint.

]]> https://savepoint.blog.br/2024/09/02/arquivos-diretorios-e-processos/feed/ 0 8486