padjee's questions

Estou prestes a reiniciar o serviço postgresql 12 em execução no Ubuntu 18. Primeiro, verifico seu status: sudo service postgresql status. Diz:

postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor pres
   Active: inactive (dead)
lines 1-3/3 (END)...skipping...
postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Embora pareça inativo, ainda consigo me conectar.

Em seguida, executo outra verificação: systemctl status postgresql@12-main. diz :

root@db-services:/# systemctl status postgresql@12-main
● [email protected] - PostgreSQL Cluster 12-main
   Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/[email protected]
           └─override.conf
   Active: active (running) since Mon 2022-06-13 09:02:25 WIB; 5 months 27 days ago
 Main PID: 5807 (postgres)
    Tasks: 86 (limit: 4915)
   CGroup: /system.slice/system-postgresql.slice/[email protected]
           ├─ 1586 postgres: 12/main: postgres db_sync 10.100.3.248(61414) idle
           ├─ 1588 postgres: 12/main: postgres db_sync 10.100.3.248(61415) idle
           ├─ 1606 postgres: 12/main: docreg db_docreg 10.100.8.150(18385) idle
           ├─ 1607 postgres: 12/main: docreg db_docreg 10.100.8.150(18399) idle
           ├─ 1608 postgres: 12/main: docreg db_docreg 10.100.8.150(18401) idle
           ├─ 1609 postgres: 12/main: docreg db_docreg 10.100.8.150(18421) idle
           ├─ 2592 postgres: 12/main: docudigtl db_docudigtl 10.100.8.112(34956) idle
           ├─ 3518 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(48290) idle
           ├─ 5150 postgres: 12/main: docudigtl db_docudigtl 10.100.7.114(61504) idle
           ├─ 5807 /usr/lib/postgresql/12/bin/postgres -D /data/postgresql/12/main -c config_file=/etc/postgresql/12/main/postgresql.co
           ├─ 5883 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(48626) idle
           ├─ 6316 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(48704) idle
           ├─ 7049 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(48870) idle
           ├─ 7986 postgres: 12/main: docudigtl db_docudigtl 10.100.7.114(56240) idle
           ├─ 8146 postgres: 12/main: docudigtl db_docudigtl 10.100.8.114(47432) idle
           ├─ 8183 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(49022) idle
           ├─ 8360 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(49036) idle
           ├─ 8445 postgres: 12/main: docudigtl db_docudigtl 10.100.8.114(47478) idle
           ├─ 9590 postgres: 12/main: docudigtl db_docudigtl 10.100.8.106(56094) idle
           ├─ 9687 postgres: 12/main: docudigtl db_docudigtl 10.100.8.112(50980) idle
           ├─10148 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(40646) idle
           ├─10324 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(40680) idle
           ├─11079 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(49496) idle
           ├─11602 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(58152) idle
           ├─11886 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(44674) idle
           ├─12106 postgres: 12/main: docudigtl db_docudigtl 127.0.0.1(49618) idle
           ├─13112 postgres: 12/main: docudigtl db_docudigtl 10.100.6.145(55014) idle
           ├─13122 postgres: 12/main: docudigtl db_docudigtl 10.100.6.145(55015) idle
           ├─13145 postgres: 12/main: docudigtl db_mysapk 10.100.6.145(55016) idle
           ├─13202 postgres: 12/main: docudigtl db_docudigtl 10.100.7.114(62073) idle
           ├─13945 postgres: 12/main: checkpointer
           ├─13946 postgres: 12/main: background writer
           ├─13947 postgres: 12/main: walwriter
           ├─13948 postgres: 12/main: autovacuum launcher
           ├─13949 postgres: 12/main: stats collector
           ├─13950 postgres: 12/main: logical replication launcher

Portanto, é realmente ativo!

Então eu faço sudo service --status-all | grep postgresql. Diz :

[ - ]  postgresql

1. Qual a diferença entre systemctl restart postgresql@12-main VS sudo service postgresql restart ?
2. Qual deles devo usar para reiniciar: systemctl restart postgresql@12-main OU sudo service postgresql restart ?

