So trying to migrate a site by restoring a backup from an existing deploy. I am getting the restore fail because of the schema mismatch (source is newer than target). Now reviewing the admin/plugins endpoint for both deploys they match for the ones listed, their status, and their version so scratc…

[圖片] Justin Rackliffe: 20231022224833 We happen to have a database with all migration ID’s for 400+ plugins so we can map them to a plugin easily. This one comes from discourse-automation.

[圖片] Justin Rackliffe: Both sites are at app 3.1.3 Could it be the old one was on beta or tests passed and not stable, so the latest stable is in fact, older? I’d check the commit numbers match (if possible). The backup is of the db, so I doubt plugin population matters, it will simply add …

I don’t believe so, but it’s a dev environment so anything is possible I guess. Is there anything you know of in the schema_migrations table (or the container cloned code) that I could manually check and correlate the schema version to whatever change? The rename of the file can get things uploade…

rails db:version from the command line in the discourse directory… but if you’ve not restored that might not help … or from psql: SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 1; You could then look that up on Github to cross-ref the commit … e.g. https://github.com/search?q=repo%…

Yeah I can see the max schema_migration (even just looking at a backup filename), but checked the table and its just the date value. No indications where it came from. example the “good” is 20230823100627 and the site is 20231022224833. I can’t even find files for “20231022” in the post_migrate f…

[圖片] Justin Rackliffe: but it’s a dev environment wait, you are trying to restore a dev instance to a Production database or vice versa? I’ve never attempted that, only ever Production to Production (which will have consistent database names and other configuration).

In this case its the Dev instance to a newly provisioned “Merge” instance which I will then use merger to import another Dev instance as testing a instance consolidation effort we have going on. The schema migration rev being in sync is a pre-req (not surprised). In this case the target env is on …

OK, your workflow is very … exotic! Ideally you shouldn’t need to keep any data in dev and should be able to simply drop the database and re-run migrations. To merge two diverging dev instances, you would normally merge code the branches, including the migrations, then create a new instance from s…

Heh yeah all the farm animals escaped the barn a while back so I am trying to get everyone back in the pen. Or at least figure out if its even feasible. And we found the missing piece looking at the instance file system Folks had been looking at automate, but on the other envs they had never acti…

BTW Github search is your friend here [image]

Yeah we finally figured it out too looking at the instance runtime itself, but far from the ideal. Lesson learned for an operational runbook if we need it. I just didn’t check the automation repo in the org since it looked to be disabled and no record of anyone using it. Bad assumption on my part…

追踪与解决一个模式漂移的原因

支持安装

merefield (Robert) 2024年一月8日 21:06 18

好的，所以您正在对生产数据库的合并进行原型设计，这很有趣。

但您想合并什么？

您知道将主题（及其用户！）在实例之间移动是官方支持的吗？：

話題		回覆	觀看
During Restore: "EXCEPTION: You're trying to restore a more recent version of the schema. You should migrate first!" Support	3	1069	2022年三月24日
Can't restore backup from business 7 to fresh install due to version error Support	2	728	2022年一月14日
Failed restore - You should migrate first? Self-hosting	7	563	2022年十月15日
Determining the version from the database Support	2	474	2020年九月21日
Relation "discourse_automation_automations" restoring from 3.3beta1 to 3.5beta7 Self-hosting hosting	6	180	2025年九月18日

追踪与解决一个模式漂移的原因

相關主題