VacateLegacyPrefixBackups 작업이 중단되었습니다

davidkingham · 6월 7, 2020, 2:56오후

업데이트 이후 이 작업이 거의 2일째 실행되고 있습니다. 이런 경우가 정상인가요? Sidekiq에서 그냥 중지해야 하는지, 아니면 더 나은 접근 방법이 있을까요? 감사합니다!

hostname	community-app
process_id	732
application_version	293467a37ae33c5fd8fd40bbfc05bffa578b90ed
current_db	default
current_hostname	community.naturephotographers.network
job	Jobs::VacateLegacyPrefixBackups
problem_db	default
time	8:28 am
	
opts	
current_site_id	default



aws-sdk-core-3.96.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/request.rb:70:in `send_request'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:59:in `block in vacate_legacy_prefix'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `each'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `vacate_legacy_prefix'
/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.2.2/lib/rails_multisite/connection_management.rb:68:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.7/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.7/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.7/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.7/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.7/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.7/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.7/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.7/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.7/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.7/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.7/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.7/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.7/lib/sidekiq/util.rb:24:in `block in safe_thread'


aws-sdk-core-3.96.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'
aws-sdk-core-3.96.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'
aws-sdk-core-3.96.1/lib/seahorse/client/request.rb:70:in `send_request'
aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:59:in `block in vacate_legacy_prefix'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `each'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:57:in `vacate_legacy_prefix'
/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'
/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.2.2/lib/rails_multisite/connection_management.rb:68:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.7/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.7/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.7/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.7/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.7/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.7/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.7/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.7/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.7/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.7/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.7/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.7/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.7/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.7/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.7/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.7/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.7/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.7/lib/sidekiq/util.rb:24:in `block in safe_thread'

Falco · 6월 7, 2020, 3:46오후

실제 S3를 사용 중이시나요, 아니면 클론을 사용 중이시나요?

davidkingham · 6월 7, 2020, 4:31오후

저는 DigitalOcean Spaces를 사용 중인데, 이것이 '진짜’로 간주되는지 잘 모르겠습니다.

Falco · 6월 7, 2020, 6:40오후

클론이 API 호출을 지원하지 않을 때 발생하는 상황과 매우 유사해 보입니다.

API가 누락되어 디스코스가 자동으로 정리할 수 없으므로, 디스코스가 이를 시도하지 않도록 폴더 정리를 수동으로 수행해야 합니다.

github.com/discourse/discourse

lib/backup_restore/s3_backup_store.rb

293467a37


      
          def vacate_legacy_prefix
            legacy_s3_helper = S3Helper.new(s3_bucket_name_with_legacy_prefix, '', @s3_options.clone)
            legacy_keys = legacy_s3_helper.list.map { |o| o.key }
            legacy_keys.each do |legacy_key|
              bucket, prefix = s3_bucket_name_with_prefix.split('/', 2)
              @s3_helper.s3_client.copy_object({
                copy_source: File.join(bucket, legacy_key),
                bucket: bucket,
                key: File.join(prefix, legacy_key.split('/').last)
              })
              legacy_s3_helper.delete_object(legacy_key)
            end
          end

davidkingham · 6월 7, 2020, 7:01오후

모르는 것을 용서해 주시겠지만, 그게 무슨 뜻인지 전혀 모르겠습니다. DO는 지난 1년간 잘 작동해 왔는데, 며칠 전 최신 버전으로 업데이트한 후에야 이런 문제가 발생했습니다.

davidkingham · 6월 11, 2020, 4:55오후

이 부분을 명확히 설명해 주실 수 있는 분 계신가요? 4일이 지났는데도 작업이 아직 실행 중입니다.

schleifer · 6월 12, 2020, 3:10오전

해당 작업에서 버그가 발생하고 있는 것 같습니다. 죄송합니다.

가장 간단한 해결 방법은 다음과 같습니다:

https://community.naturephotographers.network/admin/backups 경로로 이동합니다.
'Size’가 5GB 이상인 항목을 삭제합니다.

대신, 버킷에서 해당 항목을 수동으로 새 위치로 이동할 수도 있습니다. 현재 backups/ 대신 backups/default/로 이동하는 것이 좋습니다.

수동으로 이동하면 작업의 두 번째 버그에 부딪히게 되며, 로그에 This copy request is illegal because it is trying to copy an object to itself without changing the object's metadata, storage class, website redirect location or encryption attributes라는 오류가 표시됩니다.

해당 두 번째 버그에 대한 수정 사항을 커밋했습니다. 따라서 수동으로 이동한 후 잠시 후 업데이트를 다시 실행하면 “illegal request” 오류 메시지가 더 이상 발생하지 않습니다.

davidkingham · 6월 12, 2020, 3:29오전

앤드루, 감사합니다. 다만 작은 문제가 하나 있어요. 제 가장 큰 백업 파일이 460MB거든요…

sam · 6월 12, 2020, 4:35오전

s3 클론을 사용 중이므로, 파일을 이동하는 데 사용되는 API가 Digital Ocean에서 구현되어 있지 않은 것 같습니다.

수동으로 파일을 정리해 볼 수 있을까요?

가장 간단한 방법은 모든 백업을 다운로드한 후 기존 백업을 모두 삭제하는 것입니다.

davidkingham · 6월 13, 2020, 5:29오후

음, 백업 파일을 전부 삭제하고 작업을 중지하려고 해봤는데 계속 다시 시작돼요. 초기화를 위해 추가로 해야 할 일이 있을까요?

schleifer · 6월 17, 2020, 10:51오전

로그에 다른 오류가 있나요?

프로세스를 재시작하여 작업 상태를 다시 평가하도록 하는 것이 좋습니다.

cd /var/discourse
./launcher restart app

davidkingham · 6월 17, 2020, 1:41오후

로그에 더 이상 오류가 표시되지 않으며, 현재 작업이 sidekiq에서 계속 실행되고 있을 뿐입니다. 서버를 재부팅하고 앱을 재시작해 보았지만 효과가 없었습니다.

schleifer · 6월 17, 2020, 5:37오후

이 내용을 실행해 보고 오류가 발생하는지 확인해 보세요:

cd /var/discourse
./launcher enter app
rails console
BackupRestore::S3BackupStore.create.vacate_legacy_prefix

버킷에 실제로 백업이 없다면, 마지막 줄은 빈 목록을 출력해야 합니다:

=> []

davidkingham · 6월 18, 2020, 7:37오후

Andrew, 감사합니다. 방금 다시 정리했는데 이 결과가 나옵니다:

[1] pry(main)> BackupRestore::S3BackupStore.create.vacate_legacy_prefix
=> []
[2] pry(main)>

글		댓글	조회수
Intended path to migrate S3 to local Self-hosting uploads , s3	5	981	5월 13, 2023
Sidekiq is being paused, how can I discover why? Product Support	17	3485	9월 19, 2018
Backups fail to upload to S3 several times- works eventually Product Support backups , s3	6	324	5월 27, 2025
Unable to backup or navigate to backups Bug s3	22	811	11월 16, 2024
Unknown items in Backup list Product Support	7	756	12월 19, 2018

VacateLegacyPrefixBackups 작업이 중단되었습니다

Related topics