是的，但你在第 2 点中覆盖了它，因此这样一来，你又回到了将文件存入 S3 的做法。
2 个赞
app.yml 文件中的设置仅在重建容器时使用，并用于填充正在构建的容器中的 config/discourse.conf 文件。
1 个赞
啊！所以如果我的 conf/discourse.conf 文件中有任何 s3_ 变量，Discourse 就会认为我已启用了 S3 上传？好的……明白了……我会移除它再试一次。
可能只有一个因素是关键的……我现在不在电脑前，无法检查所有可能导致该检查触发的原因，但如果该检查被触发，我预计你的网站会将所有新上传的文件上传到 S3。
1 个赞
太棒了，真的太棒了，一切顺利！太感谢了！非常感谢你付出的所有努力，也谢谢你耐心地解释我需要做什么。能顺利推进这件事真是太好了。
所以，我有几个小问题，想让我更好地理解当前的情况……
我一直是以每次 100 条的批次运行。在前几个周期中，工具似乎在迁移帖子（？），但现在它只是在复制图片。我有成千上万条帖子，而每条帖子通常只附带一张图片……所以我不明白它怎么会“没有”帖子可以迁移了？“迁移帖子”具体是什么意思？这是第一个问题：到底发生了什么？
第二个问题更简单。现在运行工具时它只复制图片，但我注意到 2X 的图片被复制到了本地的 3X 目录中：
Downloaded 27/100: //my-forum-storage.s3.dualstack.us-east-1.amazonaws.com/original/2X/1/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg to /uploads/default/original/3X/1/4/14c56ef9f1dddb7b7a6f14e920234e0f714ea699.jpeg
注意 URL 从 2X/1/xyz.jpeg 变成了 3X/1/4/xyz.jpeg（多了一个文件夹路径）
这样没问题吧？
最后，我一直在抽样检查图片，看起来都没问题。但由于我完全不知道某张图片关联的是哪条帖子，我无法在论坛上实时检查，也就无法 100% 确定用户看到的是正确的内容。如何将 jpeg 图片文件名映射到具体的论坛帖子呢？
1 个赞
你当时具体输入了哪些命令？你需要扩大限制以覆盖所有帖子。
所以，在我确定要进入下一阶段后，最终指定了一个较大的限制，类似这样：
bin/rake uploads:batch_migrate_from_s3[100,100000]
它会迁移在帖子中发现的第一个上传项；post.raw 对上传的引用与数据库中的上传对象之间不存在参照完整性。它会查找包含任何普通 URL 或代表远程内容的 upload:// 伪协议 URL 引用的帖子，这些帖子在迁移后至少需要重新处理，如果不是直接保存修改以指向 S3 的基础 URL。当它在帖子中找不到任何需要迁移的内容时，就会继续处理下一个项目。
路径变更并非由迁移脚本直接驱动，而是 Discourse 存放文件的位置发生了变化。增加一级目录有助于在文件数量庞大时提升性能，许多其他系统也使用两层甚至偶尔三层目录来分散文件。
你可能会遇到和我一样的问题：迁移其他上传项导致 Discourse 丢失了用户的头像。我直到为时已晚、无法从备份恢复时才注意到这一点，所以我只能给受影响的发消息并道歉，请他们自行修复头像。我至今仍然不清楚那里究竟出了什么问题。
好的，明白了。我在进度输出中看到了以下内容：
所有帖子上传已迁移。正在迁移个人资料上传...
所有个人资料上传已迁移。正在迁移其他非帖子上传...
“非帖子上传”指的是什么？看起来所有的工作都卡在这里——迁移帖子和资料上传似乎都没有实际进展。
感谢您对原始上传路径的确认！
我不确定是否发生了这种情况，但这没关系——我的网站使用 SSO，每次用户登录（或在主站更改头像）时，我都会传递头像 URL。
说实话，我不知道其余的都是什么。我更希望，如果涉及引用完整性，会有外键约束；否则，系统只需查找上传内容并使用其所在位置即可。我确实遇到过外键约束，它表明当两个上传内容附加到用户资料时，需要执行一些特殊操作。
1 个赞
嗯，看起来确实是在运行……不过今天早上我遇到了一个严重问题……磁盘使用量突然飙升了 25%，导致磁盘被占满，论坛彻底崩溃。
目前，当我运行 rake 任务时，它似乎正在批量处理过程中实时下载/上传图片。我输入 rake 命令后，它会精确处理 300 张图片（我按每批 300 张的方式分批运行），然后任务结束。
所以关键问题是：能否将这些从 S3 下载到本地磁盘的操作放入队列？是否可能因此积累了某种批处理任务，然后在凌晨 5 点集中执行，导致论坛崩溃？
在迁移帖子、每批个人资料上传以及其他上传时，我让系统等待队列清空后再执行下一步。这样，所有图片在迁移完成后应立即开始处理。（标准版本则是将所有任务堆积起来，导致队列堵塞，直到处理完毕；对我而言，这意味着在重新处理图片的 10 到 12 天内，论坛通知将完全无法发送。）
我想不出是什么导致了这种峰值，除非是遇到了一批非常大的上传文件？
1 个赞
是啊，这对我来说也是个谜。我的意思是，我甚至不常运行批处理任务——每次都是手动输入命令并观察其执行。我没有更多帖子或资料需要迁移；剩余的都是“其他上传”。当我运行批处理时，它似乎是从 S3 下载并实时重新上传到 Digital Ocean。（而且我在 Sidekiq 中没看到任何表明有任务被排队的迹象。）
我正在尝试查找其他日志，看看是否能显示凌晨 5:35 发生了什么事。
请阅读整个主题。
但其中大部分内容让我感到困惑。尽管我完全熟悉 Docker/容器命令和基础的 Rails 命令。
我遇到了类似的问题（我的许多帖子缺少图片，或者有些图片直到点击后才显示）。
我在一年中的不同时段使用了两个不同的 S3 存储桶。我有大约 1000 篇帖子，以及大致相同数量的图片。
现在，我已将所有图片从 S3 存储桶复制到了我的本地服务器。请问有人能告诉我如何重新映射 Discourse 的 URL，以便这些图片能正确关联到相应的帖子吗？