Para comparação, em outro servidor, se eu fizer sudo service postgresql status. Diz :

postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2022-12-05 18:37:03 WIT; 4 days ago
  Process: 22666 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 22666 (code=exited, status=0/SUCCESS)

Dec 05 18:37:03 db-profile-mtr systemd[1]: Starting PostgreSQL RDBMS...
Dec 05 18:37:03 db-profile-mtr systemd[1]: Started PostgreSQL RDBMS.

E quando o faço systemctl status postgresql@12-main, diz:

[email protected] - PostgreSQL Cluster 12-main
   Loaded: loaded (/etc/systemd/system/[email protected]; enabled-runtime; vendor preset: enabled)
   Active: active (running) since Mon 2022-12-05 18:37:03 WIT; 4 days ago
  Process: 22609 ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast 12-main stop (code=exited, status=0/SUCCESS)
  Process: 22631 ExecStart=/usr/bin/pg_ctlcluster --skip-systemctl-redirect 12-main start (code=exited, status=0/SUCCESS)
 Main PID: 22637 (postgres)
    Tasks: 119 (limit: 4915)
   CGroup: /system.slice/system-postgresql.slice/[email protected]
           ├─  417 postgres: 12/main: refer db_ref 10.100.9.50(53216) idle
           ├─  965 postgres: 12/main: refer db_ref 10.100.9.50(53514) idle
           ├─ 1709 postgres: 12/main: profiling db_profile 127.0.0.1(34158) idle
     ...many proceses all the way down

Então eu faço sudo service --status-all | grep postgresql. E diz:

 [ + ]  postgresql

Precisa de conselho/ajuda. Obrigado

Tenho 2 servidores envolvendo master-slavereplicação (replicação física).

Eu vejo a replicação usando select * from pg_replication_slots;há um registro dizendo:

