참고: 원인은 불분명하지만, PostgreSQL 18 업그레이드로 인해 네이티브 데이터 체크섬이 비활성화됩니다. PostgreSQL 데이터 체크섬은 기본 기능이며, 이를 비활성화하는 것은 매우 비정상적인 것으로 보입니다.
데이터 체크섬을 비활성화하지 않도록 하는 PR(기본적으로 활성화됨): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub
그리고 1년에 1시간밖에 안 쓰는 동안 20GB를 비워둬야 하는 것보다는 훨씬 낫지 ㅋㅋ
나무와 물을 절약하기 위해 이 방법을 권장하는 게 좋겠네요. 
확인 차 물어보는데, 저는 Discourse가 제공하는 PostgreSQL을 사용하지 않고, Discourse 자체도 아직 PG18을 요구하지 않는 것이 맞나요? 그렇다면 아직 PG18로 업그레이드할 의무가 없는 것이 맞습니다.
좋은 지적입니다. 하지만 또 다른 이유는 LTS(장기 지원) 릴리스가 몇 년에 한 번씩 나온다는 점입니다. 그래서 그 시점에 맞춰서 함께 진행하는 것도 나쁜 아이디어가 아닙니다.
당분간은 여유가 있습니다. 그들은 어떤 기능이 필요해서 업데이트 직후 꽤 빠르게 특정 릴리스를 추진했지만, 아마 1년 정도는 기다려도 괜찮을 것입니다. 저는 discourse_docker 저장소를 주시하고 있습니다. 언젠가 PG15 지원 종료에 대한 이야기가 나오기 시작할 텐데, 그건 특별히 시끄럽지 않고 내부 관련 업데이트 추적을 위한 쉬운 방법입니다.
2개의 좋아요
Pi 5 설치 환경에서는 문제없이 작동했고, 두 번 재빌드한 뒤 완료했습니다.
7개의 좋아요
참고로 벤치마크가 있을까요?
이걸로 다른 사람들이 우리 대담한 발자취를 좀 더 빨리 따를 수 있을지도 모릅니다.
제 무료 웹 검색 AI가 이렇게 말하더라고요:
일반적인 Rails 앱에서 PostgreSQL 15 → 18로 업그레이드하면 코드 변경 없이 약 10–25% 더 빠른 쿼리 성능을 기대할 수 있으며, 새로운 인덱싱 및 플래너 기능을 활용하면 특정 쿼리 패턴에서 **최대 40%**까지 성능이 향상될 수 있습니다.
만약 사실이라면 꽤 상당한 업그레이드네요! 
7개의 좋아요
자체 호스팅 인스턴스에서 모든 것이 완벽하게 진행되었는지 확인하기 위한 것입니다. 이번 업데이트에 감사드리며, 앞으로의 소식도 알려주시길 바랍니다.
5개의 좋아요
맞습니다. 하지만 우리는 단순하고 투명한 업그레이드 메커니즘을 지향하고 있습니다. 양쪽 모두 장점이 있습니다.
필요에 따라 discourse_docker의 템플릿을 커스터마이징하는 것을 두려워하지 마시고, 편안하게 진행하시면 됩니다. 물론 핵심은 먼저 테스트를 수행하고 롤백 계획을 갖추는 것입니다.
저희 호스팅 플랫폼에서는 이러한 기능을 활성화하기 전에 더 많은 테스트와 벤치마킹을 수행할 계획이므로, 설정을 일치시키기 위해 discourse_docker에서도 이를 비활성화했습니다. 비활성화는 엄밀히 말해 필수적이지는 않습니다(내부적으로 discourse_docker의 웹 컨테이너 부분만 사용하므로) 그리고 활성화하는 것에 반대하지 않습니다.
잠재적인 함정 중 하나는 pg_upgrade가 구버전과 신버전의 데이터 디렉터리가 서로 다른 체크섬 설정을 가지고 있으면 작동하지 않는다는 점입니다. 프로세스는 PG15 서버를 종료한 후, 체크섬 없이 PG18로 변환하기 위해 pg_upgrade를 실행하고, pg_checksums를 실행하여 체크섬을 활성화한 다음 PG18을 시작하는 순서여야 합니다. 이는 덤프 및 복원(이번 업그레이드와 같이)을 수행할 때는 문제가 되지 않지만, 주의해야 할 사항입니다.
참고로 데이터 체크섬은 Postgres 9.3부터 사용 가능했지만, 지금까지는 기본적으로 비활성화되어 있었습니다. Postgres 19에서는 온라인으로 이를 활성화/비활성화할 수 있는 기능도 포함될 예정입니다.
현재로서는 아닙니다. Discourse 기능의 대부분은 데이터베이스와 통신하기 위해 Rails PostgreSQL 어댑터를 사용하지만, 백업/복원은 웹 컨테이너의 pg_dump와 psql를 사용합니다. 현재는 이 두 버전을 모두 사용하여 백업/복원을 가능하게 하기 위해 PG15와 PG18 클라이언트를 모두 설치하고 있지만, 미래의 시점에서 PG15를 제거할 것입니다.
주된 동기는 새로운 내장 로케일 제공자(builtin locale provider)로 전환하는 것이었습니다. 저희는 호스팅 플랫폼에서 OS 업그레이드를 추진하고 있으며, glibc와의 결합을 끊고 싶어 합니다.
3개의 좋아요
저는 Postgres를 컨테이너와 독립적으로 관리하고 있습니다. pg18로 전환해야 할 권장 git 해시는 무엇인가요?
1개의 좋아요
e7f1201에서 백업 호환성을 위해 웹 이미지(PG18 클라이언트)에 PG18 클라이언트를 추가했습니다. discourse_docker의 Postgres 서버 구성 요소를 사용하지 않는 경우, PG18을 위해 사용해야 할 가장 초기 리비전은 이 것입니다.
1개의 좋아요
저는 1~2개 버전 전의 업그레이드에 대해 이야기하고 있었습니다.
동의합니다. 제 지점은 단순히 더 오래된 postgres 백업을 더 새로운 버전으로 복원하는 것이 지원되지 않는다는 뜻은 아니라는 것이었습니다. 제자리 업그레이드(in-place upgrade) 메커니즘은 대부분의 사용자에게 놀라울 정도로 잘 작동하지만, 문제가 발생하면 무엇을 해야 할지 알기 어렵습니다(대부분 매우 드물게 발생하기 때문이죠).
2개의 좋아요
누군가에게 도움이 되길 바랍니다. SSH 콘솔이 멈춰 있는 동안, 그리고 차가운 불안감에 식은땀이 흐르기 시작할 때…
진행 상황을 지켜볼 수 있도록 다른 터미널에서 다음 명령어를 실행했습니다:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'이 명령어는 10초마다 상태를 갱신해 주며, 정신을 차려 있게 해 줍니다
제 35GB 마이그레이션에는 약 10분이 걸렸습니다.
8개의 좋아요
표준 설치로 업데이트를 진행했는데 아무 문제없이 잘되었습니다. 혹시 모를 상황에 대비해서 당연히 백업도 미리 받아 두었죠 
3개의 좋아요
좋아요. 거기에 free -h를 추가하겠습니다. 메모리 부족은 흔한 문제니까요.
watch나 top의 유일한 단점은 화면이 계속 새로고침되어 무언가를 놓칠 수 있다는 점입니다. 리소스가 고갈되어 업데이트가 실패하면, 몇 초 후에 기록을 잃어버리게 됩니다. 그래서 저는 while 루프를 사용하는 편입니다. 예를 들어 이렇게요:
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4개의 좋아요
성공 소식을 전할 수 있습니다. 멀티사이트 설정의 절반에 대해서는 성공적이었습니다. 기본 사이트는 예상대로 마이그레이션되었지만, 부가 사이트는 마치 새로 설치한 것처럼 보였습니다. 다행히 백업을 복원하는 것은 어렵지 않습니다. 저는 고객들을 위해 사용하는 다른 서버가 있는데, 이 업데이트를 수행하기 위해 새로운 Droplet을 생성하고 백업에서 사이트를 복원하는 것을 고려하고 있습니다. 아마도 이것이 표준이 아닌 설치 방식을 사용할 때의 위험 중 하나일 것입니다.
1개의 좋아요
데이터 컨테이너가 표준 데이터 컨테이너였나요? 클러스터 내의 데이터베이스 하나만 이동하는지, 아니면 모든 데이터베이스를 이동하는지 궁금해하고 있었습니다. 질문을 답해 주셨네요!
저는 구 클러스터에서 새 클러스터로 각 데이터베이스를 수동으로 옮긴 후, discourse.conf 파일을 수동으로 편집하여 새 데이터베이스를 가리키도록 하고, 다시 빌드(rebuild)하여 멀티사이트 컨테이너 전체를 새 클러스터(다른 머신 또는 포트)로 연결하는 방식으로 진행해 왔습니다.
1개의 좋아요
네. 물론 제 설정에서 뭔가 잘못한 부분이 없는지는 단정할 수 없어요. 
postgres 데이터를 rsync로 동기화해서 거기에 qn 업그레이드를 실행하고, 이 프로세스가 discourse 데이터베이스만 이동하는지 아니면 전체 클러스터를 이동하는지 확실하게 확인하려고 계획하고 있었습니다. 하지만 질문이 이미 답변된 것 같고, 코드를 살펴보면 명확해질 것 같습니다.
2개의 좋아요
여기 두 가지 질문이 있습니다:
- 테스트 서버에 추가 저장 블록을 마운트했습니다. 하지만 PostgreSQL 업그레이드가 공간 확인이 메인 디스크만 검사하기 때문에 실패합니다. 공간 확인을 우회할 수 있는 방법이 있을까요?
- 프로덕션 사이트에는 Google Cloud SQL을 사용하고 있습니다. Google Cloud를 통해 업그레이드하기 전에 알아야 할 사항이 있을까요?