우리 포럼에 대규모 인프라 변경이 이루어졌고, 현재 성능이 좋지 않습니다.
데이터베이스를 DigitalOcean의 관리형 데이터베이스로 마이그레이션했고, S3 에셋은 Cloudflare를 앞에 두고 Minio 인스턴스에 배치했습니다.
또한, Discourse를 더 작은 VM으로 재배포했지만, 부하를 처리할 충분한 리소스는 확보되어 있습니다.
확인해 본 결과, 몇 가지 Postgres 쿼리가 매우 오래 걸리고 있습니다:
21초
19초
그럼 되돌리라는 뜻인가요?
다만 다른 분들이 이 방법을 시도해 보셨을 수도 있고, 그런 구성을 개선하는 팁을 알려주실 수도 있겠네요.
왜 지원되지 않나요?
discourse에는 app.yml에 외부 데이터베이스 옵션이 있나요?
대형 서버를 확장하려고 하고 있습니다.
실수했어. 일단 그거 제거할게 
관리형 데이터베이스가 인스턴스와 얼마나 가까운 곳에 있나요? 같은 네트워크 안에 있나요?
네, 서버도 DO(디지털오션)예요.
지금은 지원 가이드에 따라 기본 설치(bone-stock install)를 하고 데이터베이스를 가져올 거예요.
그다음에 어떤 일이 일어나는지 한번 봐야겠어요.
데이터베이스 마이그레이션을 수동으로 실행하는 방법이 있을까요?
하지만 postgres 서버가 부하를 처리하기에 충분하지 않은 것 같습니다? 데이터베이스 크기는 어느 정도이며, postgres 서버의 RAM 용량은 얼마인가요?
postgres 서버가 정상적으로 작동하는지 확인해 보기를 기다렸어야 하지 않나요?
음, 대부분 표준 설치만 "지원"되는 경우이기 때문입니다. 외부 데이터베이스는 작동할 수 있지만, 추측하기 어려운 많은 변수들이 추가됩니다.
그것은 덜 지원되는 영역입니다. 얼마나 큰가요? 그리고 여러 가지 것들이 얼마나 큰가요? 데이터베이스, 데이터베이스 서버, 실행 중인 드롭렛(droplet), 드롭렛과 데이터베이스 사이의 대역폭 등등.
시작하기에 좋은 방법입니다. 그런 다음 항목들을 하나씩 확인해 나가면 됩니다.
보통 컨테이너를 부트스트랩할 때 자동으로 이루어지지만, 컨테이너에 진입하여
cd /var/www/discourse
bin/rails db:migrate
간단한 베어 설치조차 작동하지 않으며, 데이터베이스도 전혀 복원하지 않았습니다.
깨끗한 VM에서 discourse-setup을 실행했는데, 가입 기능이 작동하지 않습니다.
명령줄을 통해 복원을 시도했지만, discourse restore 명령에 백업 목록이 표시되지 않습니다.
수정: 두 번째 완전한 재구축 후에 작동했습니다.