Maybe I'm blind or running in a real weird setup (that's rather true, I'm trying to restore a rather damaged site), but why the heck does restore *destroy* the database after restoring it?
function drush_provision_mysql_post_provision_restore($url = NULL) {
[...]
// We have now completed successfully, remove the old database.
_provision_mysql_destroy_site_db(
drush_get_option('db_name', null, 'site'),
[...]
... *old* database? which old database are we talking about here?? Here, this yield the following tasty log:
Granting privileges to site_1521_1@localhost on site_1521_1 [3.02 [notice]
sec]
Created site_1521_1 database [3.111 sec] [success]
Granting privileges to site_1521_1@localhost on site_1521_1 [3.02 [notice]
sec]
Created site_1521_1 database [3.111 sec] [success]
...
Dropping database site_1521_1 [9.456 sec] [notice]
Revoking privileges of site_1521_1@localhost from site_1521_1 [9.508 [notice]
sec]
So in effect, restore does restore my site, but then kills it. I think we should just avoid deleting that "old" database if it's the same as the one being restored.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 592730_sane_restore.patch | 1.34 KB | anarcat |
Comments
Comment #1
anarcat commentedForgot the actual patch.
Comment #2
Anonymous (not verified) commentedI've been having trouble replicating this, though I want to stress it might not be a problem with the patch, but maybe my testing process is wrong.
Over IRC, the suggested method to reproduce was:
1) Backup the site
2) restore the site
3) rm -rf the site in sites/
4) drop the database
5) Try and restore with the 'provision restore' command.
If I do 3) , I can't restore at all, because the site is missing and drush sends the 'SITE NOT FOUND' error and complains it can't read sites/default/settings.php (which it's obviously resorted to looking for)
So I can't restore at all at this point. With an entirely missing site, this seems more like a job for Deploy.
If I restore a site normally, it creates a database with a revision increment ie site_67_0 and after importing from the dump found in the unpacked tarball, it destroys the *original* database but not the new one, as expected.
If I just do 4), drop the database but not delete the actual site data, a restore fails because it tries to do a backup first and fails, because it can't find the site_67_0 database to export.
Interesting other thing: I create a dummy empty site_67_0 database and do another restore from that original database, and as expected, it deletes the site_67_0 database and this time imports the database as site_67 (no increment) because that database got deleted earlier. This is fine as far as I'm concerned, but should we force an increment to make it obvious that it's a database that's been restored from an older one that is now gone? Maybe not, and I don't care, I'm just wondering what others opinions are. It's quite clean as far as I'm concerned to have a site_67 db again if that db no longer existed at all.
Regarding the way restore will fail if the current database has gone missing, I think perhaps Restore should not actually try and do a backup. But its clearly by design and maybe I'm not thinking of a use case for this. i.e perhaps Restore should only be used to revert an existing site to an older state, and not to be use to try and restore a missing or half-missing (ie database) site, and Deploy instead should be used in this case.
But sorry anarcat, I can't reproduce your case where the *new* database being restored, is immediately destroyed again. If i left out a step in my testing, please let me know.
Comment #3
anarcat commentedThis is a rather peculiar use case that doesn't warrant a critical status.
Comment #4
adrian commentedI ensured this won't happen in the latest code in master :
http://git.aegirproject.org/?p=provision.git;a=blob;f=db/restore.provisi...
I make a copy of the old credentials (in entirety) :
Then at the end of restore i delete the old database explicitly :