helmi
(Helmi)
2월 12, 2025, 12:30오후
1
저희는 VPS 환경에서 비교적 큰 규모의 Discourse를 운영 중이며, 현재까지는 잘 작동하고 있습니다. CPU/메모리 성능 측면에서는 여유가 있습니다. 다만 디스크 용량이 다소 부족합니다. 일상적인 운영에서는 문제가 되지 않지만, 예를 들어 Postgres를 업그레이드할 때(13에서 15로의 업그레이드가 용량 부족으로 아직 미완료 상태입니다) 용량이 부족하여 쉽게 확장할 수 없는 상황입니다.
Postgres 업데이트를 위한 다른 옵션들이 있다는 점은 알고 있지만, 이번 질문은 좀 더 일반적인 관점에서 드리는 것입니다.
저희는 Hetzner를 사용 중이며, 임시로 사용할 네트워크 스토리지가 쉽게 이용 가능합니다.
현재 테스트 서버에서 이를 임시로 구성해 보는 중입니다. 먼저 라이브 사이트의 백업을 복원하고, 이후 Postgres 업그레이드를 테스트할 예정입니다. 아직까지 성공하지는 못했습니다.
이미 심볼릭 링크를 시도해 보았지만 작동하지 않았으며, 여기 어딘가에서 이것이 권장되지 않는 방법이라는 것도 읽었습니다. 또한 /shared 공유 폴더를 /var/discourse/shared/standalone에서 /mnt/ext-storage/standalone으로 이동하고 파일을 옮겨 보았지만, 아쉽게도 문제가 발생했습니다. 빌드조차 완료할 수 없습니다.
이러한 경우를 위해 작동하는 방법이 있을까요? 해당 드라이브의 성능이 로컬 드라이브보다 훨씬 낮다는 점은 인지하고 있으며, 포럼을 그 위에 실행할 계획은 없습니다. 다만 특정 시나리오에서 이를 편하게 활용할 수 있는 방법을 찾고 싶습니다.
pfaffman
(Jay Pfaffman)
2월 12, 2025, 2:31오후
2
업그레이드를 가장 쉽게 진행하려면 새로운 VM을 생성하고 그로 마이그레이션하는 것이 좋습니다. 이렇게 하면 데이터베이스 업그레이드가 필요 없으며, VM에 새로운 운영체제가 설치됩니다. 어차피 해야 할 일이므로 일석이조입니다.
Move a Discourse site to another VPS with rsync 가이드를 따르되, 데이터베이스는 복사하지 마세요(하지만 업로드 폴더, Let’s Encrypt, 인증서는 복사해야 합니다).
백업이 S3에 저장되어 있다면, 기존 서버를 정지(freeze)하고 백업을 만든 후 새 머신에 백업을 복원하는 과정은 매우 간단합니다.
Hetzner가 다른 서버에 할당할 수 있는 영구 IP를 제공한다면, DNS 변경조차 필요 없습니다.
새 서버를 구축할 수 있는지 확인하는 것이 좋습니다. 만약 어떤 이유로든 이를 해야 하는 상황이 발생했을 때 대응할 수 있도록 하기 위함입니다. 지금이 연습하기에 완벽한 기회입니다.
helmi
(Helmi)
2월 12, 2025, 2:41오후
3
사실 이건 선택지가 아닙니다. 일상적인 용도로는 공간이 부족해지는 상황이 아니에요. 게다가 현재 600GB 드라이브를 사용 중인데 약 50%만 쓰고 있습니다. 더 큰 용량의 옵션은 없어요 — 적어도 Hetzner에서는요.
그래서 저는 외부 드라이브를 명시적으로 요청한 것입니다.
호기심으로 ./launcher cleanup app을 실행해 보셨나요? 그 작업으로 인플레이스 업그레이드를 수행할 수 있는 충분한 공간이 확보되지 않았나요?
helmi
(Helmi)
2월 12, 2025, 3:00오후
5
재구축에는 영향을 주지 않아야 하지 않나요? 단순 재시작이라면 이해할 수 있지만, 재구축까지 영향이 있어야 하나요?
pfaffman
(Jay Pfaffman)
2월 12, 2025, 3:01오후
6
더 큰 드라이브로 교체하라는 건 아니었고, 그냥 그 서버와 똑같은 새 서버를 하나 더 세팅하라는 거였어요. Discourse를 설치하고 데이터베이스를 복원하면 됩니다.
정말 좋은 질문입니다.
영향이 있습니다. 리빌드할 때마다 새로운 컨테이너가 생성되고, 각각의 컨테이너가 공간을 차지합니다. 한 번도 해보지 않으셨다면 수십 GB의 공간을 확보할 수 있을지도 모릅니다.
데이터베이스 업그레이드에는 확보할 수 있는 모든 공간이 필요합니다. 그러므로, 네. 중요한 문제라고 생각합니다.
Falco
(Falco)
2월 12, 2025, 3:49오후
8
Helmi:
이런 경우에 적용되는 방법이 있나요?
업데이트 가이드에 해당 사용 사례를 위한 가이드가 포함되어 있습니다
Mwaniki Wairungu:
수동 업데이트 / 공간이 제한된 환경
더 이상의 공간을 확보할 수 없는 공간이 제한된 환경에 계신 경우, 다음을 시도해 볼 수 있습니다:
./launcher stop app #(또는 해당되는 경우 web_only와 data 둘 다)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
--entrypoint=/bin/bash \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c "apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
docker-upgrade"
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data #(또는 local_discourse/data)
./launcher rebuild app #(또는 해당되는 경우 먼저 data를 실행한 후 web_only 실행)
테스트 결과, 이 절차에는 현재 데이터베이스 크기의 1배 미만의 자유 공간이 필요합니다.
여러분과 같은 상황에 있는 사람들을 위해 이 옵션을 추가했습니다. 이 작업을 시도하기 전에 반드시 백업을 다른 위치에 저장해 두세요!
pfaffman
(Jay Pfaffman)
2월 12, 2025, 6:11오후
9
VM을 사용 중이라면, 새 VM으로 이전하는 것이 훨씬, 훨씬 쉬우며 여러 가지 이점이 있습니다. 몇 가지 예를 들면 다음과 같습니다:
위험이 전혀 없습니다 — 문제가 발생해도 기존 서버가 그대로 유지됩니다.
다운타임이 전혀 없습니다 (기존 서버는 읽기 전용으로 유지됩니다).
아마도 어차피 필요할 OS 업그레이드를 받을 수 있습니다.
재앙이 발생했을 때 새 서버를 시작하는 방법을 알고 있는지 확인할 수 있습니다.
재인덱싱과 vacuum 작업을 다시 수행할 필요가 없습니다.
helmi
(Helmi)
2월 13, 2025, 8:29오전
10
여러분의 조언에 감사드립니다.
감사합니다. 제가 이미 알고 있다고 말했던 다른 옵션이 바로 그것입니다. 그럼에도 불구하고 알려주셔서 감사합니다.
그렇지 않다고 의심하는 것은 아닙니다 - 하지만 그래도 필요할 경우 유지보수 작업을 위해 추가 저장소를 추가하는 옵션을 탐색해 보고 싶었습니다.
pfaffman
(Jay Pfaffman)
2월 13, 2025, 10:20오전
11
업로드 파일이나, 예를 들어 /var/discourse/shared/web_only를 네트워크 저장소에 유지하는 것이 유용할 수 있습니다. 심볼릭 링크를 사용하는 대신, 해당 경로를 가리키도록 yml 파일을 수정해야 합니다. (심볼릭 링크는 컨테이너가 심볼릭 링크가 가리키는 위치에 접근할 수 없기 때문에 작동하지 않습니다.)
이렇게 하면 새로운 VM으로 이전할 때 파일을 복사하는 대신 해당 네트워크 저장소를 다시 마운트하면 됩니다.
데이터베이스에는 네트워크 저장소를 권장하지 않습니다. 성능이 더 느리기 때문입니다.
Ed_S
(Ed S)
2월 13, 2025, 2:06오후
12
사용량에 대해 자세히 분석해 볼 가치가 있다고 생각합니다. 대부분의 사용량이 업로드에 사용되고 있다면 실제 데이터베이스 크기는 그렇게 크지 않을 수 있으며, 업그레이드 시 3배의 공간을 요구하는 부분은 데이터베이스 부분일 수 있습니다.
확인해 볼 수 있는 방법 중 하나는 다운로드를 포함한 백업과 다운로드를 제외한 백업의 상대적 크기를 비교하는 것입니다.
또는 명령줄을 사용할 수도 있습니다. 제 비교적 작은 포럼의 출력 결과를 아래에 첨부합니다:
root@rc-debian-hel:~# free -m
total used free shared buff/cache available
Mem: 3813 1631 267 492 1915 1504
Swap: 4095 730 3365
root@rc-debian-hel:~# swapon
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 730.2M -2
/var/local/swap/swapfile.3 file 1024M 136K -3
/var/local/swap/swapfile.0 file 1024M 0B -4
/var/local/swap/swapfile.2 file 1024M 0B -5
root@rc-debian-hel:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 382M 1.2M 381M 1% /run
/dev/sda1 38G 22G 14G 62% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda15 253M 6.3M 246M 3% /boot/efi
overlay 38G 22G 14G 62% /var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766/merged
tmpfs 382M 0 382M 0% /run/user/0
더 자세히 살펴보면:
root@rc-debian-hel:~# du -kx / | sort -n | tail -33
767000 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local/share/pnpm
767004 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local/share
767020 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse/.local
795804 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home/discourse
795808 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff/home
833836 /var/discourse/shared/standalone/postgres_data
884648 /var/discourse/shared/standalone/uploads/default/original
978000 /usr/lib/modules
991644 /var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766/diff
991664 /var/lib/docker/overlay2/68abab42f48040e0dfc03d3c9fc893dfa3e7fb01ba1b2215731668339bbc3766
1025164 /var/discourse/shared/standalone/uploads/default/optimized
1146528 /usr/lib/firmware
1350496 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554/diff
1350512 /var/lib/docker/overlay2/8b6ac2d69a1fa195285e61aba2876484a69fd2a19032c2f4def1c4adb02d6554
1909816 /var/discourse/shared/standalone/uploads/default
1919380 /var/discourse/shared/standalone/uploads
2471968 /usr/lib
2506940 /var/log/journal/82e4cf9bff9748d090b41e6d336353eb
2515140 /var/log/journal
2592200 /var/log
3029428 /usr
3839148 /var/discourse/shared/standalone/backups/default
3839152 /var/discourse/shared/standalone/backups
4194324 /var/local/swap
4194328 /var/local
5171844 /var/lib/docker/overlay2
5217052 /var/lib/docker
5455612 /var/lib
6682972 /var/discourse/shared/standalone
6682976 /var/discourse/shared
6685716 /var/discourse
19041368 /var
23037264 /
root@rc-debian-hel:~# du -kx /var/discourse/shared/ | sort -n | tail -33
42312 /var/discourse/shared/standalone/uploads/default/original/2X/f
42448 /var/discourse/shared/standalone/uploads/default/original/2X/1
42548 /var/discourse/shared/standalone/uploads/default/original/2X/6
43380 /var/discourse/shared/standalone/uploads/default/optimized/2X/2
44148 /var/discourse/shared/standalone/uploads/default/optimized/2X/5
44340 /var/discourse/shared/standalone/uploads/default/optimized/2X/1
45240 /var/discourse/shared/standalone/uploads/default/optimized/2X/e
46648 /var/discourse/shared/standalone/uploads/default/optimized/2X/c
49516 /var/discourse/shared/standalone/uploads/default/optimized/2X/8
49772 /var/discourse/shared/standalone/uploads/default/optimized/2X/9
49932 /var/discourse/shared/standalone/log/var-log/nginx
50788 /var/discourse/shared/standalone/uploads/default/optimized/2X/0
55428 /var/discourse/shared/standalone/uploads/default/optimized/2X/d
55844 /var/discourse/shared/standalone/uploads/default/optimized/2X/f
57548 /var/discourse/shared/standalone/uploads/default/optimized/2X/6
77280 /var/discourse/shared/standalone/log/var-log
81928 /var/discourse/shared/standalone/postgres_data/pg_wal
84064 /var/discourse/shared/standalone/log
294384 /var/discourse/shared/standalone/uploads/default/optimized/1X
325068 /var/discourse/shared/standalone/uploads/default/original/1X
559576 /var/discourse/shared/standalone/uploads/default/original/2X
724684 /var/discourse/shared/standalone/postgres_data/base/16384
730776 /var/discourse/shared/standalone/uploads/default/optimized/2X
749424 /var/discourse/shared/standalone/postgres_data/base
833836 /var/discourse/shared/standalone/postgres_data
884648 /var/discourse/shared/standalone/uploads/default/original
1025164 /var/discourse/shared/standalone/uploads/default/optimized
1909816 /var/discourse/shared/standalone/uploads/default
1919380 /var/discourse/shared/standalone/uploads
3839148 /var/discourse/shared/standalone/backups/default
3839152 /var/discourse/shared/standalone/backups
6682972 /var/discourse/shared/standalone
6682976 /var/discourse/shared/
helmi
(Helmi)
2월 13, 2025, 2:21오후
13
처음에는 더 정확히 설명했어야 했는데, 이렇게 폭넓은 피드백을 받을 줄은 몰랐습니다.
업로드와 백업은 S3에 저장되어 있습니다. 현재 라이브 시스템의 데이터베이스 크기는 약 230GB입니다. 압축된 백업은 약 25GB 정도인 것 같습니다.
Falco
(Falco)
2월 13, 2025, 4:16오후
14
와, 정말 큰 규모네요! 그 정도 크기라면 데이터베이스 운영이 보통은 좀 더 까다로워지죠.
helmi
(Helmi)
2월 14, 2025, 8:12오전
16
아니요, autovacuum이 자동으로 처리해 줄 거라고 생각했는데? 아니야?
pfaffman
(Jay Pfaffman)
2월 14, 2025, 6:39오후
17
그렇게 되어야 한다고 생각합니다. 다만, 정확히 무엇이 이를 트리거하는지 명확하지 않습니다. 추가로 한 번 실행해도 해롭지는 않을 것이며, 오히려 공간을 절약할 수 있을 것입니다. 인플레이스(in-place) 업그레이드를 수행한 경우, 업그레이드 후 실행하는 것이 권장됩니다. 몇 번의 경험을 통해 상당한 공간이 정리되는 것을 본 적이 있습니다.
데이터베이스 크기가 230GB라면, 새 서버로 복원하는 것이 확실합니다. 230GB에 대한 읽기/쓰기 중단 시간은 상당할 것입니다.