Migration fails during restore


(Sam Stickland) #1

I’m trying to restore a backup I made earlier this evening and I’m getting the following error message:

[2015-07-13 21:15:05] CREATE INDEX
[2015-07-13 21:15:05] CREATE INDEX
[2015-07-13 21:15:05] Enabling readonly mode...
[2015-07-13 21:15:05] Pausing sidekiq...
[2015-07-13 21:15:05] Waiting for sidekiq to finish running jobs...
[2015-07-13 21:15:05] Switching schemas... try reloading the site in 5 minutes, if successful, then reboot and restore is complete.
[2015-07-13 21:15:05] Migrating the database...
[2015-07-13 21:15:05] EXCEPTION: 

No migration with version number 20150709021818


[2015-07-13 21:15:05] /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/migration.rb:952:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/migration.rb:814:in `up'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/migration.rb:798:in `migrate'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.10/lib/active_record/railties/databases.rake:34:in `block (2 levels) in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'

Very strange, as I haven’t upgraded or changed the discourse version since the install earlier on today.

Version: v1.4.0.beta4 +66

Any got any ideas?


Unable to restore backup - No migration with version number
(Sam Stickland) #2

I’ve checked and the migration it’s trying to find doesn’t exist:

root@ForumsLive-app:/var/www/discourse# ls -l db/migrate/2015070
20150702201926_add_topic_template_to_categories.rb
20150706215111_add_mobile_to_user_visits.rb
20150707163251_add_reports_index_to_user_visits.rb

It does exist in github though:


(Sam Stickland) #3

This ‘fixed’ it:

curl https://raw.githubusercontent.com/discourse/discourse/master/db/migrate/20150709021818_add_like_count_to_post_menu.rb > db/migrate/20150709021818_add_like_count_to_post_menu.rb

(Kane York) #4

This should be caused by trying to restore a backup made in a newer version of Discourse.

This should be fixed by rebuilding your container.


(Sam Stickland) #5

Thanks for the reply :smile:

I know that’s what should cause it, but in my case I was trying to restore a backup from a fresh installation made only hours earlier. There was no upgrade that took place as far as I know.


(Kane York) #6

That’ll do it - the new installation was created on a newer version that the installation you were restoring to. Just update the target and you’ll be fine.


(Sam Stickland) #7

No, I was actually trying to restore a backup I took of the fresh install.

I’m working on a script to import a mailing list archive, so I made a fresh install, configured it and backed it up. Every once in a while, whilst working on this script, I restore back to my configured version (to get back to an install without any imported posts).

There shouldn’t be any version mismatch.

The meta.json file in the backup says:

{"source":"discourse","version":20150709021818}

The installed version is: v1.4.0.beta4 +66

I’m not sure how to match up those two version formats.


(Kane York) #8

That’s how you match that one up.

The other one is the output of the git describe command, which I don’t have the time to explain right now :wink: It also functions as a red flag if anyone manually edited their Discourse files inside the container (it would say “v1.4.0.beta4 +66 dirty”), which is basically a crude warranty sticker.