restoration of database post migration fails — appears to time out

[madhouse.updraftParticipant]

the database search-and-replace after restore takes quite some time and seems to fall down around the part when it’s working on wp-posts

right around there I get the ‘your session has expired, please log in again” popup. (also after logging back in, the page no longer appears to receive updates after a few moments)

I have tried logging back in right away; I have tried letting that sit and just refreshing the homepage; I have tried setting up crontab to poke wp-cron.php every 10 minutes; I have watched the log files with ~/www/wp-content/updraft {86}>$ ls -t log* -1 |head -n 2 |xargs tail -f; I have tried bumping php’s max_execution_time from 30 to 900;

Having used wp-migrate-db plugin in the past to do search-and-replace, I am somewhat surprised at how long yours takes — perhaps they are doing things a little differently?

my latest logfile seems to crap out around here:

==> log.e89375c40ec5.txt <==
0655.236 () Search and replacing table: wp_posts: rows: 20819
0978.786 () Searching and replacing reached row: 5000 <– this line never appears in the browser window after the session-timeout and log-back-in (which I did immediately as the dialog popup appeared this time)

I’ve seen it get as high as 15000 but no further, in my attempts to make this migrate work. All other aspects of the migration have functioned fine: I restored theme/plugin/other, and then separately restored uploads (234 zip files, there)

the gzipped database for this site is 27MB according to the shell
-rw-r–r– 1 hidden hidden 27M Jun 27 03:30 backup_2019-06-26-1136_Hidden_ed497321a353-db.gz

what other information can I provide to help debug this or what options do I have to work around this

[Bryle CroduaModerator]

Hi,

