Gumuliokas's questions

Eu recentemente tenho alguns DBs para manter. Acabei de falar sobre isso "Evitando falhas de wraparound de ID de transação". Eu verifiquei meus DBs e obtive os números:

Eu fiz vácuodb -a -v neste banco de dados e, em seguida, obtive os números:

Na minha opinião não é bom o suficiente? Devo me preocupar?

Se entendi corretamente o manual do PostgreSQL, devo usar o vácuo freeze para zerar os contadores? Eu sei que esse banco de dados crescerá de forma constante, geralmente em inserções, não tanto para exclusões/atualizações.

Obrigada.

Eu tenho um servidor principal e outros dois servidores estão replicando do principal.

Eu tenho espaço em disco completo no servidor principal (eu tenho um archive_commandque coloca arquivos wal no /wal_archive/diretório).

Ficou cheio e o log do PostgreSQL mostra o erro:

archive command failed:

    2019-06-04 09:52:49.079 EEST [3365] LOG:  archive command failed with exit code 1
    2019-06-04 09:52:49.079 EEST [3365] DETAIL:  The failed archive command was: test ! -f /wal_archive/000000010000028C0000003B && cp pg_xlog/000000010000028C0000003B /wal_archive/000000010000028C0000003B

Limpei o /wal_archive/diretório com pg_archivecleanup, mas o PostgreSQL ainda lança o mesmo erro.

Eu tentei recarregar a configuração do PostgreSQL sem fazer alterações na própria configuração e sem reiniciar usando:

/etc/init.d/postgresql reload

mas ainda o mesmo, no log, o PostgreSQL lança um erro. Como devo retomar a cópia do wal_archive para o diretório wal_archive?

Devo mudar archive_commandpara true, recarregar e alterar o arquivo de volta para o original novamente?

Estou tentando evitar reiniciar o próprio servidor.

Acabei de fazer uma migração do banco de dados Postgres 9.4 para 10. Como verificar se está tudo bem?

Eu tentei olhar em tabelas enormes, as linhas são diferentes (de alguma forma, no Postgres 10, há mais linhas do que no 9.4)

PSQL 9.4: 14 583 936 
PSQL 10:  14 880 545 

aqui estão meus comandos pg_dump e pg_restore que foram executados sem erros, mas levaram um processo muito longo, o dump foi de 12 horas, enquanto o pg_restore 10 horas:

pg_dump    -U postgres -d hive -Z1 -Fc -f /mnt/offline_backups/hive_full_2019-03-01_1630.dmp 2> /mnt/offline_backups/hive_full_2019-03-01_1630.log
pg_restore -U postgres -d hive -v         /mnt/offline_backups/hive_full_2019-03-01_1630.dmp

ambos os comandos estavam sem erros.

Aqui algumas capturas de tela do pgadmin 4v:

Em ambos os DBs, apenas classifiquei a contagem de linhas em ordem decrescente.

Como você pode ver, as linhas inseridas são bem diferentes.

Aqui está o resumo:

estamos tentando mover todos os dados do banco de dados para outro local. optamos por executar pg_dump e encontramos alguns problemas:

primeiro foi problema de falta de memória: durante a inicialização do pg_dump, recebemos um erro:

pg_dump: saving search_path =
pg_dump: saving database definition
out of memory

então demos à VM +16GB de RAM, então 24GB no total, o processo pg_dump passou e agora temos outro problema:

pg_dump: dumping contents of table lob_messages
Write failed: Connection reset by peer
gumul@IT-dep:~$

O erro ocorre até agora apenas nesta tabela "lob_messages", esta tabela é enorme - pgAdmin mostra o tamanho de 256 GB. Eu tentei pg_dump em todo o banco de dados, depois desse erro tentei apenas pg_dump nessa tabela exata. O erro ainda ocorre.

Estamos usando o Postgesql 9,4. Nossos administradores de sistema não sabem o problema. Aqui está a visualização htop:

Aqui está a visualização df -h:

eu tentei fazer o arquivo pg_dump no armazenamento NAS montado em /mnt e também localmente em /var/lib/postgresql/9.4/main

aqui estão as configurações alteradas do postgresql.conf:

o erro permanece. Você pode compartilhar alguma sabedoria o que estou fazendo de errado? Durante esse erro (conexão redefinida por peer), desconectei-me do servidor, mas apenas naquela sessão em que o pg_dump é executado. Em outra conexão (monitoramento htop) permanece conectado durante esse erro.

Eu tive um problema com o servidor PostgreSQL.

Assumi o servidor PostgreSQL do meu ex-colega e hoje meu servidor travou devido ao espaço em disco preenchido com wal_archives.

Normalmente, os segmentos wal eram colocados no diretório raiz /wal_archive/, eu verifiquei - está vazio. Algum tempo atrás eu verifiquei e tinha alguns segmentos...

Eu cavei mais fundo e descobri que todos os segmentos wal estavam armazenados no pg_data/pg_xlogdiretório.

Como isso pôde acontecer? While postgresql.confestá configurado assim (mostrando apenas o segmento ativado de linhas de 'registro antecipado')

wal_level = hot_standby                 # minimal, archive, hot_standby, or 
archive_mode = on               # allows archiving to be done
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'  

Por que meu diretório wal_archive agora está vazio enquanto as configurações de configuração mostram informações diferentes?

O wal_archivediretório era de propriedade do arquivo do usuário root
pg_hba.confnão possui nenhum usuário de replicação - suponho que não haja replicação no servidor também. Não há arquivos como recovery.confem qualquer lugar.

cp: não é possível stat 'pg_xlog/000000010000033C00000081': Nenhum arquivo ou diretório
2018-12-05 14:37:54 EET [7540-1860] LOG: comando de arquivamento falhou com o código de saída 1
2018-12-05 14:37:54 EET [7540-1861] DETAIL: O comando de arquivamento com falha foi: test ! -f/wal_archive/000000010000033c00000081 && cp pg_xlog/000000010000033c00000081/wal_archive/000000010000033c00000081
2018-12-05 14:37:54 EET [7540-18662]

Também devido ao pânico, apaguei acidentalmente grande parte dos segmentos wal no diretório xlog, para iniciar o servidor. Tudo está funcionando bem agora, mas quero garantir que não haverá problemas no futuro.