Issue [12.5.30] Plesk Panel migrator incorrectly migrates the databases from localhost to remote

[burnley]

Plesk 12.5.30 Linux on both src and target servers. Per client migration. On both src and target servers there are 2 database servers configured:
1. localhost:3306, default
2. remote_db:3306, on a Percona XtraDB 5.7.18 cluster.
Both src and target servers have admin access to remote_db. What I see during the migration is that the databases that are running on the localhost instance on the source server end up being deployed on the target server in the cluster.

Example:
src_server IP: 1.2.3.4
target_server IP: 5.6.7.8
remote_db has an entry in /etc/hosts, so that both src and target can connect to it by hostname.
Here's what the migrator outputs during migrating the clients (obfuscated):
[...]
[2017-06-27 15:52:22][INFO] [domain.name] Copy database 'wordpress_0' content from MySQL database server 1.2.3.4:3306 to MySQL database server remote_db:3306
[...]
Ooops! I didn't want that, nor did I expect it. It should have gone like this:
[2017-06-27 15:52:22][INFO] [domain.name] Copy database 'wordpress_0' content from MySQL database server 1.2.3.4:3306 to MySQL database server 5.6.7.8:3306

In other words:
src_server:3306 -> target_server:3306
remote_db:3306 -> remote_db:3306 - this operation shouldn't be needed, any application using remote_db:3306 should continue using it.

Bug?

 

[burnley]

The migrator seems to be doing the right thing with the databases that are already in the cluster on the source server:
[...]
debug.log:+|2017-06-27_16:23:10,132|D|ST2|core.migrator|domain1.name||Database 'asddsa_joomla_5' from mysql server at remote_db:3306 remains on the same server, content will not be copied
debug.log:+|2017-06-27_16:23:10,133|D|ST2|core.migrator|domain2.name||Database 'wsefgtre_db' from mysql server at remote_db:3306 remains on the same server, content will not be copied
[...]
Is there any db related configuration I should use to prevent the local databases to be migrated into the cluster on the target server?

 

[Alina Dmi]

Hello, burney!
I can advise you to migrate subscriptions by db server(migrate subscriptions with databases on local server in one part/parts and on remote in other), because migrator could migrate only to one database server per bundle. Also, pay attention on service plan on target server (if problem subscriptions assigned to any plan) - what db server is set in service plan options?

 

[burnley]

Alina, thanks for your reply. The migration we're performing is an actual server migration, but it's approached as a per-client migration. It's part of a larger effort to upgrade the operating system and the Plesk Panel should be a drop-in replacement. The simplified process, per server, is:
- Install the new server, install & configure Plesk. The new server - aka "target" - IP addresses are assigned from a private block and the mapping to the live server - aka "source" - IP addresses is configured accordingly.
- Follow the guidelines from Migrating via the Command Line
- After the successful accounts transfer, sanity checks and so on, the source server is shut down and the target is reconfigured to use the source IP addresses using Plesk reconfigurator and the reversed IP mapping used for migration.
- Final checks etc...
Using this approach, all the clients are being migrated in the same batch and the appropriate server downtime is scheduled.
Your suggestion to look at the service plans gave me a very good hint, the service plans on the source server, transferred on the target as part of migration, have the remote_db MySQL instance set as default. Will look into this and report back after more testing. Cheers.

 

[burnley]

After a bit of cleanup and reconfiguration:
- All the hosting service plans are using localhost:3306 as the default database server
- In Tools & Settings - Database Servers, localhost instance is set as default for MySQL
Then I tested the changes on a limited batch of clients with both local and remote databases configured on the source server. After the migration finished, on the target server all the databases were created on the localhost instance, which is not what we want and this is an issue for the current migration project. What we want is, after the clients are migrated, their database configuration to remain unchanged:
- If the database was local on the source server, if should be created and set up as local on the target server
- If the database was remote on the remote_db server, it should not be created again. Instead, Plesk should set it up in a similar fashion on the target server when associating it with the website.
How can this be achieved?

 

[Alina Dmi]

Then I tested the changes on a limited batch of clients with both local and remote databases configured on the source server. After the migration finished, on the target server all the databases were created on the localhost instance, which is not what we want and this is an issue for the current migration project.

The reason is:

because migrator could migrate only to one database server per bundle

To achieve this:

- If the database was local on the source server, if should be created and set up as local on the target server
- If the database was remote on the remote_db server, it should not be created again. Instead, Plesk should set it up in a similar fashion on the target server when associating it with the website.

do the following:
1. Get subscriptions list of client that you want to migrate
2. Select subscriptions with databases only on localhost and migrate it
3. Select subscriptions with databases only on remote db server and migrate it

If some subscriptions has databases on different servers, there is no way to map them as on source server, all databases will be migrated into one of the db servers according to settings on destination server.

 

[burnley]

Thanks for the explanation. Unfortunately splitting the clients in batches based on the mysql server used isn't an option in the current scenario, when we need to migrate them all at once on a new server. I think Plesk migrator should implement the remote database management as a feature in a future release to work the way we expect it:
- src server, localhost database -> migrate to target server, localhost database
- src server, remote_dbserver1/remotedb1 -> configure site1 to use remote_dbserver1/remotedb1 on target
[...]
- src server, remote_dbserverN/remotedbN -> configure siteN to use remote_dbserverN/remotedbN on target

 

[Alina Dmi]

Hello, burnley! Thank you very much for your feedback!
This feature(db mapping) is in long-term development plans and could be released in one of the next versions.