좋은 아이디어네요, Ed! 게시물을 업데이트했습니다. 
2개의 좋아요
이 변경 사항으로 전체 메모리 사용량이 약 4% 감소하는 것을 확인할 수 있습니다. 잘하셨습니다.
2개의 좋아요
릴리 감사합니다. 조금 전에 업그레이드를 했는데 모두 잘 된 것 같습니다 
1개의 좋아요
재작성된 테이블과 인덱스가 훨씬 더 컴팩트해지는 것은 드문 일이 아닙니다.
1개의 좋아요
음, 그건 Postgres를 운영할 때 발생하는 노이즈 수준입니다 (vacuum을 실행하기 전인지, 테이블 재구축 등을 수행한 후인지에 따라 달라집니다).
그 이후로 누락된 것을 발견하지 못했으니, 제가 아는 한 모든 것이 정상입니다.
1개의 좋아요
저는 /var/discourse 경로에서 독립형 Docker 컨테이너로 Discourse를 실행하고 있습니다.
내장된 PostgreSQL 데이터베이스를 15 버전에서 18 버전으로 업그레이드하려고 시도했습니다. 업그레이드가 완료된 것으로 보였고, 활성 데이터 디렉토리는 현재 다음과 같이 보고됩니다:
/shared/postgres_data/PG_VERSION
18
그러나 다시 빌드된 Discourse 컨테이너에는 여전히 PostgreSQL 15 바이너리만 포함되어 있습니다:
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
PostgreSQL 서비스는 다음과 같이 실행되도록 구성되어 있습니다:
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
반면 실제 Discourse 데이터 디렉토리는 다음 위치에 마운트되어 있습니다:
/shared/postgres_data
이에 따라 PostgreSQL은 다음과 같은 오류를 발생시킵니다:
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
최근 Discourse Docker 이미지에는 PostgreSQL 18 바이너리가 포함되어야 한다고 알고 있습니다. app.yml을 PostgreSQL 18 템플릿을 사용하도록 변경하고 앱을 다시 빌드했지만, 생성된 컨테이너에는 여전히 PostgreSQL 15 바이너리가 있고 서비스 스크립트는 여전히 /etc/postgresql/15/main을 가리키고 있습니다.
현재 서비스 구성의 관련 부분은 다음과 같습니다:
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
질문은 다음과 같습니다:
-
컨테이너에 실제로 PostgreSQL 18 바이너리가 포함되도록 Discourse 컨테이너를 다시 빌드하거나 업데이트하는 올바른 방법은 무엇인가요?
-
app.yml에서 사용해야 할 특정 템플릿이나 이미지 태그가 있나요? -
PostgreSQL 18이 사용 가능해지면, 기존
/shared/postgres_data디렉토리를 대상으로 시작하는 지원되는 절차는 무엇인가요?
PostgreSQL 18 데이터 디렉토리를 삭제하거나 초기화하지 않았습니다. 이전 PostgreSQL 15 데이터를 복원하는 것보다는 업그레이드된 클러스터를 복구하는 것이 좋습니다.
1개의 좋아요
OP의 설명에 따르면, 제가 무언가를 놓치고 있지 않는 한 불필요한 단계였던 것 같습니다?
표준 설치를 다시 빌드하는 것만으로도 최신 이미지를 가져오고 마이그레이션이 시작되었어야 합니다.
최신 이미지에서 제외되지 않는 한, 새로운 바이너리가 보장되었을 텐데? 정말 이상하네요 …
이미지를 고정(pinned)하지 않았는지 확인해 보셨나요?
3개의 좋아요
의도적으로 그런 것은 아닙니다. 저는 일반 git 저장소와 브랜치를 사용하고 있으며, app.yml에서 제가 무언가를 고정했다는 것을 나타내는 내용이 없습니다. 도움이 될지 확인해 보기 위해 postgres 18 템플릿으로만 변경했는데, 네, 도움이 되지 않는 불필요한 단계였으니 다시 되돌릴 수 있습니다.
새 바이너리를 가져오는 방법에 대해 조언해 주실 수 있나요? 여러 번 다시 구축했음에도 불구하고 실제로는 존재하지 않습니다:
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
1개의 좋아요
시간과 번거로움을 절약하기 위해 최신 백업으로 새 서버를 생성하는 것을 고려해 보십시오. 이렇게 하면 많은 작업을 절약할 수 있습니다.
1개의 좋아요
좋아, 그렇게 생각할 수밖에 없겠네요! 때로는 고치려 애쓰는 게 오히려 시간 낭비일 수 있죠. 감사합니다.
2개의 좋아요
관리자 패널에 접근할 수 없는 경우, 즉 Discourse가 갑자기 이상해졌을 때, root@를 통해 DB를 가져와 새 인스턴스에 업로드하는 방법은 무엇인가요? (아마도 다른 가이드가 있을 수도 있겠네요)
아니면, 관리자 패널을 통해 실행하는 것과 동일한 작업을 수행하는 명령줄은 무엇인가요?
음, 그리고 더 중요한 점은, 갑자기 발생했을 것 같은 인증서 오류(예상치 못한 변경 사항 없이 발생한 것 같습니다)를 해결하기 위해 앱을 다시 빌드해야 합니다. 포트 443 접근 가능 오류가 발생하고 있으며(마법사가 "DNS 검증 실패"라고 표시함) - CF(클라우드플레어)나 DO(디지털오션)에서 무언가를 변경한 것 같지만, 제 쪽에서는 아무것도 변경하지 않았습니다. 지난번에는 디스크 공간 부족 오류였는데, 이번에는 이 아래 오류를 포함해 아마도 이 두 오류 때문에 다시 빌드할 수 없습니다. 이 아래 오류를 어떻게 넘길 수 있을까요?
추가로, 포스트그레스 15 > 18 요구 사항을 고려하여 기본 디스크 크기를 늘린 전후로도 정확히 동일한 오류가 발생했습니다.
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
아, 네. 이 토픽에서 @Lilly 님이 꽤 전에 올린 것으로 보이는, 제가 필요한 것 같은 내용을 찾았어요.
cd /var/discourse
./launcher enter web_only
discourse backup
exit
이것을 보면, 제가 새로 설치한 Discourse 인스턴스에 업로드할 수 있고 모든 문제를 우회할 수 있는 사용 가능한 DB 백업을 생성할 수 있을 것 같아요.
이 명령어로 게시글 + 업로드/이미지를 포함한 전체 백업을 받을 수 있나요?
데이터베이스만 백업하고 나머지는 rsync로 옮기는 것을 권장합니다. rsync로 Discourse 사이트를 다른 VPS로 이동하기. SSL 인증서도 rsync로 복사해 두면 DNS를 변경하기 전에 새 사이트를 미리 구동할 수 있습니다.
제 작업 방법은 다음과 같습니다: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
수정: 죄송합니다. 문제가 해결되었는지 정확히 파악하기 어렵네요. 제 이해가 맞다면, 가장 쉬운 방법은 기본 버전 없는 템플릿으로 되돌린 후 다시 빌드하는 것입니다.
2개의 좋아요
데이터(아마도 당신의 경우 앱) 컨테이너를 요구사항대로 두 번 다시 빌드하셨나요?
(참고로 업데이트 메시지는 앱을 다시 빌드하라고 되어 있지만, 아마도 "앱 또는 데이터라고 불릴 수 있는 데이터베이스 컨테이너"를 의미하는 것 같기도 하고, 둘 다인 걸까요?)
그리고 피드백을 드리자면, 얼마 전 13에서 15로 업데이트를 시도했는데 여러 번 실패하여 .13 템플릿을 유지하고 있었습니다. 그런데 .18이 제공되자 다시 시도해 보았더니 아무 문제 없이 작동했습니다(그 전에 _new와 _older 디렉토리를 정리해 주었어야 했지만요). 이제 다시 버전이 없는 기본 데이터 템플릿을 사용할 수 있게 되었습니다. 업데이트를 이렇게 견고하게 만들어 주셔서 정말 잘하셨네요.
1개의 좋아요
오류 로그를 확인해 보니, PG 업데이트 전에 로그에 SQL 관련 오류가 몇 가지 있었던 것 같습니다:
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
이것은 좀 이상합니다. 이 함수는 PG9에서 나온 것 같은데, 저는 그 전에 15버전을 사용 중이었거든요. 권한 문제나 검색 경로(search path) 문제일 수 있을까요? DB 업데이트 후에는 발생하지 않는 것 같지만, 배치 타이밍 문제일 수도 있겠네요. 이 함수가 꽤 많은 곳에서 사용되고 있고, 마이그레이션 스크립트에서도 보고 있습니다.
아마도 템플릿에는 여전히 나열되어 있지만, 구버전 PostgreSQL에서는 일부 함수가 실패하는 경우를 의미하는 것일지도 모릅니다. 제가 놓친 것이 있을 수 있지만, 구버전은 호환성이 있다고 생각했거든요.
1개의 좋아요