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
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.
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!
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.
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.
@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)
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.
Hi Till, Thanks for your explanation. What you say can be the reason indeed. I will do the upgrade not now but tonight and report how i'm doing.
From United Stated --> Columbus, Ohio I figured out how to fix my issues and rollback my upgrade. 1. My database was completely empty(no tables existed either) 2. Had to restore the table structure from my 3.0.1.6 from original 3.0.1.6 install/sql folder 3. Had to truncate all the tables in it 4. Restored my SQL backup before the upgrade. 5. Tested and everything works! Could have done this: Now I could have restored my VMWARE snapshot image, but wanted to figure out why this upgrade failed the way it did. Just took time to understand. My log files show nothing as well. Thanks Eric
This can only happen if you modified a table in ispconfig or added an additional table into the same database which made the table structure of your data incomtaoble with the new ispconfig version. To fix this, undo the changes that you did on the tables e.g. delete the fields ortables that you added before you do an update. You can find the incompatible tables by creating a new temporary mysql database, then load the database dump from the ispconfig_install/install/sql/ispconfig3.sql into this database, truncate all tables. then export all data from your current ispconfig database and try to reimport it in our temporary database.
I had made no modifications personally and I am the only admin for my servers. Could it have occurred if the install was ran twice? the only thing I do is update my Ubuntu server once a week. In any case it is resolved
Thanks Till for your sharp view! I just updated all my ISPConfig3 servers (6 in total) without any problem.
