On Discourse latest beta, docker install, multisite.
Trying to restore a backup with original database REDACTED to current database db8015. Uploads end up in default, both on filesystem and in database.
This happens both when the restore is triggered from the GUI, and when the restore is done on the command line using RAILS_DB=db8015 RAILS_ENV=production script/discourse restore.
Before that line, RailsMultisite::ConnectionManagement.current_db has the correct value (db8015), after that line, it is default.
Looks like this fix has broken production somehow @sam?
Logs:
[STARTED]
'DHSupport' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/db8015/2019-10-11-104940 exists...
Copying archive to tmp directory...
Unzipping archive, this may take a while...
No metadata file to extract.
Validating metadata...
Current version: 20191007140446
Restored version: 20190908234054
Extracting dump file...
Creating missing functions in the discourse_functions schema
Cannot restore into different schema, restoring in-place
Enabling readonly mode...
Pausing sidekiq...
[deleted a lot of irrelevant stuff]
Clear theme cache
Extracting uploads...
Remapping uploads...
Remapping 'uploads/REDACTED' to 'uploads/default'
Optimizing site icons...
Posts will be rebaked by a background job in sidekiq. You will see missing images until that has completed.
You can expedite the process by manually running "rake posts:rebake_uncooked_posts"
Executing the after_restore_hook...
Cleaning stuff up...
Dropping function from the discourse_functions schema
Removing tmp '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940' directory...
Unpausing sidekiq...
Marking restore as finished...
I spent some time on this bug, and I wanted to update you with my findings. Basically, I confirmed everything you already said, the restore process is like that:
A hacky solution would be to use here @current_db which still contains correct name instead of RailsMultisite::ConnectionManagement.current_db but this is not solving real issue why reconnect database is not working properly.
You are right. I removed Rake::Task["db:migrate"].invoke from restorer.rb and got correct database through the whole process.
You are one step ahead of me, my plan now is to go into migrate task and see which step is breaking process.
Thank you for pointing _dump, I will go directly there to see what is happening inside
Fixed was merged, thank you for finding that issue. That dump command was added because there was a problem with multisite migrations. I think that It shouldn’t matter which database we are using to dump structure because all multisites should have same structure.