Postgres 12에서 Discourse가 업그레이드를 방해합니다

디스크 공간이 부족하여 v13 업그레이드가 불가능하므로 현재 postgres v12를 사용 중입니다. v12와의 호환성이 깨진 것처럼 보이는데, 의도적인 변경인가요? 그렇다면 Discourse를 영원히 업그레이드할 수 없게 됩니다.

./launcher start app을 실행하여 다시 온라인으로 복귀했으므로 현재는 프로덕션 문제가 아니지만, 보안 문제 등 어떤 이유로도 업그레이드할 수 없다면 우리에게 매우 나쁜 소식입니다.

app.yml 내용:

  - "templates/postgres.12.template.yml"

./launcher rebuild app 실행 결과:

FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** 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.

현재 실행 중인 버전: 2.8.0.beta4 75b0d6df93.

PostgreSQL 13을 찾고 있으며 12는 아닙니다.

{“filename”=>“/etc/postgresql/13/main/pg_hba.conf”,

그렇습니다. 그것이 바로 문제입니다.

백업 후 완전히 새로운 discourse 인스턴스를 생성(기본적으로 postgres 13을 사용해야 합니다)하고, 백업을 복원한 다음 DNS에서 서버를 다시 매핑하는 것은 어떨까요?

네, 그렇게 하면 되긴 하죠. 하지만 그걸 안 하려고 필사적으로 노력 중이에요.

무섭게 느껴질 수 있지만, 거기에 충분한 안전장치가 있을 테니, 항상 이전 서버를 다시 가동할 수 있습니다.

피곤한 일을 피하려다 보니, 포럼에 하루 이틀치 게시글이 사라질 거라고 말하는 것보다는 덜 무섭습니다. 이상적으로는 Discourse 팀에서 "물론 PG12도 계속 지원하고 있어요. 그건 그냥 버그일 뿐이니 수정하겠습니다"라고 말해 주면 좋겠습니다.

그것이 왜 필요한지 이해가 되지 않습니다.

  1. 서브도메인으로 새 서버를 준비할까요?

  2. 기존 서버를 읽기 전용 모드로 전환하고 백업을 생성합니다.

  3. 새 서버에 백업을 가져옵니다.

  4. DNS를 재매핑합니다.

  5. 주(주요) discourse 서브도메인으로 새 서버를 다시 구축합니다.

이 과정에 30분이 걸릴까요?

아니요, 저는 매우 큰 포럼을 운영하고 있습니다.

아! 이런 문제는 좋은 문제지! :slight_smile:

아마도, 내가 월급을 받는 것도 아닌데! :wink:

아, 커뮤니티 PR에서 도입된 버그였군요. 우리는 어디에도 PG12를 사용하지 않아서 이 문제를 놓쳤습니다. 잠시만 기다려 주세요.

다음 PR에서 수정되었습니다.

@Wingtip 님, 다시 재빌드해 보실 수 있을까요?

다만, 더 이상 PG12를 사용하지 않으므로, 코어에서 언제든 PG13+ 전용 SQL 구문을 도입할 수 있습니다. 따라서 언젠가는 업그레이드를 계획해 두시는 것이 좋습니다.

VM 스냅샷을 하나 더 찍고 나서 바로 확인해 볼게요.

PG는 업그레이드를 하려면 디스크 공간이 엄청나게 필요해서 정말 짜증나네요. Oracle이나 MySQL에서는 이런 문제가 없어요. 그냥 그 자리에서(in-place) 업그레이드하니까요.

pg_upgrade는 제자리 업그레이드를 허용하기 위해 단일 --link 플래그를 제공합니다.

우리는 "초보자 친화적"인 런처 업그레이드 스크립트에서 이를 사용하지 않기로 결정했습니다. 설치 환경의 99%가 클라우드 VM에서 실행되며, 디스크 용량을 쉽게 저렴하게 확장할 수 있기 때문입니다.

하지만 업그레이드 과정을 통해 디스크 공간을 절약하기를 선호하는 사람들이 수동으로 업그레이드를 수행할 수 있도록 옵션으로 제공됩니다.

제안된 해결책은 두 가지였습니다. 기억이 정확하다면, 하나는 전체 DB 크기의 약 3배가 필요했고, 다른 하나는 약 2배가 필요했습니다. 인플레이스(in-place)로 처리할 수 있다면, 이를 문서화하는 것이 매우 유용할 것입니다.

수정: 수정이 잘 작동했습니다. 감사합니다!

네, 생각 없이 복사해서 붙여넣었습니다. 죄송하고, 고쳐주셔서 감사합니다!