Ao tentar executar backups do sistema, recebo a seguinte mensagem: “O backup falhou. Verifique os logs.”
O log relata: pg_dump: [archiver (db)] conexão com o banco de dados "discoursedb" falhou: não foi possível conectar ao servidor: Connection refused
Acredito que podem haver dois problemas envolvidos:
O servidor remoto está rodando em uma porta não padrão.
O PostgreSQL remoto está executando uma versão mais recente do PSQL.
Ao acessar o app (/var/discourse/launcher enter app) e executar um backup manual, observei que, inicialmente, sem a definição da porta, obtive exatamente o mesmo erro:
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: [archiver (db)] conexão com o banco de dados "discourse_db" falhou: não foi possível conectar ao servidor: Connection refused
O servidor está rodando no host "123.456.789.101" e aceitando
conexões TCP/IP na porta 5432?
Isso foi resolvido facilmente (EXCETO que não sei como forçar o Discourse a usar a porta correta nos backups). No entanto, o próximo problema foi um pouco mais preocupante: estamos usando uma versão mais recente do PSQL no servidor de banco de dados:
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: versão do servidor: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); versão do pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: abortando devido a incompatibilidade de versão do servidor
O que pode ser feito nessa situação? Existe alguma maneira de tornar o backup do sistema funcional nesse caso, ou o Discourse e o banco de dados PostgreSQL precisam ser feitos separadamente?
Se a segunda opção for a única viável, qual é a maneira CORRETA de fazer backup, pelo menos, dos dados? Existe algum mecanismo coeso preferencial disponível para realizar ambos ao mesmo tempo, sem a necessidade de escrever um novo script para isso?
Encontrei uma discussão em outro post sobre alguém com uma situação ligeiramente comparável. A grande diferença no meu caso é que armazenamos os arquivos no servidor local, e não no S3. Poderia deixar de fazer backup do PostgreSQL, já que ele é backupado independentemente, mas ainda preciso fazer backup de:
conteúdo local e
configurações do Discourse
Ainda gostaria de um backup consolidado com o banco de dados + conteúdo + configurações tudo em um só lugar, mas acho que vocês não apoiam isso (ou não vão apoiar), então gostaria de pelo menos obter conteúdo + configurações em um pacote consolidado.
Postgres 11 não é compatível. Você pode procurar em outro lugar como restaurar entre versões, mas será necessário algum trabalho para fazer o Discourse funcionar com o pg11.
Interessante e estranho. Li em algum lugar que o 11 estava OK, mas, além disso, já tenho um sistema implantado na versão 11 e, até agora, não observei nenhum erro ou problema (exceto com o backup)… Agora você me deixou preocupado…
Ah, lá vamos nós: de acordo com este post, o PostgreSQL 11 “deveria funcionar sem problemas.”
Sim. Tenho dois sistemas implantados no pg11 também. Eles estão funcionando bem, exceto que estou fazendo backups diretamente. Atualizei o pg para a versão 11 no container. Eles fazem os backups, mas não conseguem restaurá-los.
O sistema de backup do Discourse deve apenas emitir um aviso e não falhar se houver uma incompatibilidade de versão do PostgreSQL. Acabei de tentar fazer um backup e, como também estou usando um servidor PG externo, nenhum arquivo tar foi criado.
O mesmo problema aconteceu comigo. Movi o banco de dados postgresql para um servidor separado e comecei a receber um erro de backup. Encontrei a solução excluindo e reinstalando o postgresql no docker no servidor principal.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql