자체 호스팅 사용자를 위한 PostgreSQL 18 업데이트

뉴스 및 이벤트 공지사항
62

자세한 내용을 좀 더 공유해 주실 수 있을까요? 저도 동일한 문제를 겪고 있습니다.

1개의 좋아요
63

같은 현상을 겪고 계신 분들을 위해 제가 한 작업의 요약(AI)을 드립니다:
PG15를 일시적으로 시작 → 데이터베이스 덤프 → PG18 사용 → 덤프 복원

1개의 좋아요
64

네, 이번 업그레이드는 이미지 기반입니다.

즉, Discourse의 구버전을 설치하더라도 이미지가 여전히 18 업그레이드를 강제하나요?

알겠습니다.

1개의 좋아요
65

수정을 하셨네요. 그런데 ChatGPT가 제시한 방법은 오류는 해결했지만, 대신 데이터베이스가 초기화되어 결국 계정, 주제, 게시글이 모두 사라졌습니다.

다행히 비교적 새로운 개발용 포럼이라 잃어버린 것이 많지는 않았습니다.

2개의 좋아요
66

오늘 이런 일이 일어나지 않도록 세심한 주의를 기울였습니다. 각 단계마다 아무것도 삭제되지 않는다고 알려주었고, 더 이상 필요하지 않은 데이터를 삭제하기로 합의할 수 있도록 모든 데이터가 이전되었는지 세 번 확인했다는 인상을 받았습니다.

하지만 만약 문제가 발생했다면, 내가 잃어버릴 데이터는 테마 컴포넌트 설정뿐이었을 것입니다.

1개의 좋아요
68

안녕하세요. 제 포럼은 데이터베이스가 꽤 큰 편입니다(약 80GB). 13에서 15로 업그레이드할 때 서버를 교체하고 새 설치 후 복구하는 방식으로 진행했습니다. 여러분도 같은 방식으로 진행하시나요? (업그레이드를 시도해 봤는데 collation 오류가 발생했습니다.)

69

이 토픽의 앞부분에서 스태프가 다음과 같이 언급했습니다:

그러므로, 네, 그것은 하나의 옵션입니다.

당신은 이미 이렇게 말했습니다:

콜레이션 오류? 기존 Discourse의 버전은 무엇인가요?

경험한 오류나 콘솔 출력을 게시해 보시는 건 어떨까요?

하지만 공간이 부족해지지는 않았나요? (기존 데이터베이스 크기의 2배가 권장됨)

70

안녕하세요, 공간은 충분합니다 (250GB 여유). 오류는 'collation mismatch’였는데, app.yml 파일에 UTF-8 문자열이 없는 것 같습니다.

1개의 좋아요
71

discourse_docker 이미지에서 합리적인 기본값을 제공하려고 노력하지만, 모든 가능한 사용 사례를 고려하기는 어렵습니다. 원하시는 경우 이미지를 커스터마이징하여 버전을 유지하도록 설정할 수 있습니다.

일정 수준에서 종속성 버전은 우리의 호스팅 요구사항을 반영합니다 - 우리는 내부적으로 기본 이미지를 사용합니다. 이는 이미지가 너무 오래되지 않도록 보장하지만, 동시에 우리가 유지보수할 수 있는 조합의 수에도 제한이 있음을 의미합니다.

해당 방식에 더 익숙하시다면 완전히 유효한 방법입니다.

경고가 구버전 DB를 덤프하기 위해 준비하는 동안 생성된 것이라면 걱정할 필요가 없습니다. 우리는 단순히 pg_dump를 실행하기 위해 구버전 데이터 디렉토리에 대해 서버를 실행하고 있을 뿐입니다. 덤프가 새 서버로 복원되면 인덱스가 다시 생성됩니다.

이런 현상이 발생하는 이유는 지난 며칠간 Debian Bookworm에서 Trixie로 업그레이드되어 glibc 버전이 변경된 기본 이미지의 새 버전을 출시했기 때문입니다. libc 제공자(사용자분도 아마 이 방식을 사용했을 것입니다)를 기반으로 하는 로케일은 glibc 업그레이드 과정에서 안정적이지 않으므로, 업그레이드 스크립트가 구버전 데이터를 덤프하기 위해 Postgres 서버를 시작할 때 collation mismatch 경고가 표시됩니다.

collation mismatch가 바로 pg_upgrade를 실행하지 않고 덤프 및 복원 방식을 사용하는 전체적인 이유입니다. DB가 builtin 제공자와 함께 C.UTF-8을 사용하는 경우, glibc 업그레이드가 더 이상 collation에 영향을 미치지 않습니다.

2개의 좋아요
72

