Basil Titus's questions

Temos um cluster de replicação do PostgreSQL 13 onde um dos standbys está configurado com recovery_min_apply_delay="x hr", o que pode ser útil em caso de corrupção de dados.

Para um cenário em que uma exclusão acidental aconteceu no servidor mestre , mas ainda não foi aplicada ao servidor em espera . Neste caso, estou tentando extrair os dados do servidor em espera removendo o atraso de repetição do WAL e adicionando recovery_target_timeum ponto antes da exclusão acontecer.

Até este ponto, tive sucesso, mas depois que terminei de puxar os dados do servidor standby para o master (estou pensando em postgres_fdw), preciso retomar a replicação. Mas quando executo pg_wal_replay_resume(), ele está criando uma nova linha do tempo e não está mais no cluster de replicação.

Existe alguma maneira de reproduzir o WAL além de usar recovery_target_time?

Dando um exemplo do que estou tentando alcançar,

Digamos que recovery_min_apply_delay=2hr , uma exclusão acidental aconteceu às 03:50 AM, neste momento transações confirmadas em standby são transações que aconteceram em ou antes de 01:50 AM. Se eu esperar mais 2hr e às 05:49 AM se eu conseguir pausar a repetição do WAL em standby, poderei ver um instantâneo dos dados que estão "logo antes" de DELETE. Então usarei postgres_fdw para extrair dados do standby.

Como eu consigo "logo antes" de uma forma precisa e sistemática? Também seria capaz de retomar o replay do WAL.

Estou praticando Point in Time Recovery (PITR) no PostgreSQL 13 contra exclusão acidental de dados. Como o PostgreSQL oferece vários parâmetros para executar PITR, estou um pouco confuso escolhendo entre Transaction XID e LSN.

Se uma DELETEdeclaração acidental removesse um grande número de linhas e eu obtivesse o correspondente XIDa partir LSNdo dump do WAL, executar o PITR produziria o mesmo resultado, independentemente de eu usar o XID ou o LSN?

Existe o risco de perder outras transações confirmadas se eu restaurar usando o XID?

Este tópico já foi discutido aqui: Entendendo tamanhos de bloco Mas tenho mais algumas coisas a acrescentar para meu caso de uso.

Geralmente, a maioria database systemsusa um padrão block sizede 8 KB, embora alguns permitam que ele seja modificado. Por outro lado, os modernos operating systemsgeralmente usam um 4 KBtamanho de bloco para file systems. Essa discrepância pode resultar em várias physical I/Osolicitações para preencher um único database page.

Um tamanho de bloco de sistema de arquivo menor beneficia random reads, como index lookups, enquanto tamanhos de bloco maiores são vantajosos para sequential scanse heap fetches. Considerando esses pontos, tenho algumas perguntas:

1. Existe uma prática comum para alinhar o tamanho do bloco do banco de dados com o tamanho do bloco do sistema de arquivos para OLTP?
2. Em um clustered system(por exemplo, SQL Server Availability Groupsou PostgreSQL streaming replication) com um primário e um ou mais secundários, é aceitável ter tamanhos de bloco de sistema de arquivos diferentes ou isso é algo que deve ser sempre evitado?
3. Para analytical databasesou columnar tables, é benéfico usar um tamanho de bloco maior?

Estamos tendo esse comportamento estranho ExclusiveLockem um de nossos bancos de dados executando o PostgreSQL 13. Não consigo descobrir o que leva a esse bloqueio, pois as informações de bloqueio são de uma ferramenta de monitoramento.

Pelo que vejo nos documentos ExclusiveLockadquiridos apenas por atualização materialised view, no entanto, não temos nenhuma visualização materializada em nosso banco de dados. Um pouco de pesquisa que acabei neste blog https://blog.heroku.com/curious-case-table-locking-update-query e o caso que esse cara compartilha é semelhante ao meu, pois posso ver alguns RowExclusiveLockdurante esse período e algumas consultas atualizando a mesma linha simultaneamente. No entanto, não consegui encontrar nenhum documento oficial sobre o comportamento do PostgreSQL na escalada de bloqueio, assim como outros bancos de dados fazem.

O Postgres escala o bloqueio em casos raros? Quais casos podem levar a escalações?

