./launcher rebuild app 명령어를 실행했습니다.
redis is now ready to exit, bye bye ... 이 메시지가 discourse를 멈추게 합니다. 40분간 멈춰 있다가 ctrl + c로 중단했습니다.
계속 로딩만 됩니다. 그 결과 새 컨테이너가 생성되지 않았습니다. 원인을 찾기 위해 discourse의 어떤 로그를 확인하면 도움이 될 수 있는지 설명해 주실 수 있나요?
이것이 리소스 할당 문제일 수 있을까요?
이 서버에 호스팅된 다른 웹사이트나 서비스가 있나요? 서버에서 사용 가능한 RAM/CPU 용량은 얼마인가요?
이것은 정상적인 현상입니다.
이것은 정상적이지 않습니다. 해당 메시지가 표시된 후 보통 1분도 채 안 되어 새 컨테이너가 시작됩니다.
이 과정을 여러 번 시도해 보셨고, 동일한 결과가 나왔나요?
네, 여러 번 시도했지만 결과는 동일했습니다.
브랜치 3d050bdaa31633a954758894629c0eb9fea537d0에 있었습니다
fe71c43c57c0248a8264245cb6ff0dc114da335a로 업그레이드하려고 했는데
discourse가 멈추버리네요 !!
production.log
Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:139:in `block in call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:293:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:138:in `call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:44:in `subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:13:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:3468:in `_subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2301:in `block in subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2300:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:287:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH) subscribe failed, reconnecting in 1 second. Call stack ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:125:in `call'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:915:in `block in get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:914:in `get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:360:in `process_global_backlog'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:271:in `block in global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:284:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Job exception: Error connecting to Redis on localhost:6379 (Errno::ENETUNREACH)
Creating scope :visible_groups. Overwriting existing method Group.visible_groups.
Creating scope :visible. Overwriting existing method Notification.visible.
Creating scope :public_posts. Overwriting existing method Post.public_posts.
Creating scope :private_posts. Overwriting existing method Post.private_posts.
Creating scope :open. Overwriting existing method Poll.open.
Migrating to CreateDiscourseVotingCategorySettings (20200727220143)
Migrating to CreateDiscourseVotingVotes (20200728222920)
Migrating to CreateDiscourseVotingTopicVoteCount (20200729042607)
Creating scope :visible_groups. Overwriting existing method Group.visible_groups.
Creating scope :visible. Overwriting existing method Notification.visible.
Creating scope :public_posts. Overwriting existing method Post.public_posts.
Creating scope :private_posts. Overwriting existing method Post.private_posts.
Creating scope :open. Overwriting existing method Poll.open.
Creating scope :visible_groups. Overwriting existing method Group.visible_groups.
Creating scope :visible. Overwriting existing method Notification.visible.
Creating scope :public_posts. Overwriting existing method Post.public_posts.
Creating scope :private_posts. Overwriting existing method Post.private_posts.
Creating scope :open. Overwriting existing method Poll.open.
ubuntu 14.04는 꽤 오래된 버전인 것 같습니다. 지난 몇 주 동안 14.04 관련 문제가 발생했다는 게시글을 몇 건 확인했습니다:
https://meta.discourse.org/search?q=14.04%20order%3Alatest
5월 이후로 의존성 관계가 변경되면서 무언가가 깨진 것일 수도 있습니다 
답변 주셔서 감사합니다.
새로운 서버에는 Ubuntu 20.04.1 LTS와 Docker가 설치되어 있습니다.
기존의 prod-forum을 이 서버로 옮기는 방법은 무엇인가요?
단계별 매뉴얼을 제안해 주실 수 있을까요?
일반 가이드를 사용하여 처음부터 빌드합니다. app.yml 파일을 복사합니다. 다시 빌드합니다. 첫 번째 서버의 Discourse 백업 파일을 가져옵니다. 완료.
(아, 도메인의 IP를 재매핑하는 작은 문제도 있네요!)
좋긴 한데, 관리 패널을 통해 백업을 만드는 방식은 우리에게 작동하지 않네요))
docker 컨테이너를 이전하려면
docker ps -a
docker commit c559bec6f29a local_discourse/app
docker save local_discourse/app > /tmp/local_discourse_app.tar.gz
scp /tmp/local_discourse_app.tar.gz root@my-new-server:/tmp/
---
docker load < /tmp/local_discourse_app.tar.gz
docker run local_discourse/app
이 단계에서 문제가 발생합니다 - NoMethodError on docker run - #8 by Dev_Work
외부에 기존 백업이 전혀 없나요?
새로운 데이터가 포함된 사본이 필요합니다(새로운 백업은 제외)
안녕하세요 @Dev_Work
문제가 발생하셨다니 안타깝습니다.
다시 한번 확인해 보겠습니다:
- 사이트 전체를 수동으로 백업했으며, 해당 백업 파일은 다음과 같습니다:
discourse-2020-08-24-103334-v20200811004537.tar.gz
- 그런 다음 표준 방법으로 Discourse를 처음부터 설치했습니다:
https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
-
이 작업은 docker가 설치되고 테스트가 완료된 완전히 새로운 ubuntu 20.04.1 LTS 서버에서 수행했습니다.
-
그런 다음 위에서 언급한 백업 파일을 사용하여 새 서버에서 수동으로 복원했나요?
이 내용이 맞는지, 그리고 현재 이 단계까지 진행되었는지 확인 부탁드립니다.
답변 감사합니다.
네, 맞습니다. 새로운 Ubuntu 20.04.1 LTS에서 문제가 발생합니다.
수동 디스코러스 복구 과정을 시도하기 전에 사용자 이름 "pavel_BLANKEDOUT"으로 관리자를 생성했나요?
이것이 문제가 아닐 것으로 추측하지만, 중복 키 오류에 사용자 "pavel_BLANKEDOUT"이 언급되어 있으므로 모든 가능성을 고려해 질문합니다.
아니요, 생성하지 않았습니다.
백업 데이터베이스에 없는 사용자 관리자입니다.
안녕하세요 @Dev_Work
백업으로 사용하고 있는 원래 사이트가 완전히 다운된 건가요?
아니면, 기존 사이트의 컨테이너에 접속해서 discourse DB의 손상된 인덱스를 확인할 수 있나요?
또한, 기존에 깨져 있던 인스턴스는 PostgreSQL의 어떤 버전을 사용했나요? 10 버전인가요, 12 버전인가요?
이것은 제 문제와 비슷해 보이네요. Search results for 'could not create unique index category:6' - Discourse Meta
울고 싶어요 
ERROR: could not create unique index "index_user_emails_on_email"
DETAIL: Key (lower(email::text))=(andrii_test@local.com) is duplicated.
EXCEPTION: psql failed: DETAIL: Key (lower(email::text))=(andrii_test@local.com) is duplicated.
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:49:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
구 서버는 PostgreSQL 12를 사용했습니다
구 사이트와 서버는 정상 작동 중입니다
구 사이트의 컨테이너에 진입할 수 있습니다(손상된 인덱스를 어떻게 확인하나요?)