update problem

[nokia80]

hello
I have two times ISPConfig server ns1 and ns2.
The ns2 is the master if I update, so good.
ns1 but I get this error,

Possible problem with dumping the database. We will stop here. Please check the file existing_db.sql

I like to hear the solution


best regards michael

[Hans]

Originally Posted by nokia80

Possible problem with dumping the database. We will stop here. Please check the file existing_db.sql

Hi Michael, i have 6 ISPConfig3 servers. 1 master and 5 slaves. I started by upgrading the first slave server and i got exactly the same error as you do. I did not start upgrading the master server yet, as i understood that upgrading the slaves first is more safe in case the MySQL database structure has been changed.

See my post here.

There must be something wrong, because i followed the instructions very carefuly. I hope there will be a solution soon.

[neuromystical]

I am having same problem Hans, any update on this? I am surprised there has not been any responses yet.

[Hans]

Originally Posted by neuromystical

I am having same problem Hans, any update on this? I am surprised there has not been any responses yet.

Please be patient, as the developers need to find a solution. I don't know where you're from, but ISPConfig has it's origin in Germany, during your post it was there in the middle of the night.

The error occurred instantly after giving the MySQL password. After that the upgrade was aborted. Nothing happened to your existing MySQL database.
So don't worry about that. There will be a solution soon!

[till]

The error message means that the installer was not able to dump the ispconfig database. So it stopped to make sure that you dont loose any data.

1) Please check the file /var/log/ispconfig_install.log if it contains any errors.
2) Did you update with the ispconfig_update.sh script or did you use the manual update procedure?

[Hans]

Originally Posted by till

@Hans: The error message means that the installer was not able to dump the ispconfig database. So it stopped to make sure that you dont loose any data.

1) Please check the file /var/log/ispconfig_install.log if it contains any errors.
2) Did you update with the ispconfig_update.sh script or did you use the manual update procedure?

Hi Till,

The/var/log/ispconfig_install.log does not contain anything regarding this upgrade.
What happened is that the ISPConfig packages has been downloaded and extracted.
After giving the MySQL root password during the upgrade, the upgrade stopt instantly.

Yes, i used the installer script ispconfig_update.sh.
I did create a backup of my mysql database on the shell, so making a dumpfile is working, but the installer script can't.

With all my respect for your work. I think there is something wrong with the new version and/or the upgrade script.
In the mean time i've seen that there are more users like me who have the same problem when they upgrade a slave ispconfig3 server.
The upgrade of master ISPConfig3 servers seems to be fine, but not on slave ISPConfig3 servers.

I did not upgrade my master ISPConfig3 server yet, as i want to upgrade my slave ispconfig3 servers first.

[till]

With all my respect for your work. I think there is something wring with the new version and/or the upgrade script.

I dont think so. Looks more like a configuration issue or a corruption in one of the mysql database tables thats prevents the export of the mysql tabales by mysqldump. I've upgraded already 5 slave servers yesterday, not a single one had a problem and I know several german hosters that updates their setups with slave servers too without an issue.

As I decribed above, the installer stops if the mysqldump command is not able to create a database dump.

Please run the update on the slave again by following the manual update instructions. When it fails, post the output of:

ls -lah

from within the install directory where you executed the update.php script.

[Hans]

Originally Posted by till

I dont think so. Looks more like a configuration issue or a corruption in one of the mysql database tables thats prevents the export of the mysql tabales by mysqldump. I've upgraded already 5 slave servers yesterday, not a single one had a problem and I know several german hosters that updates their setups with slave servers too without an issue.

As I decribed above, the installer stops if the mysqldump command is not able to create a database dump.

Please run the update on the slave again by following the manual update instructions. When it fails, post the output of:

ls -lah

from within the install directory where you executed the update.php script.

Till,

Thanks for your reply.
In theory it might be that the mysql database tables are corrupted.
But because i'm very careful, (1st time upgrading ISPConfig3) i started to upgrade a slave server which does not host any website yet.
With other words it is a brand new installation which i did not use yet.

Nevertheless, i will try the upgrade manually and will report my experience here as you told me to do.

[Hans]

@Till,

Same problem during the manual upgrade:

Possible problem with dumping the database. We will stop here. Please check the file existing_db.sqlxen6:/tmp/ispconfig3_install/install#

Here is the output of ls -lah :

total 116K
drwxr-xr-x 7 root root 4.0K 2010-03-12 10:09 .
drwxr-xr-x 9 root root 4.0K 2010-03-11 10:27 ..
drwxr-xr-x 2 root root 4.0K 2010-03-11 10:27 apps
drwxr-xr-x 5 root root 4.0K 2010-03-11 10:27 dist
-rw-r--r-- 1 root root 39K 2010-03-12 10:09 existing_db.sql
-rw-r--r-- 1 root root 20K 2010-02-10 14:05 install.php
drwxr-xr-x 2 root root 4.0K 2010-03-11 10:27 lib
drwxr-xr-x 2 root root 4.0K 2010-03-11 10:27 sql
drwxr-xr-x 2 root root 4.0K 2010-03-11 10:27 tpl
-rw-r--r-- 1 root root 2.9K 2009-02-12 11:33 uninstall-fedora.php
-rw-r--r-- 1 root root 2.9K 2008-12-10 16:42 uninstall.php
-rw-r--r-- 1 root root 19K 2010-02-25 16:04 update.php

So as you can see, i have existing_db.sql within /tmp/ispconfig3_install/install.
Why is asked for existing_db.sqlxen6 ?

(xen6 is the hostname of the VM)

[till]

I guess I see the problem now. As you did not used the server before the update, the dumped db is just below the minimum size that the updater expects. If you would just have created a website or two, the update should have run trough.


Please check the content of the existing_db.sql file. If it looks as it contains all the data of the dbispconfig database, then delete the existing_db.sql file, edit the update.php script in line 152 and change

if(filesize('existing_db.sql') < 60000)

to:

if(filesize('existing_db.sql') < 30000)

Then run update.php again to do the update. This is the solution for your case and not nescessarily the solution for the problems of the other posters.

So @everyone else in this thread: do the manual update procedure and then take a look at the size of the existing_db.sql file and its content. If it seems to contain all the data from the dbispconfig database, then proceed as I suggested to Hans in this post.

I will set the limit for the size check to 30000 in future updates.