Recentemente migrei o antigo Veeam para uma nova máquina virtual. A nova máquina virtual: Windows Server 2022, Veeam 12.3, PostgreSQL 15 que está sendo executado na mesma VM.
Atualmente estou monitorando alguns serviços (CPU, Memória, Discos.. etc..) com NSClient++. Estou procurando uma solução para monitorar o servidor PostgreSQL com nagios. Alguém conseguiu com sucesso o acima e quais plugins/clientes/soluções você usou?
Estou planejando configurar um servidor PostgreSQL/PostGIS no RHEL 9.4 como parte do trabalho de migração de uma versão mais antiga do RHEL e estou comparando caminhos de atualização de uma perspectiva de estabilidade.
Se entendi corretamente, há duas maneiras de instalar o PostgreSQL e o PostGIS no RHEL9:
Instale o PostgreSQL ( postgresqlNN-server) e o PostGIS ( postgisNN_MM) do repositório oficial do PostgreSQL ( pgdgNN).
Esta opção segue o ciclo de manutenção do PostgreSQL e PostGIS .
Instale o PostgreSQL ( postgresql) do Red Hat Application Streams e o PostGIS ( postgis) do EPEL.
A Red Hat fornece diversas versões do PostgreSQL:
Para o PostGIS, as atualizações são fornecidas pela EPEL com base no melhor esforço devido à natureza do projeto orientada pela comunidade. Dito isso, os mantenedores da EPEL se esforçam para manter os pacotes até o EOL do RHEL.
Das Perguntas Frequentes da EPEL :
Por quanto tempo os pacotes EPEL são atualizados?
Idealmente, os pacotes EPEL são mantidos enquanto a versão RHEL correspondente for suportada. No entanto, o EPEL é um esforço voluntário, e um mantenedor de pacote pode aposentar sua ramificação EPEL a qualquer momento.
Estou pensando em usar o EPEL PostGIS porque ele complementa o PostgreSQL fornecido pela Red Hat, que oferece um longo ciclo de vida (PostgreSQL 13 suportado até 2032). No entanto, estou preocupado com a compatibilidade de longo prazo dos pacotes EPEL com o software fornecido pela Red Hat, especialmente depois que as versões upstream (por exemplo, PostgreSQL ou PostGIS) atingirem o EOL.
No meu caso, o PostgreSQL upstream atingirá o fim da vida útil em 2025-11 e, olhando para o gráfico de compatibilidade PostgreSQL-PostGIS e extrapolando a tendência, espero que o PostGIS deixe de oferecer suporte ao PostgreSQL 13 nas próximas versões.
Como os pacotes EPEL, como o PostGIS, normalmente são mantidos em tais cenários, especialmente quando vinculados ao software fornecido pela Red Hat com um ciclo de vida mais longo?
Especificamente:
No PostgreSQL, tenho a seguinte configuração em pg_hba.conf:
local all sec_eng scram-sha-256
host all sec_eng scram-sha-256
hostssl all app_server 192.168.1.0/32 scram-sha-256 clientcert=verify-full
Não há outras linhas de configuração.
Quando tento me conectar ao PostgreSQL usando sudo psql -U sec_eng, o cliente me autentica como um peer, e não me solicita nenhuma senha e, portanto, a autenticação falha.
Se eu tentar, sudo psql -U sec_eng -h localhostserei autenticado como Ident, não serei solicitado a digitar uma senha e, portanto, a autenticação falhará.
O que estou fazendo errado aqui? Como posso conectar ao PostgreSQL por meio de um Socket Unix, usando meu nome de usuário e uma senha?
No trabalho, estamos enfrentando uma espécie de problema misterioso. A cada poucas horas, uma de nossas tabelas ( tasks) vê a latência da consulta aumentar (causada pelo uso da CPU) seguida por uma explosão de LWLock:BufferContent, depois volta ao normal. Aqui está uma captura de tela dos insights de desempenho do RDS:
Fizemos muito trabalho para tentar mitigar isso, e o trabalho resultou em incidentes (anedoticamente) menos frequentes e menos graves. No entanto, o problema não desapareceu.
Primeiro notamos que havia algumas consultas que não atingiam os índices. Passei um tempo certificando-me de que todas as nossas consultas para esta tabela executassem varreduras de índice e somente de índice. As consultas tendem a ser assim:
SELECT COUNT(1) FROM tasks WHERE status = 'PENDING' AND NOT deleted
e temos índices correspondentes statuscom uma condição status = 'PENDING' AND deleted = FALSE. EXPLAIN ANALYZEmostra que o índice está sendo usado corretamente.
Descobrimos que algumas consultas que especificam uma condição em nossa userIdcoluna tinham um plano de consulta incorreto quando o usuário tinha um grande número de registros. Isso foi solucionado com correções na consulta e melhorias no índice. Pelo que podemos dizer, não há consultas que tenham um plano de consulta incorreto para quaisquer valores (ainda assim, o problema persiste).
Durante os picos, não há aumento na carga recebida. Antes, durante e depois do incidente, as consultas afetadas mostram o mesmo número de "chamadas/s" nos insights de desempenho do RDS, e nosso aplicativo cliente mostra um QPS estável, portanto, isso não é causado por um aumento nas consultas .
Observei que os EXPLAIN ANALYZEresultados dessas consultas mostram um aumento nas buscas de heap durante esses picos, mesmo para verificações somente de índice. Li que o heap ainda é atingido durante as varreduras de índice porque o mapa de visibilidade pode indicar que as páginas que contêm tuplas referenciadas pelo índice podem não estar visíveis. Este parecia ser um sinal forte: PENDINGas tarefas (conforme mostrado na consulta acima) são frequentemente linhas "quentes" que recebem muitas atualizações, por isso faz sentido que o mapa de visibilidade para páginas que contêm essas linhas exija buscas.
Para compensar, as configurações de vácuo automático foram ajustadas para causar vácuos muito mais frequentes. Agora vemos vácuos automáticos a cada poucas horas, mas o problema não desapareceu. Eu vi esses picos apenas 20 minutos após a conclusão do vácuo automático da mesa. Além disso, o número de buscas de heap relatado EXPLAIN ANALYZEdurante o pico pode ser de 1 a 2 ordens de magnitude maior que o número de PENDINGregistros de tarefas: o número raramente excede 200 no total, e podemos ver muitos milhares de buscas de heap em varreduras somente de índice para índices que contêm apenas PENDINGregistros.
Durante a depuração, percebi que o planejador de consultas tende a ajustar quais índices consulta ao longo do tempo, mesmo quando a carga permanece ~constante. Às vezes, ele escolhe índices que permitem varreduras de índice, mas não varreduras apenas de índice. Por exemplo, ele pode escolher um índice on statusalone e ignorar um índice on statuscondicional on status = 'PENDING' and not deleted, mesmo quando este último satisfaz perfeitamente a consulta. Ajustei as configurações seq_page_coste random_page_costpara ambos em 1.0vez dos padrões do Postgres (1 e 4, respectivamente), o que deve direcionar o Postgres a preferir varreduras de índice. Infelizmente, o problema persistiu (embora talvez com menos frequência). A captura de tela acima é após o ajuste das configurações.
Algumas informações adicionais:
Neste ponto, estou quase sem ideias. Para referência, estamos no Postgres 14.10 rodando db.m5.16xlargecom um volume SSD GP2. Minha suspeita é que esta versão do Postgres só precisa de uma atualização (trabalho planejado), mas não é uma solução satisfatória.
Algo que me deixa um pouco perplexo é por que o uso de recursos que causa a latência é a CPU. Você pode ver na imagem acima o aumento em verde (CPU). Basicamente, em todas as consultas, deve haver muito poucos registros verificados. Todas as consultas são agregações de contagem e as condições das consultas são todas de igualdade simples. Aqui está uma das saídas de consulta afetadas quando não há pico:
Aggregate (cost=46.02..46.03 rows=1 width=8) (actual time=0.362..0.362 rows=1 loops=1)
" -> Index Only Scan using ""tasks_globalPending"" on tasks (cost=0.25..37.54 rows=3393 width=0) (actual time=0.239..0.353 rows=128 loops=1)"
Heap Fetches: 178
Planning Time: 0.161 ms
Execution Time: 0.377 ms
Muito rápido! Indiscutivelmente extremamente eficiente (embora eu prefira zero buscas de heap). E para um COUNT()valor que nunca retorna um valor superior a 300, é surpreendente como isso pode ir de 0,4 ms para 10-20 ms por consulta e queimar esse tempo no uso da CPU. O que isso está fazendo?
macOS Sonoma 14.2.1 (23C71), recém-atualizado para 14.5 (23F79)
História
Eu tinha um script python (norgis ALKIS-Import) importando muitos dados para meu banco de dados Postgres no fim de semana. Quando voltei hoje, o banco de dados ainda estava funcionando, mas não consegui acessá-lo. Recebi esta mensagem de erro: "base/5/2703": No such file or directory. Depois de reiniciar meu Mac, ele não iniciava mais.
Cópias de segurança
Eu tenho um armazenamento conectado diretamente com RAID 10, onde faço backups diários e mensais usando um script de shell rsync e LaunchAgents. Apenas copia a pasta var-16 para o grande armazenamento. Tentei iniciar todos os backups diários (7) e o backup mensal e todos apresentaram o mesmo erro. Eu também tinha um backup com algumas semanas, mas recebo o mesmo erro. Minha mente simplesmente não consegue explicar por que diabos todos os meus backups estão danificados sem que eu toque em nenhum deles.
O que eu tentei
Esta é a saída de log do arquivo postgresql.log após iniciar o servidor.
2024-07-22 14:29:58.728 CEST [9382] LOG: listening on IPv6 address "::", port 5432
2024-07-22 14:29:58.728 CEST [9382] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-07-22 14:29:58.729 CEST [9382] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
2024-07-22 14:29:58.744 CEST [9382] LOG: could not open directory "pg_tblspc/.DS_Store/PG_16_202307071/pgsql_tmp": Not a directory
2024-07-22 14:29:58.744 CEST [9382] LOG: could not open directory "pg_tblspc/.DS_Store/PG_16_202307071": Not a directory
2024-07-22 14:29:58.745 CEST [9385] LOG: database system was interrupted while in recovery at 2024-07-22 14:23:35 CEST
2024-07-22 14:29:58.745 CEST [9385] HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
2024-07-22 14:30:03.952 CEST [9385] LOG: database system was not properly shut down; automatic recovery in progress
2024-07-22 14:30:03.966 CEST [9385] FATAL: could not open directory "pg_tblspc/.DS_Store/PG_16_202307071": Not a directory
2024-07-22 14:30:03.967 CEST [9382] LOG: startup process (PID 9385) exited with exit code 1
2024-07-22 14:30:03.967 CEST [9382] LOG: aborting startup due to startup process failure
2024-07-22 14:30:03.967 CEST [9382] LOG: database system is shut down
Também não entendo por que ele deseja fazer algo em um diretório .DS_Store. Eles não são feitos e usados pelo macOS?
Editar
Se alguém souber por que todos os meus backups também foram danificados, responda. De onde vieram os .DS_Stores e por que o postgres tentou fazer algo com os arquivos .DS_Store? Obrigado!
Sou um iniciante em PostgreSQL e estou seguindo uma introdução aos bancos de dados para configurar um banco de dados PostgreSQL local e conectar-me a ele. Estou executando o Debian 15, então faço o seguinte:
# apt update
# apt install postgresql
A instalação foi bem-sucedida. Eu então faço:
sudo -u postgres psql
psql (15.7 (Debian 15.7-0+deb12u1))
Type "help" for help.
postgres=# \l
postgres=# createdb prismatest
postgres-# \l
postgres-# \c prismatest
connection to server on socket "/var/run/postgresql/.s.PGSQL.5433" failed: FATAL: database "prismatest" does not exist
Previous connection kept
Portanto, a lista de bancos de dados não mostra nada e não é possível conectar-se ao banco de dados - supostamente - recém-criado. Meu usuário tem os direitos:
postgres-# \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
Alguém pode me ajudar a descobrir o que está acontecendo? Obrigado...
isso não funciona
CREATE ROLE "role-one" LOGIN;
CREATE ROLE "other_role" LOGIN WITH "role-one";
eu recebo este erro
ERROR: unrecognized role option "role-one"
LINE 1: CREATE ROLE "other_role" WITH "role-one";
O que estou fazendo de errado? Não consigo encontrar exemplos online que deixem claro para mim qual é a sintaxe. Pelo que vi deve funcionar.
Como faço para criar uma nova função com LOGIN e adicioná-la a outra função chamada role-one?
Eu configurei o servidor PostgreSQL para usar o Kerberos. No meu Ubuntu Desktop onde o cliente PostgreSQL está instalado, posso estabelecer com sucesso a conexão Kerberos com o servidor PostgreSQL usando o cliente psql.
No Ubuntu Desktop, instalei o pgadmin4 usando o servidor apache2 seguindo as instruções: https://computingforgeeks.com/how-to-install-pgadmin-4-on-ubuntu/ Posso fazer login com sucesso no pgadmin4 usando a conexão interna do pgadmin4 e posso estabelecer o PostgreSQL conexão com o servidor PostgreSQL que NÃO usa Kerberos. Acho que o pgadmin4 está configurado corretamente.
Agora eu gostaria de estabelecer a autenticação Kerberos com pgadmin4 para o servidor PostgreSQL Kerberos configurado. Eu segui a documentação oficial: https://www.pgadmin.org/docs/pgadmin4/latest/kerberos.html e também assisti ao vídeo do youtube: https://www.youtube.com/watch?v=EDg6I21kCak - posso seguir e configure tudo como no documento e no vídeo, mas, finalmente, quando abro o navegador Firefox 113, digite URL: http://desktop.example.com/pgadmin4/browser/ e a página da web pgadmin4 é carregada, mas no canto superior direito há um erro mensagem exibida: "Falha na autenticação do Kerberos. Não foi possível encontrar o tíquete do Kerberos."
Eu verifiquei o ticket com o comando "klist" e o ticket está lá e ainda é válido (lembre-se de que posso estabelecer conexão Kerberos com sucesso com a ferramenta psql). Além disso, o arquivo keytab da área de trabalho está presente no Ubuntu.
No Ubuntu, verifiquei /var/log/pgadmin/ onde está um arquivo vazio. Também verifiquei a pasta /var/log/apache2/ onde a única mensagem (durante o estabelecimento da conexão) está em access.log:
192.168.100.31 - - [02/Jun/2023:13:41:49 +0200] "GET /pgadmin4/browser/ HTTP/1.1" 302 930 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv: 109.0) Gecko/20100101 Firefox/113.0"
192.168.100.31 - - [02/Jun/2023:13:42:04 +0200] "GET /pgadmin4/login?next=%2Fpgadmin4%2Fbrowser%2F HTTP/1.1" 401 5435 "-" "Mozilla/5.0 (X11 ; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0"
Alguma ideia do que posso pesquisar?
Não há problemas para se conectar a ele de qualquer outro ambiente (o local funciona bem, assim como da nuvem), e o grupo de segurança está totalmente aberto no momento. Uma instância real do PostgreSQL, hospedada na AWS, não apresentou problemas. É apenas uma coisa de Aurora. Eu criei várias instâncias com configurações diferentes. A autenticação SSL está desativada e o próprio SSL está configurado para ser opcional.
"Desculpe, encontramos um erro e não foi possível concluir sua solicitação."
Estou executando o Postgres 14 em um Windows Server 2022 Standard. Enquanto as operações do banco de dados estavam em execução, como a inserção, meu servidor reiniciou e agora o Postgres não inicia. Eu olhei para o arquivo de configuração e as últimas linhas são as seguintes:
2023-04-23 01:43:36.913 PDT [123528] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:52:04.222 PDT [105764] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:52:04.223 PDT [118464] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:54:38.568 PDT [121492] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:54:38.569 PDT [123696] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:59:51.982 PDT [124252] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:59:51.983 PDT [122440] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 01:59:51.983 PDT [116252] LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
2023-04-23 02:00:52.468 PDT [4988] LOG: received fast shutdown request
2023-04-23 02:00:52.572 PDT [4988] LOG: aborting any active transactions
2023-04-23 02:00:52.611 PDT [6172] FATAL: terminating connection due to administrator command
2023-04-23 02:00:52.683 PDT [5984] ERROR: canceling statement due to user request
2023-04-23 02:00:52.716 PDT [4988] LOG: background worker "logical replication launcher" (PID 5984) exited with exit code 1
2023-04-23 02:00:52.903 PDT [5916] LOG: shutting down
2023-04-23 02:00:55.161 PDT [4988] LOG: database system is shut down
Além disso, conforme sugerido por outros, verifico o Visualizador de eventos e vejo:
2023-04-23 03:33:39.610 PDT [5804] FATAL: configuration file "C:/Program Files/PostgreSQL/14/data/postgresql.conf" contains errors
Como estou usando o psycopg para trabalhar com db, estou recebendo os seguintes erros:
File "C:\Python310\lib\site-packages\psycopg2\__init__.py", line 122, in connect
conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (::1), port 5432 failed: Connection refused (0x0000274D/10061)
Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (127.0.0.1), port 5432 failed: Connection refused (0x0000274D/10061)
Is the server running on that host and accepting TCP/IP connections?
Para limitação de tamanho, removi todos os comentários:
listen_addresses = '*' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
shared_buffers = 4096MB # min 128kB
work_mem = 2000MB # min 64kB
maintenance_work_mem = 3000MB # min 1MB
dynamic_shared_memory_type = windows # the default is the first option
max_wal_size = 1GB
min_wal_size = 80MB
effective_cache_size = 4GB
log_destination = 'stderr'
logging_collector = on # Enable capturing of stderr and csvlog
log_timezone = 'America/Los_Angeles'
datestyle = 'iso, mdy'
timezone = 'America/Los_Angeles'
lc_messages = 'English_United States.1252' # locale for system error message
# strings
lc_monetary = 'English_United States.1252' # locale for monetary formatting
lc_numeric = 'English_United States.1252' # locale for number formatting
lc_time = 'English_United States.1252' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
Não tenho um backup de banco de dados recente. Como devo conquistar o problema?