To help us work out the cause of your problem, can you please send us a copy of the migration log?
You can find this log in the ‘wp-content/updraft’ directory of your new site location.
You can send the log file as an attachment or copy the contents into an online tool (such as https://pastebin.com/ )

Best Wishes,
Bryle

[madhouse.updraftParticipant]

Could really use some assistance with this before the weekend arrives. there’s still work to be done on this site once we’ve put it up at the staging location for testing new features.

[madhouse.updraftParticipant]

here’s the logfile’s contents as requested

0000.560 (R) [notice] Looking for db archive: file name: backup_2019-06-26-1136_Town_Square_Delaware_ed497321a353-db.gz
0000.560 (R) [notice] Archive is expected to be size: 27104.6 KB: OK
0001.219 (R) [notice] Unpacking backup… (backup_2019-06-26-1136_Town_Square_Delaware_ed497321a353-db.gz, 26.5 Mb)
0001.269 (R) [notice] Restoring the database (on a large site this can take a long time – if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)…
0002.049 (R) [notice] Enabling Maintenance mode…
0002.050 (R) [notice] Backup created by: 2.16.15.24
0002.050 (R) [notice] Backup of: https://townsquaredelaware.com
0002.051 (R) [notice] Content URL: https://townsquaredelaware.com/wp-content
0002.051 (R) [notice] Uploads URL: https://townsquaredelaware.com/wp-content/uploads
0002.051 (R) [notice] Old table prefix: wp_
0002.051 (R) [notice] Site information: multisite = 0
0002.052 (R) [notice] New table prefix: wp_
0003.068 (R) [notice] Processing table (InnoDB): wp_options
0065.376 (R) [notice] Database queries processed: 50 in 64.11 seconds
0142.835 (R) [notice] Search and replacing table: wp_options: rows: 1586
0150.260 (R) [notice] Processing table (InnoDB): wp_users
0158.606 (R) [notice] Search and replacing table: wp_users: rows: 224
0158.894 (R) [notice] Processing table (InnoDB): wp_usermeta
0219.488 (R) [notice] Search and replacing table: wp_usermeta: rows: 6593
0219.608 (R) [notice] Searching and replacing reached row: 5000
0219.645 (R) [notice] Processing table (InnoDB): wp_commentmeta
0236.893 (R) [notice] Database queries processed: 100 in 235.62 seconds
0251.316 (R) [notice] Search and replacing table: wp_commentmeta: rows: 4980
0257.977 (R) [notice] Processing table (InnoDB): wp_comments
0284.164 (R) [notice] Search and replacing table: wp_comments: rows: 2300
0287.775 (R) [notice] Processing table (InnoDB): wp_links
0292.141 (R) [notice] Search and replacing table: wp_links: rows: 0
0292.142 (R) [notice] Processing table (InnoDB): wp_postmeta
0369.780 (R) [notice] Database queries processed: 150 in 368.51 seconds
0410.953 (R) [notice] Search and replacing table: wp_postmeta: rows: 310
0549.739 (R) [notice] Processing table (InnoDB): wp_posts
0588.048 (R) [notice] Database queries processed: 200 in 586.78 seconds
0654.427 (R) [notice] Database queries processed: 250 in 653.16 seconds
0655.236 (R) [notice] Search and replacing table: wp_posts: rows: 20819
0978.786 (R) [notice] Searching and replacing reached row: 5000

[madhouse.updraftParticipant]

Well, too late to hope for a response before the weekend; is there any way we could arrange for some more timely back-and-forth where even more days don’t pass in between responses? Our end is a bit time sensitive, and already delayed. It would be greatly appreciated.

[Bryle CroduaModerator]

Hi,

Apologies for the late reply.

It appears that the migration process is timed out or killed off. This is usually due to server resources reaching its limits.

Please ask your hosts/server admin to investigate their PHP error logs. These logs should contain more information on the exact issue that is causing the backup process to halt.

If you want us to restore/migrate the site for you, you can purchase one of our hands-on support package here – https://updraftplus.com/shop/get-support/

Regards,
Bryle

[madhouse.updraftParticipant]

There’s nothing in the error logs for php to suggest that. particularly after I upped the max execution time to 900 from 30, but not before either. Nothing in the MySQL logs either.

What other methods of workaround do I have for this? it’s 10:59am here in the states, so there’s plenty of daylight left for us to work on this : I notice that your timezone is significantly different from ours, inasmuch as the forum timestamps would indicate.

[madhouse.updraftParticipant]

this one-reply-per-day thing is getting wearisome. is there any way we could arrange to go back-and-forth via email rather than by forum? OR does anyone have alternative suggestions as to how we can get the DB restored so we can move forward with testing on the staging server so the client can show things to THEIR clients ?

For a paid support forum the turnaround time on replies is shocking.

posted at 3:43pm EST

[Bryle CroduaModerator]

Hi,

You can manually restore the database via phpMyAdmin. Then to change the old url with the new url, just follow this guide https://updraftplus.com/faqs/migrated-site-searchreplace-database-can-now/

You can also open a ticket using this form – https://updraftplus.com/paid-support-requests/

Regards,
Bryle

[madhouse.updraftParticipant]

Sure I could use PHPmyAdmin — I could also manually restore it with commandline mysql even more easily.

but this /faqs/migrated-site-searchreplace-database-can-now/ well. now this is some great advice..

(presuming one had successfully restored the DB without the search-and-replace bit):
1. change WP_SITEURL in wp-config.php to the old site’s address
2. log in (you forgot to mention the part where you go to your hosts file and temporarily add the new server’s IP address so it points at the old url)

(and I love this part):
3. *perform the database migration again*

___You mean the part that’s been failing on us?___ So you’re basically saying, “Use the plugin harder”?

*deep calming breath*

We had already gotten this to the point of ‘restore the plugins/themes’, ‘restore the other and uploads’ and LASTLY JUST restore the db, each separately in their own pass run, before we contacted you. The logfail above is from the part where we were JUST restoring the DB with the search-and-replace. That was the _complete_ logfile.

Why are we paying for the fancy schmancy version of the plugin again, remind us? I’m _certain_ the client is wondering at this point, given how long it’s taking us to get a workable support response.

How about this: do you have a “sql patch” file or script that we can use to manually apply the search-and-replace to the DB with after manually importing it to the DB via the commandline? Other suggestions? Today?

posted: 11:24 am EST

[madhouse.updraftParticipant]

support ticket submitted @ approximately 1:27pm EST

[madhouse.updraftParticipant]

SO yeah, we got a response from the support ticket, wherein I referenced this forum post to detail what we had tried so far.

Their response? (which came in at 1:34am our time, and was read and responded to by us 7 hours later at 8:43am our time)

>> “Restoration process can stall/halt depending upon the total backup size and available server configuration, PHP timeouts can stall/halt the restoration process.

>> If you are trying to restore all backup sets at once, instead I’ll suggest you to restore each backup set one by one i.e. First restore Plugins > Themes > Uploads > Others and at the end restore the database.

>> Let us know if above method helps to fix the issue.”

So, try the thing we described having already tried (right there in our previous response), and for which the attached log was attached, and for which we had already increased the PHP max execution time 3000%.

great. supremely unhelpful. So now we wait yet another full working day, sitting around twiddling our thumbs waiting for yet another probably-useless response that comes during anything other than normal working hours east coast time, and by which time we are able to respond, everyone over there’s already gone to bed. Fantastic.

posted 9:39am EST

[Bryle CroduaModerator]

This reply has been marked as moderator-only.

[Author]

Posts