1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Resolved [Migration] Onyx to Onyx Migration Stuck at "Create Hosting Plans"

Discussion in 'Plesk Onyx for Linux' started by Justin, May 8, 2017.

  1. Justin

    Justin New Pleskian

    5
    20%
    Joined:
    May 7, 2017
    Messages:
    10
    Likes Received:
    1
    Location:
    USA
    Hi there,

    I have been trying to migrate it over to the new server using the Plesk migrator. So far I am out of ideas as to why it keep getting stuck.

    Both servers run Plesk Onyx 17.5.3 update #5 with a 1Gbps connection speed.

    I'm trying to migrate 6 accounts, 7 service plans and 13 domains total up 7.22GB in size.

    I started the migration on Saturday. Today is day 3, the migration is stuck at 30%. 4 domains has been migrated with
    some errors.

    So I stopped the migration, and attempted the following:

    Code:
     
    1. ps ax | grep -i  plesk-migrator and killed the process
    2. ps ax| grep -i  deployer and killed the process
    3. deleted tasks.db and folders inside rsessions
    4. deleted all files in var/lib/psa/dumps/
    4.  rebooted server
    5. restarted migration
    
    Now the migration is stuck at "creating hosting plans" for close to 3 hours. Usually, the plesk migrator takes about 40 minutes to migrate all 13 domains and 7.22GB worth of files. I checked the log file, everything seems to be running fine, but it is running extremely slow. Last logged at 6:56PM CST. Now it is 8:26PM.

    What am I missing here?

    I can provide log files through messages.

    Any help would be greatly appreciated.

    Thank you!
     
  2. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    37
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,986
    Likes Received:
    404
    Location:
    Berlin, Germany
    It seems that the database admin access permission issue has not been solved prior to the new migration attempt. Make sure that admin@localhost can connect to the Plesk database with the password from /etc/psa/.psa.shadow on the source server. There may be further errors, maybe you can try to look into migration logs to find more details. See Plesk Migration Manager logs structure and PMM logs collector. for their location.
     
  3. Kingsley

    Kingsley Regular Pleskian

    21
    73%
    Joined:
    Dec 13, 2014
    Messages:
    473
    Likes Received:
    18
    Location:
    Nigeria
    Hello;

    Where you able to resolve this

    Code:
    Failed to copy content of database 'database'
    Migration tools tried to perform operation in 3 attempts: Command execution failed on the source server 'source' (100.100.100.3) with non-zero exit code.
    command: MYSQL_PWD="$(cat)" mysqldump --no-defaults -h localhost -P 3306 -uadmin --quick --quote-names --add-drop-table --default-character-set=utf8 --set-charset --routines d_bond > /root/plesk_migrator/plesk_migrator-d74obde4ga0aa7yv5ub58fc5edprs0ux/db-dumps/d_bond.sql
    exit code: 2
    stdout:
    stderr: mysqldump: Got error: 1045: "Access denied for user 'admin'@'localhost' (using password: YES)" when trying to connect
     
  4. trialotto

    trialotto Golden Pleskian Plesk Guru

    37
     
    Joined:
    Sep 28, 2009
    Messages:
    1,445
    Likes Received:
    206
    @Justin,

    You should check your firewall configuration.

    It is very likely that you have restricted access to MySQL server.

    I am pretty sure that you do not have to check the SSH firewall settings (otherwise you would not be able to start Plesk Migrator), but make sure they allow connections on both the source and the target server.

    The same should be done for the MySQL server connections: allow traffic between the source and target server.

    The most common method is to change the firewall ruleset for MySQL (and SSH).

    The most easy and secure method is to add a custom rule, that essentially results in "allow from [trusted IPs] on all ports": make sure this custom rule is the first one!

    With the latter method, one does not have to alter the MySQL (and SSH) rules AND the custom rule can be easily altered from time to time.

    Hope the above helps......

    Regards......
     
Loading...