正在尝试通过恢复现有部署的备份来迁移站点。我收到恢复失败的错误，因为架构不匹配（源比目标新）。
现在正在查看两个部署的 admin/plugins 端点，它们匹配已列出的插件、其状态和版本，所以我有点困惑。我还尝试将所有主题和组件都放回去，以防万一，但没有任何改变。两个站点都已更新到应用程序 3.1.3，因此在这种情况下，这似乎不是根本原因。
猜测是在站点上安装了一个插件，然后实例被重新部署，并且数据库被保留，但没有安装此插件，但这只是一个猜测。是否有确定性的方法可以根据实例或数据库来确定是什么导致了架构漂移？是否有办法“降级”或唯一的方法是使目标站点匹配或超集？
会不会是旧版本处于测试版或测试通过但未稳定，所以最新的稳定版实际上更旧？
我会检查提交编号是否匹配（如果可能）。
备份是数据库的，所以我怀疑插件填充是否重要，它只会添加插件数据，但实际上并不会使用它……
我不这么认为，但这是一个开发环境，所以一切皆有可能。
您知道 schema_migrations 表（或克隆的代码容器）中有任何我可以手动检查并关联模式版本与任何更改的内容吗？
重命名文件可以通过 UI 上传文件，但我使用的是 merger，它会根据 max(schema_migrations) 进行阻止，我真的想避免过多地修改代码。
其中一些内容是在可能出现迁移版本不匹配的任何操作任务之前进行的。更好地了解如何将迁移版本追溯到更改，以便当这种情况再次发生时，我希望能找到一个协调的 runbook。
rails db:version
在 discourse 目录中从命令行运行…但如果您尚未恢复，这可能没有帮助…
或者从 psql：
SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 1;
然后您可以在 Github 上查找该版本以交叉引用提交…
例如 https://github.com/search?q=repo%3Adiscourse%2Fdiscourse+20231222030024&type=code
浏览迁移文件，然后记下添加它的提交以确认日期等。
注意：这不一定与代码提交相同！可能更早 
（您可以通过 git log -1 获取）
是的，我可以看到最大的 schema_migration（即使只是查看备份文件名），但检查了表，它只是日期值。没有迹象表明它来自哪里。
例如，“好的”是 20230823100627，而网站是 20231022224833。我甚至在 post_migrate 文件夹（或仓库的其他地方）找不到“20231022”的文件。
我确定它就在我眼前。是的，我正在挖掘过去的更改和电子邮件，试图弄清楚是否能匹配 8 月份之后某个操作，当时可能有一个错误的版本潜入了。
等等，您是想将开发环境恢复到生产数据库，还是将生产环境恢复到开发数据库？
我从未尝试过，只做过生产到生产（这将具有一致的数据库名称和其他配置）。
在这种情况下，它将从 Dev 实例迁移到一个新配置的“Merge”实例，然后我将使用 merger 将另一个 Dev 实例导入，作为我们正在进行的实例合并工作的测试。模式迁移版本同步是先决条件（不出所料）。在这种情况下，目标环境是 1022，源是 0823。在我所有的 3.1.3 版本中，我们都是 0823，所以 1022 来自哪里一直是个难题，而这正是我试图回溯的，但我找不到任何线索。
好的，您的工作流程非常……奇特！
理想情况下，您不应该在开发环境中保留任何数据，而应该能够直接删除数据库并重新运行迁移。
要合并两个分叉的开发实例，您通常会合并代码分支（包括迁移），然后从头开始创建一个新实例？
这在一定程度上解释了为什么有一个不错的 rake 任务可以预先填充一些固定装置，以便有所可用：rake dev:populate
我们有一个包含400多个插件的所有迁移ID的数据库，因此我们可以轻松地将它们映射到插件。这个来自 discourse-automation。
嗯，是的，农场里的所有牲畜都从谷仓里跑出来了，所以我正试图把它们都弄回围栏里。或者至少弄清楚是否可行。
而且我们找到了缺失的部分，查看了实例文件系统。
大家一直在关注自动化，但在其他环境中，他们从未启用过它，所以它在插件列表中是可用的，并且没有进行模式更改。所以远非理想，但这个工作的提示是检查所有已安装插件的存储库，即使它们被禁用，因为它们可能曾经被启用过。
我们正在进行重新部署，移除其中一些研发插件，同时密切关注插件/数据库条目，并在那里进行更好的记录。
我们最终也弄清楚了，看了实例运行时本身，但远非理想。吸取教训，如果需要，我们会制定操作手册。我只是没有检查组织中的自动化存储库，因为它看起来被禁用了，而且没有人使用的记录。这是我的错误假设。
@RGJ 那个数据库有可能在任何地方公开访问吗？使用实例文件系统“可行”，但比我希望的要混乱。
你的意思是人们没有推送他们的提交吗？
你想保存什么？
是的，我是在 discourse 仓库本身中搜索，而不是像之前那样搜索整个世界，因为我不确定它是否会显示出来。不带范围的搜索成本太高，但我没有扩大到组织层面，看看是否有 Discourse 官方的努力。
我们有 3 到 4 个 Discourse 实例，是独立团队启动的，用于解决共同的业务问题，我们正在尝试将所有人整合到一个实例中，同时又不丢失他们之前的工作。
我不相信在开发环境中保留数据是一种好的做法。
如果数据很重要，那么工作应该在更受控的生产环境下进行。
我不知道您想做什么的全部细节，但我的看法是，解决方案几乎肯定应该是插件，可以部署在任何地方，甚至不必完全依赖特定版本的 Discourse，也不必关心特定数据是否在播种其自身的固定装置之外预先填充。
好的 
在这种情况下，我们正在使用几个开发实例来对生产实例进行这些合并操作的可行性研究。如果我们能让运行手册变得完善，那么所有数据和实例都将达到生产级别，但到目前为止一直由独立团队维护。因此，了解成功合并的障碍是什么，正是我现在正在努力解决的问题。模式版本显然是一个关键问题，应用程序和插件都会影响“可合并性”。幸运的是，生产实例已经显示出 0823，所以这个特定的问题不会在生产运行中发生，但了解如何分析模式漂移是必要的，并且将极大地帮助我们的操作文档。
好的，所以您正在对生产数据库的合并进行原型设计，这很有趣。
但您想合并什么？
您知道将主题（及其用户！）在实例之间移动是官方支持的吗？：
是的，有数千个现有主题和相关内容，所以一次性的内容有点混乱
Merge two Discourse sites into one 使用的是不同的脚本，但基本思想相同。
发现了模式的另一个细微差别。所以我们从部署中删除了自动化插件并重新部署。然后我注意到 schema_migration 似乎回滚到了 0823 作为最新的。所以我想我可以在不将自动化插件安装到我正在合并的实例中就可以进行。嗯，当我再次运行导入时，我得到了一个 PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist 错误，所以即使迁移版本回滚了，但与它相关的模式更改似乎仍然存在于实际数据库中。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