user : rep_user`

application : 12/main

state : streaming

Eu tenho que mudar postgresql.confno mestre para habilitar pg_crona extensão, então preciso reiniciar o mestre.

É seguro apenas reiniciá-lo usando: sudo service postgresql stopseguido por sudo service postgresql start? Preciso descartar a replicação primeiro antes de reiniciar?

obrigado

Acabei de emitir este comando para uma mesa e já se passaram 2 horas, mas não terminei:vacuum verbose people_data

Não consigo nem cancelar o processo pois não consigo ver o PID usando esta consulta:

SELECT pid,
       now() - pg_stat_activity.query_start AS duration,
       query,
       state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes' 
  and state = 'idle'
order by duration desc;

O tamanho desta tabela é de apenas 16 GB. A tupla morta conta apenas no máximo 130 usando (apenas 10 tabelas têm tupla morta acima de 100):

select n_live_tup, n_dead_tup, relname 
from pg_stat_all_tables 
where n_dead_tup > 100 
limit 20;

Agora algumas pessoas me relatam que não conseguem acessar o banco de dados? Felizmente, este é um banco de dados de desenvolvimento, portanto, apenas interrompe o processo de desenvolvimento.

Como posso cancelar o vácuo sem ver o PID?

Em uma master-slaveconfiguração de replicação (1 mestre com 2 escravos. os escravos estão em espera ativa caso o mestre falhe).

1. Como posso fazer um backup em circunstâncias normais? Todos os nós são copiados individualmente e restaurados de acordo com seus próprios arquivos de backup?
2. Se o mestre falhar e um dos escravos for nomeado o novo mestre, como faço para reintroduzir o mestre? Será que esse velho mestre se tornará um escravo agora?

obrigada

Isso é novo para mim. Já procurei na net mas sem resultado.

Eu tenho um servidor, Servidor A , que está funcionando há algumas semanas, é um novo servidor. Eu configurei o FDW para este servidor acessar todas as tabelas de um publicesquema de 2 bancos de dados ( db B1 e db B2 ), vamos chamá-lo de Servidor B. Todas as tabelas são "armazenadas" em um esquema específico no servidor A em 3 bancos de dados diferentes (db A1, A2, A3). Existe também streaming replicationentre este servidor e o Servidor C

Aqui está o resumo do FDW que eu faço:

• Configure o servidor B : adicione entrada pg_hbapara aceitar todas as conexões create user fdwuser, recarregue o arquivo de configuração

• Configure o Servidor A :

1. Crie esses esquemas no banco de dados A1, A2, A3 para armazenar os dados do servidor B :

    CREATE SCHEMA reference;
    CREATE SCHEMA profile;
    GRANT USAGE ON SCHEMA profile TO jhon, bon;
    GRANT USAGE ON SCHEMA reference TO jhon, bon;
   

2. Crie a extensão FDW para cada banco de dados no banco de dados A1, A2, A3:

   CREATE EXTENSION IF NOT EXISTS postgres_fdw;
   

3. Criar servidores estrangeiros:

   CREATE SERVER foreign_profile 
     FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '10.10.8.40', port '5432', dbname 'db_profile'); ` 
   
   CREATE SERVER foreign_referensi 
     FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host     '10.10.8.40', port '5432', dbname 'db_reference');` 
   

4. Criar mapeamento de usuário:

   CREATE USER MAPPING FOR jhon SERVER foreign_reference OPTIONS (user fdwuser, password        
   'secret');  
   CREATE USER MAPPING FOR bon SERVER foreign_profile OPTIONS (user fdwuser, password 
   'secret'); 
   CREATE USER MAPPING FOR jhon SERVER foreign_reference OPTIONS (user fdwuser, password        
   'secret');  
   CREATE USER MAPPING FOR bon SERVER foreign_profile OPTIONS (user fdwuser, password 
   'secret');  
   CREATE USER MAPPING FOR jhon SERVER foreign_reference OPTIONS (user fdwuser, password 
   'secret');  
   CREATE USER MAPPING FOR bon SERVER foreign_profile OPTIONS (user referensi, password 
   'secret'); 
   

5. Importe os esquemas externos para o banco de dados A1, A2, A3:

   IMPORT FOREIGN SCHEMA public FROM SERVER foreign_profile INTO profile;  
   IMPORT FOREIGN SCHEMA public FROM SERVER foreign_referencd INTO reference; 
   

Todo o processo é um sucesso. Posso acessar a tabela externa no Servidor B do Servidor A . Tudo bem, sem problemas.

Agora, verifico os arquivos WAL usando SELECT COUNT(*) FROM pg_ls_dir('pg_wal') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';. Ele mostra mais de 2100 arquivos . Isso é preocupante.

Aqui está a configuração no servidor A:

archive_command cd .
archive_mode    on
checkpoint_completion_target    0.9
checkpoint_flush_after  32
checkpoint_timeout  300
wal_level   replica
wal_keep_segments   8
max_wal_senders 10
max_wal_size    8192
hot_standby on

Então eu faço algumas verificações:

1. select * from pg_catalog.pg_stat_activity

   Existem 250 entradas, dominadas por backend_type= parallel workerouclient backend

2. select * from pg_catalog.pg_stat_archiver

   Failed_count = 0;
   Archived_count = 71; 
   

3. Depois de alguns minutos, corro select * from pg_catalog.pg_stat_archivernovamente. Agora diz:

   Failed_count = 0;
   Archived_count = 3; -- it seems to be reset for some reasons
   

4. Verifique a replicação: select * from pg_catalog.pg_stat_replication. Resultados :

   state = streaming

   sync_state = async

Este servidor parece estar ocupado, eu acho.

Perguntas:

1. Por que os WALs continuam aumentando? Isso é normal? Se não, devo reduzi-los?
2. Por que o archived_countreset?
3. O que esse comando faz: archive_command cd .?

Eu quero configurar a replicação de streaming no Slave.

No servidor principal (servidor A. Ubuntu 18.04; Postgres 12) :

1. sudo nano /etc/postgresql/12/main/postgresql.conf
2. Definirlisten_addresses = '*'
3. As configurações do postgresql.conf são:

wal_level = "logical"

archive_mode = "ON"

archive_timeout = 3600

checkpoint_timeout = 600

hot_standby = "ON"

max_connections = 700

max_wal_sender = 5

max_wal_size = 16GB

min_wal_size = 2GB

max_worker_processes = 30

synchronous_commit = "OFF"

wal_log_hints = "OFF"

wal_recycle = "ON"

wal_keep_segments = 4000

wal_sync_method = "fdatasync"

Este Servidor Principal já hospedou replicação lógica para outro servidor (Servidor B. Ubuntu 18.04; Postgres 12)

No servidor escravo (servidor C. Ubuntu 22.04; Postgres 12) :

• alterar o diretório de dados
• configure isso como escravo para replicação de streaming do servidor A.

Aqui está o detalhe: Depois de instalar o postgres (instalação nova), eu me certifico de que ele está em execução e altero o diretório de dados:

1. sudo -u postgres psql
2. SHOW data_directory;. --Saída /var/lib/postgresql/12/main
3. Saia do psql:\q
4. sudo systemctl stop postgresql
5. sudo systemctl status postgresql
6. sudo rsync -av /var/lib/postgresql /data/postgresql2
7. renomeie a pasta:sudo mv /var/lib/postgresql/12/main /var/lib/postgresql/12/main.bak
8. Edite o postgresql.conf:sudo nano /etc/postgresql/12/main/postgresql.conf
9. Definir para o novo local:data_directory = '/data/postgresql2/postgresql/12/main'
10. Inicie o banco de dados novamente:sudo systemctl start postgresql

O resultado é bom. O Postgres está rodando bem no Servidor C. Quando eu faço SHOW data_directory;isso dá: /data/postgresql2/postgresql/12/main

Em seguida, configuro a replicação de streaming no servidor C:

1. pare o serviço no escravo:systemctl stop [email protected]

2. su - postgresentãocp -R /data/postgresql2/postgresql/12/main /data/postgresql2/postgresql/12/data_original

3. Remova o diretório antigo:

   rm -rf /data/postgresql2/postgresql/12/main/*

4. Em seguida, faça o backup básico:

   pg_basebackup -h 10.100.9.40 -p 5432 -U rep_user -D /data/postgresql2/postgresql/12/main -Fp -Xs -R -P -v

5. Reiniciar :systemctl start [email protected]

-- dá erro:

*`Job for [email protected] failed because the service did not take the steps required by its unit configuration.
See "systemctl status [email protected]" and "journalctl -xeu [email protected]" for details`*

6. Então eu começo a usar outra maneira:sudo -i -u postgres /usr/lib/postgresql/12/bin/pg_ctl start -D /data/postgresql2/postgresql/12/main

Dá erro:

waiting for server to start....postgres: could not access the server configuration file "/data/postgresql2/postgresql/12/main/postgresql.conf": No such file or directory

Por favor ajude. O que pode causar isso?

Estou pedindo orientação.

Eu quero configurar uma replicação entre 3 servidores: 1 mestre A, 2 escravos B e C. O mestre transmite para 2 escravos. A para B é a replicação lógica , enquanto A para C é a replicação de streaming

Depois que li alguns artigos e agora estou ciente de que a replicação de streaming envolve pg_basebackup, com o Slave puxando dados do Master.

Pergunta :

1. Li os artigos aqui e aqui . Qual está correto, "ALTER SYSTEM SET listen_addresses TO '*';"OU listen_addresses = 'your_primary_IP_address'. Estou apenas confuso.

2. Quais são algumas considerações antes de prosseguir com a replicação que envolve 3 servidores?

Obrigado postgresql 12, Ubuntu 20.04

Perdoe minha pergunta idiota.

Eu quero saber quais são as diferenças entre o cluster de banco de dados postgreSQL (1 servidor, N bancos de dados, N portas) e um servidor que hospeda vários bancos de dados (1 servidor, N bancos de dados, 1 porta)?

Eu li o agrupamento aqui e também aqui e isso também. Eu simplesmente não entendo. Ainda mais estranho para mim (devido à minha falta de conhecimento), no OpDash diz que o cluster pode executar diferentes versões do postgres ao mesmo tempo. :(

Algum exemplo de uso de cluster de banco de dados no mundo real? Suponha que eu queira fazer alta disponibilidade com replicação Master - Slave, preciso de clustering de banco de dados para isso?

por favor me esclareça ou me aponte para uma direção/artigo.

obrigada

Recentemente eu configurei o Forward Data Wrapper. Aqui está o que eu faço:

CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.168.125.1', port '5432', dbname 'template1 ');  
IMPORT FOREIGN SCHEMA public LIMIT TO (tbl_test) FROM SERVER foreign_server INTO public;

Crie um usuário no servidor de destino/externo: CREATE USER fdwuser WITH PASSWORD 'secret' E então faça as configurações necessárias como GRANT. O FDW funciona.

Mas depois quero fazer mais. E se eu reunir todos os usuários que desejam acessar o FDW em um arquivo GROUP. Então eu faço o seguinte:

• Create group role: demorole1

• create user: fdwuser3

• grant demorole1 to fdwuser3

• crie mapeamento de usuário para a função do grupo "demorole1" :

  CRIAR MAPEAMENTO DE USUÁRIOS PARA OPÇÕES DE SERVIDOR demorole1 external_server (usuário 'fdwuser', senha 'secret');

• select * from tbl_test;-- falhou .

• conceda acesso demorole1 a tbl_test, esquema e servidor externo:GRANT ALL ON TABLE tbl_test TO demorole1; GRANT USAGE ON FOREIGN SERVER foreign_server TO demorole1; GRANT USAGE ON SCHEMA public TO fdwuser3;

• Teste: select * from tbl_test; -- falhou . mapeamento de usuário não encontrado para o usuário fdwuser3

• CREATE USER MAPPING FOR demorole1 SERVER foreign_server OPTIONS (user 'fdwuser', password 'secret');

• Teste novamente: select * from tbl_test; - ainda falhou . mapeamento de usuário não encontrado para "fdwuser3"

• Faça o mapeamento do usuário:CREATE USER MAPPING FOR fdwuser3 SERVER foreign_server OPTIONS (user 'fdwuser', password 'secret');

• select * from tbl_test;-- TRABALHOS

Pergunta: Como posso criar uma função de grupo para que os usuários no servidor local possam ser definidos como membros, para que eu não precise fazer o mapeamento de usuário Conceder e Criar toda vez que um usuário quiser acessar a tabela FDW?

Obrigado

Então eu herdei esse banco de dados. No início, já havia alguns arquivos em pg_wal.

Então, depois de algumas semanas, eu conto SELECT COUNT(*) FROM pg_ls_dir('pg_wal') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';, resulta: 8182 arquivos.

Observando o carimbo de data/hora do arquivo no pg_waldiretório, vejo alguns novos arquivos sendo criados, mas o número de arquivos permanece o mesmo. Estou suspeitando que a rotação ocorre.

Então observo pg_stat_archiver:archived_count = **2**; failed_count = 0

Cerca de 3 horas depois, eu conto novamente SELECT COUNT(*) FROM pg_ls_dir('pg_wal') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';. Resultado: 8183 . Obviamente, um novo arquivo é criado.

Então eu faço pg_stat_archiver:archived_count = **3**; failed_count = 0

archived_count last_archived_wal           last_archived_time   failed_count    last_failed_wal  last_failed_time 
3              000000010000009B00000083    22-09-13 13:14:20.   0
stats_reset                          
2022-09-13 08:14:19

Este banco de dados é muito baixo, não ocupado. Às vezes ninguém acessa. Mas há replicação lógica que sincroniza cerca de 300 registros uma vez por dia com outro servidor.

Aqui estão minhas configurações:

max_wal_size : 1024 Mb
min_wal_size : 2048 Mb
wal_keep_segment : 0
wal_rotation : ON
wal_level : logical
wal_compression : ON
archive_on : ON
archive_mode : test ! -f /Archive/%f && cp %p /Archive/%f
archive_timeout : 900

Perguntas :

1. Por que a segunda contagem de pg_walaumento? Estou esperando que diminua porque o número arquivado aumenta.
2. Se wal_keep_segment = 0, por que o número de WALs pg_walnunca é 0 ? Na documentação diz:

Se wal_keep_segments for zero (o padrão), o sistema não mantém nenhum segmento extra para fins de espera,

3. Por que o número mínimo de WALs, durante o período de baixa, não = min_wal_size+ wal_keep_segment?

Por favor me esclareça.

Muito obrigado

Eu corro pg_dump na última noite para fazer backup de algum banco de dados de 111 Gb: time pg_dump -j 5 -Fd -Z 1 db_profans -f /backup-nfs/

Eu monitoro o crescimento do tamanho

Mas, de repente, esta manhã, o banco de dados está inativo. Eu verifico o diretório do sistema. A raiz está cheia. PS : Eu não tenho nenhum acesso ao servidor, temos caras diferentes para gerenciá-lo.

O que está acontecendo ? Por que todos os arquivos de backup se movem para a raiz? Ou algo mais fazendo com que a raiz fique cheia, talvez como arquivos WAL criados durante o backup ou arquivos de log se acumulando? Eu tenho replicação para este banco de dados, mas era realmente mínimo, apenas sincronizando 300 registros diariamente. E eu não ligo nenhum log também ..

Como excluir todos os arquivos de backup manualmente?

Aqui está o .

Atualizações:

Descobri que a causa do problema é que, na verdade, o processo de arquivamento não é gravado em um disco externo. Essa pasta "/Archive", que supostamente contém os WALs arquivados, é na verdade criada dentro da "raiz" ! Eu não sabia porque não era como o que eu pedi no outro dia antes. Agora, ao excluir os WALs arquivados, o servidor está funcionando novamente. Portanto, a causa não é do processo pg_dump.

Li coisas sobre pg_start_backupdaqui e daqui pg_base_backup .

Eu fiquei confuso. Então, dos 2 métodos, qual geralmente é melhor ? Parece que pg_start_backupé melhor do que pg_base_backup. Mas, pg_base_backuptem parâmetro para ser o mesmo que pg_start_backupcom pg_basebackup –xlog-method=streamcommand.

Se eu tiver uma situação assim:

• sem agrupamento
• replicação lógica de algumas tabelas (não de todo o banco de dados)
• sem espera quente
• Servidor físico de 1 db com muitos bancos de dados em uma instância
• deseja implementar o PITR

Qual deles é adequado para mim? Estou apenas confuso.

Postgres 12.

Obrigado

Depois de emitir pg_basebackup -D /var/lib/postgresql/basebackup -l "backup main $(hostname) on $(date)" -P, vejo que há 2 arquivos ".backup' no pg_waldiretório. Veja . É assim que o pg_archivediretório se parece . Perguntas:

1. Por que existem 2 arquivos?
2. Quais arquivos WAL posso excluir com segurança, antes do primeiro arquivo ".backup" (tudo em cima de **96.00000028) ou antes do segundo (tudo em cima de **98.00000028) ?
3. Ou eu tenho que excluir arquivos wal (todos os arquivos acima do 00028) em pg_archive?

Obrigado

Estou gerando dados fictícios com esta consulta:

INSERT INTO tbltest1 (id, kol1, kol2)
SELECT generate_series(1,10000), substr(md5(random()::text), 1, 25), substr(md5(random()::text), 1, 45)
FROM generate_series(1, 1000000);

Então, no meio do processo, surge este erro: não foi possível gravar no arquivo "pg_wal/xlogtemp.2399" sem espaço no dispositivo.

Obviamente, isso indica que não tenho mais espaço.

Então eu quero entrar no banco de dados emitindo o psqlcomando " ". Mas este erro ".s.PGSQL.5432" aparece: a conexão com o servidor no soquete "/var/run/postgresql/.s.PGSQL.5432" falhou. nenhum arquivo ou diretório aparece.

Vejo que algum erro causará este erro ".s.PGSQL.5432" . Este é realmente um beco sem saída para mim.

Por que nenhum erro de espaço deixado é emitido? Por que os arquivos WAL não são reciclados? Eu tenho o archive_mode = off, wal_level = logical. O WAL deve ser reciclado nestas configurações. O que devo fazer para ativar o banco de dados novamente?

Vejo que ainda tenho muitos espaços disponíveis (cerca de 20 GB a mais) estou executando na VM em execução no host Win 10.

Está realmente me assombrando. Por favor ajude

Atualizar

Parece que o postgre não pode escrever em pg_wal devido a falta de espaço.

1. eu verifico usando$root df -h
2. Então eu aumento o espaço: Inicialize a partir de USB ao vivo (Ubuntu ISO). Escolha "Experimente o Ubuntu" Abra o gparted Mova o espaço do HDD onde o postgre reside para o final do disco Expanda para consumir o espaço livre Reinicie a VM, sem usar a instrução ISO Full aqui e aqui também
3. Faça Memory Test(memtest86+) usando o CD de inicialização (Ubuntu ISO acima). Não acho que este passo seja necessário.
4. Reebot o sistema operacional convidado (estou executando o servidor no VMWare Workstation)
5. Certifique-se de que o Ubuntu consuma todo o espaço alocado. Instrução completa aqui . Ajuste à sua necessidade.
6. Reinicie novamente.
7. Faça login no Ubuntu e inicie o postgres como de costume

Agora o postgres pode ser executado normalmente. Não há mais erro ".s.PGSQL.5432".

Até agora, concluo que a falta de espaço no pg_wal pode causar o .s.PGSQL.5432erro " ".

Agora estou enfrentando outro erro. Posso fazer " Select * from table Limit 10" mas não consigo fazer consulta como " Select count(id) From table". Há erro sobre o bloco de página : página inválida no bloco 62052 da relação base /13462/16387

Quaisquer comentários ou ajuda são muito apreciados.

Ubuntu 22.04 rodando em VM, Postgres 12.

[ 4

Eu tenho um servidor com muitos bancos de dados...contém cerca de 20 bancos de dados. Alguns deles têm 16 milhões de linhas, mas não tantos. Geralmente, há pouca ou nenhuma atividade à noite, mas não tão ocupado durante o dia (exceto se houver um evento, como novo registro ou atualização de membro). Embora não ocupados, os bancos de dados contêm dados críticos. Nenhum dos bancos de dados foi copiado por mais de um ano!

Como posso apoiá-los com segurança sem travar o servidor? O que eu preciso como requisito inicial? Eu li muitas estratégias de backup, mas sou excessivamente cauteloso, pois não quero fazer coisas bobas. Eu quero desenvolver o método de backup mais seguro e "facilmente" recuperável.

No momento, ativei o arquivamento e já está funcionando bem.

Qualquer conselho bem-vindo ou talvez haja artigos que eu deveria ler.

Meu ambiente: Postgres 12 rodando no Ubuntu 20

Obrigado

Atualmente estou passando por uma situação estranha. Arquivo failed_countsubindo de 0 a 2475.

Aqui alguns parâmetros que eu verifico:

1. selecione * de pg_stat_archiver;

archived_count3567; last_archived_time2022-08-17 21:36:05; failed_count2516; last_failed_time18-08-2022 10:58

2. select pg_switch_wal(); WAL está sempre mudando, muito 1-2 segundos.

3. SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication;

Isso também está mudando a cada segundo. Sempre girando de milhares para 0 durante o período de tempo.

4. SELECT COUNT(*) FROM pg_ls_dir('pg_wal') WHERE pg_ls_dir ~ '^[0-9A-F]{24}';

Desde as 12h desta manhã, esse valor era sempre 7450. Antes disso, sempre aumentava. O valor máximo observado foi 10811

5. SELECT * FROM pg_stat_bgwriter ; Isso dá:

   Nome |Valor | ----------+---------------------------- -+ checkpoints_timed |109040 --> aumentando |
   checkpoints_req |96 --> permanece o mesmo |
   checkpoint_write_time|12514471288 | checkpoint_sync_time |1373072.0 | buffers_checkpoint |412734838 | buffers_clean |20745183 | maxwritten_clean |121362 | buffers_backend |98238043 | buffers_backend_fsync|0 | buffers_alloc |904724994 | stats_reset |2021-08-04 12:19:41.333 +0700|

Olhando para pg_stat_bgwriter, checkpoints_timed está aumentando, o que é bom.

Isso acontece apenas com meus servidores de produção (o outro está testando o servidor).

• O que está acontecendo ? Por que o WAL parou de gerar, mas a contagem arquivada está falhando? Tenho a impressão de que, se não houver um novo WAL, o arquivamento não deve ocorrer.
• Qual parâmetro LOGGING devo ativar para monitorar esses erros?

Minha configuração:

name                        |setting                                   |unit|
----------------------------+------------------------------------------+----+
archive_command             |test ! -f /archive/%f && cp %p /archive/%f|    |
archive_mode                |on                                        |    |
archive_timeout             |2400                                      |s   |
checkpoint_completion_target|0.9                                       |    |
checkpoint_flush_after      |32                                        |8kB |
checkpoint_timeout          |300                                       |s   |
checkpoint_warning          |30                                        |s   |
hot_standby                 |on                                        |    |
log_checkpoints             |off                                       |    |
max_replication_slots       |10                                        |    |
max_wal_senders             |5                                         |    |
max_wal_size                |8192                                      |MB  |
min_wal_size                |2048                                      |MB  |
synchronous_commit          |off                                       |    |
synchronous_standby_names   |*                                         |    |
wal_compression             |off                                       |    |
wal_keep_segments           |4000                                      |    |
wal_level                   |logical                                   |    |
wal_log_hints               |off                                       |    |
wal_segment_size            |16777216                                  |B   |
wal_sender_timeout          |60000                                     |ms  |

Por favor ajude. Obrigado

Estou fazendo a replicação para 16 milhões de registros. Só quero perguntar sobre a fase inicial da replicação lógica:

1. Preciso copiar a tabela inicial do editor para o assinante primeiro? Ou é tratado pela assinatura? Não sei quanto tempo vai demorar se for tratado pelo processo de replicação...
2. Aqui e em alguns outros sites também, https://www.enterprisedb.com/postgres-tutorials/logical-replication-postgresql-explained , diz "... gerar vários trabalhadores de sincronização de tabela" Como posso gerar vários trabalhadores de sincronização de tabela? Qual parâmetro é? Nenhum dos artigos que li menciona o parâmetro para configurar trabalhadores de sincronização

obrigado

Postgres 12 rodando no Ubuntu

Iniciei com êxito a replicação lógica em um ambiente de teste. Eu gero insertno mestre para alguns registros de 60K usando o procedimento. Enquanto o processo de inserção está em execução, eu monitoro o escravo usando a SELECT count(*)consulta " ". Mas os registros não estão somando. Se eu executar a consulta após o término da inserção no primário, SELECT countfunciona bem, todos os registros entre o escravo e o primário são iguais.

Esse comportamento é normal? Estou esperando que o escravo e o primário sejam exatamente os mesmos quase instantaneamente.

Obrigado

é possível se for min_wal_sizemaior que max_wal_size? O que acontece se isso acontecer? Quais são as circunstâncias em que min_wal é maior que max_wal ?

Estou usando PG 12.

Obrigado

Como monitoro uma replicação lógica no Postgresql 12 vendo o lsn?

O que eu fiz : Inspecione algumas colunas no Editor e no Assinante.

Lado do editor:

select * from pg_stat_replication; -- veja o REPLAY_LSN

select * from pg_replication_slots; -- veja o CONFIRMED_FLUSH_LSN

Lado do assinante:

select * from pg_catalog.pg_stat_subscription; -- veja o RECEIVED_LSN e o LATEST_END_LSN

Certifico-me de que todos os valores são os mesmos nessas colunas.

Estou correcto ? Ou existe alguma outra maneira de ver que a replicação funciona inspecionando alguns parâmetros?