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.
"pg_xlog" é o diretório de trabalho em que os arquivos WAL são armazenados enquanto o PostgreSQL ainda pode precisar dos arquivos WAL, ou seja, para recuperação de uma queda de energia ou outra falha "soft". Eles são removidos de lá apenas quando o PostgreSQL tem certeza de que não são mais necessários para esse propósito, e uma vez que "archive_command" tenha sido concluído com sucesso.
Não podemos dizer o que aconteceu com o seu "/wal_archive/", mas aqui está uma história plausível:
Você tinha algum tipo de sistema de arquivos de rede (NFS, CIFS, etc.) montado usando "/ wal_archive" como ponto de montagem. Essa montagem falhou e nunca foi restabelecida. Isso significa que o sistema de arquivos original contendo seus arquivos WAL ainda está flutuando em algum lugar, mas o computador não sabe mais como acessá-lo. Você vê o antigo ponto de montagem /wal_archive como um diretório vazio porque é assim que as montagens funcionam no Linux. O usuário que está executando seu servidor postgres provavelmente não pode gravar nesse diretório residual, porque quando a montagem foi perdida, as permissões também foram. Portanto, o archive_command está falhando com erros de permissão, mas você nunca percebeu isso porque não estava procurando no log do servidor. Ele tentou repetidamente arquivar o arquivo WAL fora do pg_xlog, mas falhou repetidamente. Desde que falhou, ele nunca poderia remover o arquivo de pg_xlog, até que finalmente encheu. Em pânico, você removeu alguns dos arquivos do pg_xlog. Agora ele ainda está tentando arquivar esse arquivo, mas agora está falhando por um motivo diferente, o arquivo não está mais em pg_xlog, conforme demonstrado pela mensagem de erro "cp: cannot stat 'pg_xlog/000000010000033C00000081'".
Agora que você está funcionando novamente, os arquivos devem estar aparecendo no /wal_archive/ ou deve haver erros no arquivo de log do servidor informando que o archive_command falhou.
Observe que o archive_command que você está usando não é perfeitamente seguro. Ele não sincroniza o conteúdo do arquivo recém-copiado em /wal_archive/ antes de relatar o sucesso, portanto, uma falha no tempo certo pode significar que o arquivo recém-arquivado não existe em nenhum lugar. Você pode querer mudar para soluções enlatadas como "pgbackrest" ou "barman", ou usar replicação de streaming, para evitar esse tipo de armadilha.
Observe também que qualquer backup que você acha que tem provavelmente será inválido, a menos que você também esteja fazendo backups lógicos (como com pg_dump). É melhor você pegar novos e testá-los.