Redis 오류로 Unicorn 로그에 포럼 사용 불가(

제품 지원 자체 호스팅
1

안녕하세요.

저는 제 머신에 두 개의 포럼을 호스팅하고 있으며, 둘 다 최신 상태입니다(하나는 3.4.0.beta3-dev 버전이고, 접근할 수 없는 다른 하나는 확인이 불가능합니다).

이 중 하나는 이번 주早些에 업데이트를 마쳤는데, 약 2일 전부터 갑자기 작동이 멈췄습니다.

로그인하면 모든 페이지에 “Oops” 메시지가 표시됩니다.

컨테이너에 접속하여 unicorn 로그를 확인해 보니 redis 연결에 문제가 있는 것으로 보입니다:

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

문제는 컨테이너 내에서 redis-cli를 통해 redis 서버에 연결하고 키를 설정 및 가져오는 것은 정상적으로 작동하는데, 왜 이런 문제가 발생하는지 이해가 안 된다는 점입니다.

포럼에서 비슷한 문제를 많이 보았는데, 대부분 오래되었거나 해결되지 않은 상태입니다. 도와주실 수 있는 분 계신가요? 필요하시면 추가 정보를 제공할 수 있습니다.

2

이전에는 작동했나요?

언제부터 시작했나요?

표준 app.yml 파일이 두 개 있고, 각각에 Redis와 postgres 템플릿이 있으며 데이터 경로도 다른가요?

가능성 중 하나는 권한 문제입니다. 어떤 시점에 사용자와 그룹의 ID가 변경되었지만, 단일 컨테이너 환경에서는 그로 인해 문제가 발생한 것을 본 적이 없습니다.

3

제 문제를 확인해 주셔서 감사합니다.

네, 약 3일 전까지는 정상적으로 작동했습니다. 하지만 오늘 아침 컨테이너 내에서 CLI를 통해 백업을 실행해 보았더니 이상한 postgres 오류로 인해 실패했습니다. 그래서 데이터베이스가 어떻게 손상된 것 같습니다. 이는 위에서 언급한 오류 메시지와는 전혀 관련이 없지만, 8일 전의 정상적인 백업(포럼 운영자가 이를 허용합니다)을 복원하여 모든 문제가 해결되는지 확인해 보고 싶습니다.

예전 버전의 Discourse 백업을 더 새로운 버전으로 복원할 수 있을까요? (백업 시점과 현재 사이에 업데이트가 있었기 때문입니다.)

수정: 명확히 하자면, 두 포럼은 서로 다른 yaml 파일이며, 따라서 각각 독립적인 컨테이너와 데이터 디렉토리를 사용하고 있습니다.

4

백업에서 실패한 건가요, 복원 시에 실패한 건가요?

실제로 그 이상한 오류 메시지를 포함해 주시면 도움이 될 것입니다. 하지만 복원 시에 발생한 문제라면, 여기에서 설명된 오류일 가능성이 높습니다: Restore failing with missing chat_mention function

만약 맞다면, 제 조언은 기다리는 것입니다. 기다릴 수 없는 상황이라면, 복원하려는 사이트가 백업을 생성한 사이트와 동일한 커밋을 가지고 있는지 확인해 볼 수 있습니다.

5

백업에 있습니다.

pg_dump: error: Dumping the contents of table "posts" failed: PQgetResult() failed.
pg_dump: error: Error message from server: ERROR:  could not open file "base/16384/17044": No such file or directory

그래서 먼저 백업을 복원해 보려고 합니다. 이렇게 하면 문제가 해결될지 확인해 보고 싶어서요. :slight_smile:

6

그것은 데이터베이스 문제인 것 같습니다.

파일시스템 백업을 복원해 본 적이 있으신가요? 데이터베이스가 실행 중인 상태에서 파일시스템 백업을 수행하면 이런 문제가 발생할 수 있습니다. 그래서 저는 파일시스템 백업을 권장하지 않는 이유 중 하나입니다.

보통 권장하는 discourse 백업 복원을 원하신다면, 데이터베이스를 삭제한 후 빈 데이터베이스를 생성하고 마이그레이션을 수행한 다음 복원을 진행해야 합니다.

7

파일 시스템 백업을 수행하지만, PostgreSQL 데이터베이스는 덤프를 별도로 생성하기 때문에 제외합니다. 다만, Discourse 폴더를 제외하는 것을 깜빡했을 수도 있으니 나중에 확인해봐야겠습니다.

이 스레드의 정보는 제 사용 사례에도 여전히 유효한가요?

8

백업 파일을 필요한 위치에 배치하는 방법에 대한 설명은 불필요하게 복잡해 보입니다.

9

오케이, 원인을 찾았어요. 파일 시스템에 대해 올바른 방향으로 이끌어 주셔서 감사합니다. 바이러스 스캔을 실행한 결과, 누군가 포럼에 바이러스 시그니처가 있는 파일을 업로드한 것을 발견했습니다. 그 결과 clamav가 해당 파일을 삭제했습니다. 이제 postgres 파일이 다시 격리되지 않도록 설정을 더 잘 조정할게요.

시간을 낭비하게 해서 죄송합니다 :slight_smile:

10

좋아요! 제 힌트가 도움이 되었다니 기쁩니다! 저는 그걸 전혀 생각하지 못했을 텐데, 사실 바이러스 소프트웨어를 아주 오래 전에 사용한 적이 없거든요.