오늘 아침 GUI를 통해 업데이트한 후 사이트가 다운되었습니다. Postgres V15에서 V18으로 업데이트를 시도했지만 실패한 것 같습니다. 그래서 앱의 런처를 통해 재구축을 시도해 보았지만 효과가 없었습니다. 또한 VIPS /usr/local/lib/libvips.so.42에 대한 오류 메시지도 나옵니다.
혹시 아이디어가 있으신 분이나 저만의 문제일까요?
두 번째 재구성을 시도해 보는 것이 항상 가치가 있습니다. 특히 데이터베이스 버전이 올라간 경우 더 그렇습니다. 가까운 주제를 참고해 보세요.
아직 문제가 해결되지 않았다면, 확인한 출력 내용 중 약 100줄 정도를 코드 블록으로 붙여넣어 주세요.
크리스가 언급했듯이, 당신에게는 다소 늦은 조언일 수 있지만:
그 방법을 시도해 보았지만, 물론 당신이 언급한 스레드는 보지 못했습니다. 업데이트를 시작하기 전에 백업을 해 두었기 때문에, 방금 컨테이너 내에서 PG V18로 수동으로 업데이트하고, vips의 더 최신 버전도 설치하여 해당 버전으로 설정함으로써 작동하도록 만들었습니다.
지금 사이트는 작동하는 것 같습니다. 그 후 전체 리빌드를 실행했는데 성공적이었으니, 이제 모든 것이 잘 되길 바랍니다.
vips-8.18.4
PostgreSQL 18.4
그러나 다른 머신에 있는 다른 인스턴스도 업데이트해야 하므로, 당신이 게시한 스레드를 들어가서 자세히 읽어볼 것입니다.
Ed_S님, 감사합니다!
흥미로운 점은, 2025년 10월에 작성한 app.yml 파일에 이미 다음 내용이 포함되어 있다는 것입니다:
templates:
- “templates/postgres.template.yml”
다른 토론에서 제가 뭔가 잘못 읽고 있는 걸까요?
그 말은 기본 옵션을 선택했다는 뜻인데, 이는 Postgres를 특정 버전으로 고정하지 않고 Discourse가 원하는 버전을 그대로 사용하는 것입니다.
(사람들은 새 버전이 나올 것을 알고 이를 사용하지 않으려고 할 때 특정 버전을 고정합니다. 하지만 이를 위해 예상치 못한 새 버전이 도착하기 전에 조치를 취해야 합니다.)
좋아요, 한숨. 그래서 오늘 아침 내 업데이트에서 정확히 무엇이 잘못되어 실패했는지 확신이 서지 않습니다. 이 사이트가 실패한 이유를 파악하기 전까지는 다른 사이트를 업그레이드하는 것에 대해 주저하게 됩니다. 특히 이 첫 번째 사이트를 실행하기 위해 컨테이너 내에서 수동으로 업그레이드했던 것처럼 실패를 반복하고 싶지 않기 때문입니다.
제 추측으로는, 오늘부터 도입되는 postgres 18 버전을 포함한 이번 업데이트에는 두 번의 재빌드가 필요할 것입니다. 웹 인터페이스에서는 재빌드를 한 번만 수행할 수 있으며, 제 추측이 맞다면 웹 인터페이스 업데이트는 항상 실패한 것처럼 보일 것입니다. 실제로는 실패한 것이 아니라, 중간까지만 진행되었을 뿐입니다.
이 추측은 틀릴 수도 있습니다. 쉽게 테스트해 볼 수 없기 때문입니다.
저를 포함해 여러 사람이 웹 업데이트 메커니즘을 더 이상 사용하지 않는다고 말하고 있습니다. 실패할 경우 결국 커맨드라인으로 접속해야 하기 때문입니다. 95% 이상의 시간에는 제대로 작동하는 것이 사실입니다. 하지만 간혹 실패하기 때문에, 저는 개인적으로 이를 사용하지 않습니다.
네, GUI 대신 CLI 업데이트를 하자는 좋은 아이디어였네요. 첫 번째 사이트는 Ubuntu 22.04를 사용 중이고, 아직 업그레이드가 필요한 두 번째 사이트는 24.04를 사용 중입니다. 오늘 아침에 이미 충분히 긴장한 상태라, 두 번째 사이트는 CLI 업데이트만으로 시도해 보고 결과를 알려드리겠습니다. 두 번째 서버에서는 여전히 구버전의 vips(/usr/local/lib/libvips.so.42)가 확인되는데, 첫 번째 시도 때와 달리 이번에는 필요에 따라 적절히 업그레이드되기를 바랍니다. 감사합니다.
OJ, 명확히 하기 위해 말씀드리면, 제 첫 번째 discourse 업데이트는 확실히 실패했습니다. GUI 업데이트 후 CLI로 재빌드해도 마찬가지였습니다. 그래서 Postgres와 vips 컨테이너를 V18로 수동으로 업데이트해야 했습니다. 두 번째 사이트에서는 더 나은 결과를 기대하고 있습니다. 지켜봐 주세요.
그건 꽤 심각한 상황이네요.
충분한 디스크 공간이 있는지 확인하세요. 다른 주제에서 권장되는 2 x 데이터베이스 크기를 참고하세요.
물론이죠, 그리고 두 서버 모두 디스크 공간이 충분합니다. 다음은 서버 1입니다.
df -h /var/discourse
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 194G 25G 170G 13% /
서버 2:
df -h /var/discourse
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 193G 26G 168G 14% /
따라서 Server 2의 다른 디스커스 사이트도 실패한 Server 1과 동일한 방식으로 설정되어 있는 것 같습니다. 아직 이 두 번째 서버를 시도하고 싶지는 않습니다: 중요하지는 않지만, 컨테이너에서 다음을 확인했습니다:
/var/discourse# ./launcher enter app
x86_64 아키텍처 감지됨.
...app:/var/www/discourse# which vips
/usr/bin/vips
ldd /usr/bin/vips | grep vips
libvips.so.42 => /usr/local/lib/libvips.so.42 (0x000070c9601bb000)
ls -l /usr/local/lib/libvips*
-rwxr-xr-x 1 root root 3097864 Jul 26 02:22 /usr/local/lib/libvips.so.42
ps aux | grep '[p]ostgres'
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
/usr/lib/postgresql/15/bin/postgres --version
postgres (PostgreSQL) 15.18 (Debian 15.18-1.pgdg12+1)
좋아요, 서버 2에서 CLI를 사용하니 작동하네요. 정말 의외네요. 교훈은 업데이트할 때는 CLI를 사용하라는 것 같습니다. Ed_S님, 감사합니다.