Migration from 8.2 to 9.2.3 - Database failure

[meat1oaf]

Getting the following error using the 9.2.3 Migration manager on every domain that has a database.

Please note that the old server is Plesk 8.2 running on FC2 - with mysql v3. The new server is running Centos 5.4 - with mysql 5. Sales support said it should "not be a problem".

<?xml version="1.0"?>
<execution-result status="success"><object name="xxxxxx.com" type="domain"><message code="FailedDatabaseDeployment" severity="error"><context>virtual void plesk:atabaseDeployer::act(plesk::XmlNode) const</context><file>./databases.cpp</file><line>192</line><text>Failed deployment of database xxxxxx (domain xxxxxx.com)</text><message code="ExecCmd::ExFailed" severity="error"><text>Execution of /usr/bin/mysql --no-defaults -u admin -h localhost -P 3306 Xxxxxx failed with return code 1.
Stdin is
source /tmp/migration-unpack-aHURKC/backup_Xxxxxx_1_1001071422;
exit
Stderr is
ERROR 1064 (42000) at line 4 in file: '/tmp/migration-unpack-aHURKC/backup_Xxxxxx_1_1001071422': You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-------------------------------------------------------
DROP TABLE IF EXIS' at line 1
</text></message></message></object></execution-result>

 

[meat1oaf]

one more thing...

I noticed this in the error log:
/usr/bin/mysql --no-defaults -u admin -h localhost -P 3306 Xxxxxx
(where Xxxxxx is my database name)

I tried running the same command on my server's CLI, and got:
and got

ERROR 1045: Access denied for user: 'admin@localhost' (Using password: NO)

Wouldn't the password need to be stored somewhere, if not explicitly given on the command line? If so, where is it? Thanks!

 

[IgorG]

Admin's password stored in /etc/psa/.psa.shadow and in mysql database. Password should be the same in the both places.

 

[meat1oaf]

password stored in my .psa.shadow file is correct - and it is the same password as the admin password I log onto the Control panel with.I do not see where in the database the admin password is stored (unhashed) - but i assume it is the same or i wouldn't be able to log in?

 

[IgorG]

It is 'mysql' database and 'user' table:

mysql> select Password from user where User='admin';
+------------------+
| Password |
+------------------+
| 3d89770b0d299d60 |
+------------------+
1 row in set (0.00 sec)

 

[meat1oaf]

right... but this is encrypted. How can I tell if the password is correct? What encryption does Plesk 8.2 use? I could try to encrypt my password and see what result I get, and if it matches the entry in the database...

 

[meat1oaf]

ok - i see that you are referring to the mysql database and not the psa database.

Ok, I know that my password is correct there, because I can run

mysql -uadmin -pXXXXXXX

and it connects fine locally. My problem, it seems (according to the error, where the mysql connect call is issued) that the -P parameter is not passed through the script. Does it pull the password from /etc/psa/.psa_shadow?

Either way, the password in that file, and in the mysql database are both the same, and both correct.

 

[IgorG]

Do you have some /root/.my.cnf file with password defined there? or in /etc/my.cnf ?

 

[meat1oaf]

No password set in /etc/my.conf, and /root/.my.conf does not exist.

 

[IgorG]

Well. Could you please describe with more details what sort of problem with this password? What is wrong there?

 

[meat1oaf]

I am not sure what you mean about mor details.... I gave you the exact error that I am seeing.

When I run a migration on a domain with a database, it "Completes with Errors". When I look at the log, I get the error I mentioned in my first post. The domain is available on the new server, with no tables in its database.

I only mentioned that I ran the mysql command that the error log showed, and that would not let me log in - I assume b/c the -p attribute was not passed. I do not know - I only brought it up in case it helped you.


Now, one other thing I notice is that, apparently when I first installed Plesk, back in version 7, the mysql database was only version 3 - and apparently though my upgrades to 8.2, that version remained the same. Could this be a problem migrating from mysql3 to mysql 5?

thx

 

[Simon Breukhoven]

unfortunately i'm having the exact same problem,

i'm trying to migrate from plesk 8.2 running on FC3 with mysql 3.23.58-16.FC3.1 to plesk 9.2.3 running centos 5.4 with mysql 5.0.77-3.el5

The errors from the logs are also exactly the same

 

[meat1oaf]

FYI - I just downloaded 9.3 (which became available today) and just wanted to indicate for the recod that I am STILL having the problem listed above. No databases survive a migration....

 

[IgorG]

It is client's databases. Seems there is problem with access to these databases during migration procedure. As possible workaround you can backup database separately before migration, delete it and perform migration. After that restore database on new server. Of course it is bad method if you have a lot of databases with the same problem. It is required deep investigation directly on your server. Therefore I can suggest you contact support team regarding this complex problem.

 

[meat1oaf]

I am sorry - but I believe you are incorrect.

It is not a single database that I am having trouble with, but rather ALL of them.
I even created a new account with a single database with one table, with only a single field. That too did not migrate.

Somebody else here is having the same problem - so there is something we are missing.

The only thing I can think of is that I had changed the admin password a couple months ago. Any chance that would wreak some havoc with whatever script is used to perform the backup procedure? Are we sure that a bug does not exist here? I am tired of paying Parallels for the privilege of discovering their bugs.

 

[meat1oaf]

In hopes that you may actually re-open this discussion, please take into account the following test I performed.

I reinstalled a fresh server with Fedora Core 2 and Plesk Reloaded 7.5. I created one domain, with one database with one entry of same data.
I then upgraded to each subsequent version incrementally. (to reproduce the history of my production server)

When I got to version 8.2, I tried to migrate the domain to my new 9.3 server and I RECEIVED THE EXACT SAME ERROR!!!!!!!!

This is CLEARLY and UNEQUIVOCALLY a problem with migrating from the early Fedora Cores. (Most likely having to do with the fact that they only have mysql3). However, your site does not mention this, and states that I should be able to migrate from 8.2 to 9.3 without issue. This is clearly a bug, and should be address for no charge. I shouldn't have to call your support line to figure this one out.

PLEASE, PLEASE, PLEASE, set this up for yourself and try it out. You will get the same results I did.

-Jason

 

[IgorG]

I have submitted request to developers regarding this problem. I will update this thread with results of investigation as soon as I receive it.

 

[meat1oaf]

My clients are demanding some sort of ETA. I have purchased the upgrade to v9.3. I have proven beyond a shadow of a doubt that the problem is a Plesk problem. Could I please receive an update as to your progress? I need to tell my clients something.

 

[IgorG]

Developers are working on this problem. We never provide any ETA and I have not any ETA when it will be fixed. You can contact support team and escalate problem there if problem should be fixed urgently.

 

[IgorG]

I have received following information from developers:

Such error - inability of mysql to process multidash comment - it actual for newly mysql versions only.
Bug not reproduced at mysql-5.0.45-7.el5 (Centos-5.3)
Bug reproduced at mysql from updates for Centos-5.3 and 5.4
As possible workaround customer can try to migrate to another OS if he has it.