New to the community? Start here

Shipper getting stuck at 80% repeatedly.

I am trying to migrate a site, shipper migration is cycling in a neverending loop and while checking the debug log, I am getting an error message repeatedly “PHP Warning: Error while sending QUERY packet. PID=6257 in /public_html/wp-includes/wp-db.php on line 2007”

Sat, 6 Apr 2019 16:39:36
More Shipper Pro discussions
Shipper Pro
  • Pawel Pela
    • Ex Staff

    Hello again Damjan!

    Please try with the attached beta release of Shipper. It’s still waiting to undergo testing before release, but from what we’ve already seen it works fine and fixes the exact issue you are having.

    You will need to install this beta on both the source and destination sites.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello!

    I wiped destination and started from scratch, just to be sure we have a green field destination setup on WPMU DEV Hosting.

    I uninstalled all WPMU DEV Default plugins except Dashboard of course. Than I installed suggested Shipper 1.0.2-beta.1.

    On source, I’ve uninstalled existing version of Shipper and reinstalled the mentioned one.

    I am sorry to say, but the problem is still the same… exactly the same symptoms. Neverending cycling until someone stops the migration process.

    Source side status shows 80%, because it is unaware of what is happening on the destination side, where the process repeats itself and clears Shipper log every time when it starts over again.

    PS: since I crated destination from scratch, there is no debug.log for destination at the moment, neither you have FTP access there, but I allow you accessing it, if you have access from the backend. Otherwise, I will grant you access of course. Source side .log file is attached here.

    As I already said, I am doing this because I believe in the product and I am willing to test it out as much as possible for all of us to get real world experience and the page is not not that important. Doing it manually is always the way out, but I’ll wait for it as least until/while we have something to troubleshoot here.

    Thank you for any kind of feedback!

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    It’s always great to hear from people who are so interested in our plugins and services! Thank you for the good words! :slight_smile:

    That situation requires a bit more checking. I understand you are exporting from source to destination, right?

    The Shipper logs don’t say anything except the process stopped at 80%. The migration progress on the destination site seems to reflect this – most of the content has been transferred, but not all.

    But the error message you posted initially (and one I found migrated to destination) tells me that there’s a different resource related issue on the source site – you are exceeding database access limits set by your hosting. It’s basically asking for too many database accesses during a short period of time.

    As previously, the solution here may be to ask the hosting to increase the limits for you.

    If that helps, I’ll add a task for our development team to include an improvement to check if this situation is happening and possibly slowing the migration down to avoid exceeding the limits.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hi Pawel!

    You know what is so cool about this. That I am my own hosting provider in this case :slight_smile: I have my own VM, which is really not that resourceful, but it should be good enough (2 vCPU, 3072 MB RAM). It is up to date VestaCP on Ubuntu 18.04 LTS.

    I’ve made a quick search on “vestacp exceeding database access limits” and found this:

    There is “soft” limit, real limit – only hardware.

    /usr/local/vesta/conf/mysql.conf

    MAX_DB=’500′

    Than I checked this setting on my server and it is actually set to 500 as a default value. I will go now and change it to 1000, test migration again and report back here…

    Thanks a lot!

    Damjan

  • damyang
    • Site Builder, Child of Zeus

    Oh wow! Finally! Great success!! :slight_smile:

    After I switched that MAX_DB to 1000, performance exploded. It was migrated in under 1h (before it was 3-4 hourse).

    I switched the way of migration process other way around, so I didn’t export it from Source, but rather import it on Destionation (that reminds me about the question, which is preferred or suggested way by WPMU DEV(?)).

    Than it was an issue with obsolete .htaccess file somewhere in /uploads of legacy Plugin Contact Form 7, which couldn’t be imported on destination and it screwed the finalization process, so it basically stuck near the end. Even though the log said that migration was completed, there was only 90% of web page migrated.

    So I deleted that .htaccess and its folder on Source, recreated web site on WPMU DEV Hosting, re-run the process, and… BINGO! Here I have another question… how to efficiently reset info about previous trials? Because I noticed that it kind of took all metadata from previous try, it wasn’t aware that I delete one file from Source. I’ve seen that cache and hash-id files in Shipper folder – should those be deleted?

    Thank you a lot for your help, analysis and a suggestion where to look for!

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    That’s so cool! Great job on your side! :slight_smile:

    Yup, we’re using nginx so the .htaccess are not necessary, although they shouldn’t cause issues.

    As for the direction – it’s either way. I was only asking to make sure I look at the proper logs and don’t miss anything important.

    Yes, you can delete all those files from Shipper.

    Kind regards,

    Pawel