Durante a atualização, recebi
Parando o servidor de banco de dados PostgreSQL 15: mainErro: O proprietário da configuração (postgres:101) e o proprietário dos dados (runit-log:999) não correspondem, e o proprietário da configuração não é root … falhou!
falhou!
não foi possível abrir o arquivo de versão " /shared/postgres_data/PG_VERSION ": Permissão negada
Falha, saindo
O que foi resolvido por
sudo ./launcher enter app
e então
chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
Estou em um loop infinito, o banco de dados foi atualizado corretamente, mas quando executo ./launcher rebuild app ele fica em loop, a única coisa que consigo ver é o seguinte
EDIT: Encontrei esta mensagem…
mv: falha ao mover entre dispositivos: '/shared/postgres_data_new' para '/shared/postgres_data/postgres_data_new'; impossível remover o destino: Diretório não vazio
Sua instalação contém extensões que devem ser atualizadas
com o comando ALTER EXTENSION. O arquivo
update_extensions.sql
quando executado por psql pelo superusuário do banco de dados atualizará
essas extensões.
Por favor, me aconselhe
Upgrade Concluído
----------------
As estatísticas do otimizador não são transferidas pelo pg_upgrade.
Depois de iniciar o novo servidor, considere executar:
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
Executar este script excluirá os arquivos de dados do cluster antigo:
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
UPGRADE DO POSTGRES CONCLUÍDO
O banco de dados antigo 13 está armazenado em /shared/postgres_data_old
Para completar o upgrade, reconstrua novamente usando:
./launcher rebuild app
-------------------------------------------------------------------------------------
Ok, então parece que este é o problema aqui:
Estes estão localizados em shared/standalone/ e já foram movidos manualmente…
mv: não é possível mover '/shared/postgres_data' para '/shared/postgres_data_old': Dispositivo ou recurso ocupado
mv: falha ao mover entre dispositivos: '/shared/postgres_data_new' para '/shared/postgres_data/postgres_data_new'; impossível remover o destino: Diretório não vazio
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Gerando locais (isso pode levar um tempo)...
Nenhuma solução parece funcionar. É tão frustrante.
Isso seria muito incomum para alguém oferecer tal serviço sem antes ser solicitado.
Se você deseja contratar alguém, este é o lugar para ir: Marketplace - Discourse Meta
Nossa instância multissite está inativa após a atualização. Ela disse:
Sua instalação contém extensões que devem ser atualizadas
com o comando ALTER EXTENSION. O arquivo
update_extensions.sql
quando executado pelo psql pelo superusuário do banco de dados atualizará
essas extensões.
Não consigo encontrar o arquivo update_extensions.sql em lugar nenhum. Onde ele estaria localizado?
Verifique isto
mv: não é possível mover '/shared/postgres_data' para '/shared/postgres_data_old': Dispositivo ou recurso ocupado
mv: falha ao mover entre dispositivos: '/shared/postgres_data_new' para '/shared/postgres_data/postgres_data_new'; impossível remover destino: Diretório não está vazio
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Gerando locais (isso pode levar um tempo)...
Fui eu. Ofereço ajuda quando parece que alguém está em uma situação que será difícil de resolver com a ajuda aqui.
Pergunta de curiosidade.
Existe alguma estratégia ou padrão relacionado a atualizações de componentes chave, como o Postgres?
Vejo que o suporte ao Postgres 13 foi até 25/11 e que o 15 vai até 2027, e a versão atual é a 17.
Realmente, estou apenas querendo aprender e entender. Mudar versões de banco de dados geralmente é um grande problema e um trabalho pesado.
Obrigado!
Eu estou na estaca desde o Postgres 10. Geralmente eles atualizam a cada duas versões, embora tenham pulado do 12 para o 13 porque havia algumas melhorias que tornaram uma troca antecipada válida. Fiquei um pouco surpreso de eles não terem ido direto para o 16.
Normalmente, as atualizações são bem tranquilas, desde que você tenha espaço suficiente no disco e uma versão recente do Docker.
Voltei para o modelo 13 até que haja uma correção, obrigado
Consegui resolver o problema que tive com a atualização do PostgreSQL de 13 para 15, após restaurar o servidor com a atualização falha a partir de backups, os seguintes passos funcionaram para mim com uma locale PostgreSQL en_GB.UTF-8:
sudo -i
su - discourse
cd /var/discourse
git stash
git stash drop
git pull
./launcher stop app
docker run --rm \
--entrypoint=/bin/bash \
-e LANG='en_GB.UTF-8' \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen && locale-gen &&
apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
docker-upgrade'
exit
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
chown -R 101:104 /var/discourse/shared/standalone/postgres_data
su - discourse
cd /var/discourse
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data
./launcher rebuild app
Precisei remover as alterações locais que haviam sido feitas no passado para o LANG do PostgreSQL usando git stash; git stash drop e a movimentação dos diretórios de dados do PostgreSQL precisou ser feita como root e um chown foi necessário.
O git pull é necessário desta vez? Geralmente não é.
Não é mais necessário atualmente, pois o rebuild faz isso.
A mensagem final Device or resource busy do primeiro erro implica que algo mais está segurando um bloqueio desse diretório postgres_data, de modo que ele não pode ser movido.
Como esse é o diretório do banco de dados, uma explicação provável é que postgres_data pode ser um ponto de montagem. Isso é ainda mais provável, pois vemos inter-device move failed no segundo comando mv, implicando que shared/postgres_data_new e shared/postgres_data estão em discos/partições diferentes.
Se você confirmar que postgres_data é um ponto de montagem, terá que mover manualmente todos os arquivos de postgres_data para algum outro diretório de backup e, em seguida, mover todos os arquivos de dentro de postgres_data_new para o diretório postgres_data (agora vazio). Ambos os movimentos devem ser feitos após a conclusão da primeira reconstrução com UPGRADE OF POSTGRES COMPLETE, mas antes de emitir a segunda.
Se postgres_data não for um ponto de montagem, lsof é seu amigo. Você pode usá-lo para tentar identificar o que está causando o bloqueio.
Claro, faça os backups necessários primeiro.
Isto é perfeito, obrigado.
Os arquivos estavam na seguinte pasta:
/var/postgres_data_discourse como postgres_data_new
O seguinte corrigiu isso.
Movi o postgres_data_new para /var
Renomeei o postgres_data_discourse para postgres_data_discourse_old
Renomeei o postgres_data_new para postgres_data_discourse
Executei ./launcher rebuild app
Obrigado novamente 
Tenho 62g de banco de dados, o que você sugere para realizar o melhor upgrade?
62G /var/discourse/shared/standalone/postgres_data
Recomendo que você migre para uma nova VM, configure um novo Discourse com um banco de dados vazio (copiando os diretórios ssl e letsencrypt se desejar uma troca com tempo de inatividade zero) e restaure o banco de dados atual para o novo servidor. Isso permite que você faça a atualização com tempo de inatividade zero e risco zero de que algo possa dar errado.
Provavelmente não é cedo demais para atualizar seu sistema operacional de qualquer maneira.
Essa é uma boa ideia.
Posso mover o backup ### 3.4.0.beta4-dev ### para a instalação mais recente?
Se você está perguntando se pode restaurar qualquer versão antiga do Discourse para qualquer nova versão do Discourse que possa obter, a resposta é sim.