Estamos realizando Citusbenchmarking e nos deparamos com uma situação onde o planejador faz o parallel execution planmas durante a execução não parallel workerssão lançados. O cluster possui 3 nós de trabalho, cada um com 2CPUs em execução no Centos. Qual pode ser a razão por trás disso?

->  Finalize Aggregate  (cost=76650.31..76650.32 rows=1 width=32) (actual time=174741.832..174741.999 rows=1 loops=1)
                 ->  Gather  (cost=76650.09..76650.30 rows=2 width=32) (actual time=174741.807..174741.974 rows=1 loops=1)
                       Workers Planned: 2
                       Workers Launched: 0
                       ->  Partial Aggregate  (cost=75650.09..75650.10 rows=1 width=32) (actual time=174740.490..174740.492 rows=1 loops=

A consulta que estamos usando para benchmarking é

select sum(amount) from tab_dist_1 where id>=49820 and id<=59743292;

Temos monitoramento de série temporal tanto pg_stat_databaseem pg_stat_statements. Recentemente, temos observado o uso de arquivos temporários em nosso banco de dados durante determinado período. Mas, para o mesmo período, não conseguimos encontrar consultas que no total correspondam ao uso total do pg_stat_database. Vimos em algum lugar operações de manutenção como vacuuminge analysepodem causar o uso de arquivos temporários, mas durante o período também não conseguimos encontrar tais atividades. Existem outras operações internas que podem causar o uso de arquivos temporários?

É possível especificar pgbouncer reserve_pool_timeoutem milissegundos, tentei especificá-lo com '500 ms', mas gerando um erro e tentei especificar 0,5, desta vez sem erro, mas não consegui descobrir que está realmente funcionando ou apenas desativei o tempo limite, mas reserve_pool está sendo utilizado .

Recentemente tivemos alto uso de CPU/memória e E/S em nosso MongoDB. Ao verificar os logs, tudo que encontrei foram alguns insertdurante esse período. Ao inspecionar os logs, notei que a maioria dos logs de inserção está bytesReadna seção de armazenamento. Portanto, suspeito que isso cause E/S e o armazenamento em cache dos dados cause muita memória.

Após o pico de inserção, a E/S e a CPU caíram, mas a memória permaneceu a mesma, o que foi resolvido após a reinicialização.

A leitura deste disco é normal com a operação de inserção? Estamos usando o Mongo v4.0 com WiredTigermecanismo de armazenamento na VM CentOS7.

2024-02-14T23:39:44.533+0800 I COMMAND  [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 34390, timeReadingMicros: 140837 } } 141ms
2024-02-14T23:40:16.785+0800 I COMMAND  [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 24150, timeReadingMicros: 506594 } } 507ms

Estamos usando o modo de arquivo de autenticação no pgbouncer. A parte de autenticação do Pgbouncer é muito confusa. Seria útil se alguém pudesse esclarecer minhas dúvidas abaixo.

• As conexões Pgbouncer são autenticadas duas vezes no lado do segurança e na camada de banco de dados?

• Qual é a utilidade da autenticação no Pgbouncer se ele estiver usando as mesmas credenciais do banco de dados ?

• É possível usar um conjunto diferente de credenciais de usuário para a autenticação Pgbouncer diferente das próprias credenciais do banco de dados?

Tenho visto muitos blogs de ajuste de desempenho do PostgreSQL e empresas como a EDB sugerindo colocar a configuração max_worker_processes do PostgreSQL para o número de CPUs na máquina.

Estamos usando uma VM PostgreSQL 13 dedicada na nuvem com 16 vCPUs . Mas a configuração padrão do Postgres max_worker_processes=8 . Baseia-se no valor padrão O que eu estava pensando O Postgres irá apenas até 8 vCPUs no máximo e o uso máximo esperado da CPU está em torno de 50% até alguns dias atrás, tivemos algum pico de conexão que na verdade estava ligado à sobrecarga de E/S, mas a CPU atingiu 95 -99% durante o pico.

Então, como max_worker_processes está relacionado à CPU? Isso terá algum impacto se eu deixar o valor padrão de 8? Ou existem outras maneiras de encontrar um valor ideal?