안녕하세요,
로드 밸런서 뒤에 web_only 컨테이너가 있는 멀티 노드 환경에서 설정을 변경할 때 일부 설정이 단일 노드(변경 사항을 로드 밸런서를 통해 연결한 노드일 가능성이 높음)에만 적용되는 것을 확인했습니다. 특히 Global notice, Globally pinned posts, 그리고 최근 커스텀 테마를 업데이트하기 위해 테마를 변경할 때 이러한 문제가 발생했습니다.
결국 변경 사항은 사용자가 변경 사항이 이루어진 동일한 노드에 로드 밸런서를 통해 연결된 경우에만 표시됩니다. 이로 인해 일부 경우 페이지 로드가 혼재되고 사이트 렌더링이 엉망이 되기도 합니다.
질문이 있습니다. 이러한 변경 사항 이후에 rake를 통해 모든 노드에서 설정 재로드 명령을 실행해야 하는지, 아니면 컨테이너 실행 시 설정이 자동으로 재로드되고 클러스터 모드로 설정이 자매 노드에 자동으로 전파되도록 특정 환경 변수를 추가해야 하는지 궁금합니다.
네, 다음을 시도해 볼 수 있습니다:
su discourse -c 'bundle exec rake cache:clear'
대신, rails 콘솔에 들어가고 싶다면 SiteSetting.refresh!을 사용하는 것이 같은 효과를 낼 수 있지만, 사이트 설정에 더 특화되어 있습니다.
감사합니다! 뭔가 빠뜨린 것 같은 느낌이 들었습니다. 어떤 설정 변경 후에 이러한 작업이 필요한지에 대해 언급된 문서가 있을까요? 문서들을 빠르게 살펴봤지만 해당 사항이나 HA 설정에 관한 내용은 찾지 못했습니다.
수정: cache:clear가 사용 불가능한 것 같습니다.
docker exec -it web_only bash
root@discourse-build-web-only:/# cd /var/www/discourse
root@discourse-build-web-only:/var/www/discourse# su discourse -c 'bundle exec rake cache:clear'
rake aborted!
Don't know how to build task 'cache:clear' (See the list of available tasks with `rake --tasks`)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
(See full trace by running task with --trace)
--tasks로 확인해봐도 해당 작업이 보이지 않습니다.
확인 차 질문드립니다: 모든 노드 사이에 공유되는 Redis 데이터베이스가 있나요? 이는 Discourse가 작동하는 데 필수적입니다.
(다른 일부 애플리케이션은 노드당 Redis 하나씩을 사용하는 방식으로 작동하지만, Discourse에서 그렇게 하려 하면 설명하신 유형의 문제가 발생합니다)
네. Redis는 모든 discourse 노드 인스턴스에서 공유됩니다. HA(고가용성) 설치를 위해 S3, Redis, PostgreSQL을 각각 별도로 구성했습니다.
/logs에서 Global messages on xx timed out, message bus is no longer functioning correctly와 유사한 오류 메시지를 확인하시나요?
이전에 Redis와 메시지 버스가 서로 다른 호스트에서 실행되면 타임아웃이 발생하여 서로 다른 Unicorn 워커 간 동기화가 실패한다는 사실을 발견했습니다.
제 우회 방법은 Unicorn 서버 전체를 주기적으로 재로드하는 것이었습니다.
모든 노드의 로그를 grep으로 검색해 보았지만, 해당 로그 항목을 찾을 수 없습니다.
아, 결국 Global messages on xx timed out, message bus is no longer functioning correctly 메시지가 있었던 거군요. 하지만 실수로 실제 로그 디렉터리만 확인하고 있었습니다. 이제 웹 인터페이스의 로그 오류 섹션을 살펴보니 말씀하신 항목들이 실제로 보이네요. Discourse에서는 서로 다른 오류가 서로 다른 위치에 표시된다는 점에 익숙해져야 할 것 같습니다. 그래도 Discourse 웹 인터페이스에 이런 기능이 있는 것은 여전히 좋은 점입니다.
안녕하세요 @david, PR을 열었습니다: fix: subscriber thread never self heals after half open tcp connection by Mubramaj · Pull Request #388 · discourse/message_bus · GitHub
이 PR은 Global messages on xx timed out 문제를 해결하고, @pangbo 님의 전체 Unicorn 서버를 주기적으로 재로드하는 임시 해결책이 필요 없도록 합니다.