오늘 밤 업그레이드를 수행했고, 계획대로 진행되었습니다. 동일한 데이터베이스 정렬 순서 경고가 표시되었지만, 무시해도 되는 것 같습니다. 감사합니다.

2개의 좋아요
73

app.yml 파일에 다음을 입력해 보았습니다.

app.yml
templates:

  • “templates/postgres.15.template.yml”
  • “templates/redis.template.yml”
  • “templates/web.template.yml”
  • “templates/web.ratelimited.template.yml”

업그레이드를 지연시키기 위해 시도했지만 다음과 같은 오류가 발생합니다.

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

74

잘못된 기본 컨테이너인 것 같습니다. ./launcher rebuild를 실행해 보셨나요? 이 명령은 git pull을 수행해야 하지만, 그래도 문제가 해결되지 않는다면 git pull을 직접 실행해 보시는 것을 권장합니다.

1개의 좋아요
Maintenance page workaround - can this be done?
75

같은 오류

Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Status: discourse/base:2.0.20260812-0036 이미지의 최신 버전 다운로드 완료
docker.io/discourse/base:2.0.20260812-0036
Launcher가 최신 상태인지 확인 중
Launcher가 최신 상태입니다
기존 컨테이너 중지 중

  • /usr/bin/docker stop -t 600 app
    app
    2.0.20260812-0036: discourse/base에서 가져오는 중
    Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
    Status: discourse/base:2.0.20260812-0036 이미지가 최신 상태입니다
    docker.io/discourse/base:2.0.20260812-0036
    /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
    /usr/local/bin/pups --stdin
    I, [2026-08-25T06:22:16.249062 #1] INFO – : stdin에서 읽는 중
    I, [2026-08-25T06:22:16.274434 #1] INFO – : File > /etc/service/postgres/run chmod: +x chown:
    I, [2026-08-25T06:22:16.281650 #1] INFO – : File > /etc/service/postgres/log/run chmod: +x chown:
    I, [2026-08-25T06:22:16.287846 #1] INFO – : File > /etc/runit/3.d/99-postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.293208 #1] INFO – : File > /root/install_postgres chmod: +x chown:
    I, [2026-08-25T06:22:16.299851 #1] INFO – : File > /root/upgrade_postgres chmod: +x chown:

실패(FAILED)

Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
실패 위치: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** BOOTSTRAP 실패 ** 이전의 오류 메시지를 확인하십시오. 오류가 하나 이상 있을 수 있습니다.
./discourse-doctor가 문제를 진단하는 데 도움이 될 수 있습니다.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1

1개의 좋아요
76

원인을 찾은 것 같습니다.

현재 기본 이미지에는 PostgreSQL 18 서버가 설치되어 있지만, postgres.15.template.yml은 여전히 PostgreSQL 15 서버 패키지가 이미 존재한다고 가정하고 있습니다. 따라서 해당 파일이 존재하기 전에 다음 경로에 도달합니다:

/etc/postgresql/15/main/postgresql.conf

그 결과, 위의 ENOENT 오류가 발생합니다.

PostgreSQL 15 홀드백 템플릿이 PostgreSQL 18 서버 패키지를 제거하고 PostgreSQL 15 서버 패키지를 설치한 후 PostgreSQL을 구성하도록 하는 작은 PR을 열었습니다:

이것은 postgres.template.yml을 postgres.15.template.yml로 변경할 때 PostgreSQL 18 업그레이드를 지연시키는 의도된 경로를 복원해야 합니다.

4개의 좋아요
77

업데이트가 배포되었나요?
다시 시도해 볼 수 있는 시기는 언제인가요? (참고용)

78

수정을 병합했습니다(@Ethsim2 님, 감사합니다!). 이제 다시 시도해 보셔도 됩니다.

2개의 좋아요
79

동작합니다. 정말 감사합니다!

2개의 좋아요
80

같은 서버에 여러 컨테이너를 실행 중인 사용자분들 중에 업그레이드 잘 되셨나요? 이번 주말에 시간이 나면 우리 것도 업그레이드하려고 하는데, 혹시 당분간 기다리는 게 좋을지 먼저 여쭤보고 싶어서요..

81

네, 몇 주 전에 한 서버에서 듀얼 컨테이너 업그레이드를 진행했습니다(러시아 서버에서도요). 전혀 문제가 없었지만, 먼저 디스크 공간이 충분한지 꼭 확인하세요.

2개의 좋아요
82

Docker 외부에서 PostgreSQL 업데이트를 진행하는 분들을 위한 팁입니다. pg_upgrade에 --link 옵션을 사용하면 데이터를 복사할 필요가 없습니다. 데이터를 하드링크할 수 있으며, 이를 통해 디스크 공간을 절약할 수 있습니다.

2개의 좋아요