VacateLegacyPrefixBackups ジョブが停止

davidkingham · 2020 年 6 月 7 日午後 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 · 2020 年 6 月 7 日午後 3:46

本物の S3 を使用していますか、それともクローンを使用していますか？

davidkingham · 2020 年 6 月 7 日午後 4:31

私は DigitalOcean Spaces を使っていますが、それが「本物」と見なされるかどうかはわかりません。

Falco · 2020 年 6 月 7 日午後 6:40

それは、クローンが API 呼び出しをサポートしていない場合に発生する現象と非常に似ています。

不足している API のせいで Discourse がフォルダのクリーンアップを実行できないため、手動でフォルダのクリーンアップを行う必要があります。

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 · 2020 年 6 月 7 日午後 7:01

無知をお許しください。その意味が全くわかりません。DO は過去 1 年間問題なく動作していましたが、このエラーは先日最新バージョンにアップデートした後に初めて表示されました。

davidkingham · 2020 年 6 月 11 日午後 4:55

どなたかこれを明確にしてくれませんか？このジョブは4日後もまだ実行中です。

schleifer · 2020 年 6 月 12 日午前 3:10

そのジョブでバグに遭遇していますね、申し訳ありません。

最も簡単な解決策は以下の通りです：

https://community.naturephotographers.network/admin/backups に移動する
‘Size’ が 5GB 以上のエントリを削除する

あるいは、それらをバケット内の新しい場所（現在の backups/ ではなく、おそらく backups/default/）に手動で移動することもできます。

手動で移動すると、ジョブ内の 2 つ目のバグに遭遇し、ログに 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 というエラーが表示されます。

この 2 つ目のバグについては、修正をコミットしました。そのため、手動で移動した後、少し時間を置いて再度更新を行えば、「不正なリクエスト」というエラーメッセージは表示されなくなります。

davidkingham · 2020 年 6 月 12 日午前 3:29

ありがとう、アンドリュー。小さな問題が一つあるんです。私の最大のバックアップが460MBなんです…

sam · 2020 年 6 月 12 日午前 4:35

これは、S3 のクローン環境にいるために発生していると思われます。そのため、データの移動に使用する API が DigitalOcean によって実装されていないためです。

手動でデータを移動することはできますか？

最も簡単な方法は、すべてのバックアップをダウンロードし、古いバックアップをすべて削除することです。

davidkingham · 2020 年 6 月 13 日午後 5:29

はい、すべてのバックアップを削除し、ジョブを停止しようとしましたが、再起動してしまいます。リセットするために他に何か必要なことはありますか？

schleifer · 2020 年 6 月 17 日午前 10:51

ログに別のエラーはありませんか？

プロセスを再起動して、ジョブの状態を再評価できるようにしてみましょう。

cd /var/discourse
./launcher restart app

davidkingham · 2020 年 6 月 17 日午後 1:41

ログにエラーはもう表示されませんが、Sidekiq でジョブが継続して実行されています。サーバーの再起動やアプリの再起動を試みましたが、改善されませんでした。

schleifer · 2020 年 6 月 17 日午後 5:37

これを試して、エラーが発生するか確認してください:

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

バケットにバックアップが本当にない場合、最後の行は空のリストを出力するはずです:

=> []

davidkingham · 2020 年 6 月 18 日午後 7:37

アンダーソンさん、ありがとうございます。再度クリアしましたが、以下が表示されます：

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

トピック		返信	表示
Intended path to migrate S3 to local Self-hosting uploads , s3	5	850	2023 年 5 月 13 日
Sidekiq is being paused, how can I discover why? Support	18	3228	2018 年 9 月 20 日
Backups fail to upload to S3 several times- works eventually Support backups , s3	7	215	2025 年 5 月 27 日
Unable to backup or navigate to backups Bug s3	23	377	2024 年 11 月 18 日
Unknown items in Backup list Support	8	685	2019 年 1 月 18 日

VacateLegacyPrefixBackups ジョブが停止

関連トピック