The update went fine on one of my servers, but shows an err in the monitor. The ISPConfig Log has: Code: Unable to connect to the database Can't create database 'c2list'; database exists c2list is one of the databases I had before the update, and I didn't change any permissions. I can't honestly say the error wasn't there before the update because I didn't check just before running it. I know it wasn't there a short time ago though.
The error just means that the database could not be created because it existed already. Just click on the delete button in the error lost to remove it as it will block the config queue otherwise.
Thanks Till that looks better now. After I removed it it showed up again though. I tried backing it up, and removing it. ISPC made a new one so I thought it would be happy now, but it keeps generating tha same error. This was my first upgrade after moving to version 3.
This has nothing to do with a ispconfig update. Basically you can not create a database adain that exists already.
So how do I stop the error. It keeps coming back even if I delete the database. I don't see how we can ever upgrade again if it won't like the databases that are already there.
From root I did "ispconfig_update.sh". I've really messed things up now. My two servers are replicated/mirrored, and when I removed the DB on web1 it of course removed it on web2.
It does seem that this was all because of DB replication. I guess I needed to shut off replication completely before I did any upgrade. Because I didn't, the upgrade of one got stuck in the DB logs so it kept trying to do the same on the other slave. The two databases just kept trying to sync each other, which kept messing them up. What I ended up doing was shut off the slaves, fixed the databases from back up, the completely redid the master/master replication setup so the all at the same point again. I won't make that mistake next time.
Ok, this means you use mysql replication? This is not compatible with ispconfig 3, no wonder that the update failed. ISPConfig uses its own replication.
OK now I'm really confused. I asked that when I first started this project, but it sounded like because I was running this as a load balancer/fail over system, the built in replication wouldn't work. I need both servers to be exactly the same in case of fail over to the second server. I even tried installing ISPC on the second server as a slave, but it didn't seem to work. Am I wrong, and I should reinstall it? If that's true, how should it be done?
You can not use ispconfig on the second server for a failover setup as ispconfig does not support mirroring in the current release. For your setup, as you use mysql replication, ispconfig should be installed only on the first server and not on the second server and then you will have to replicate the data to the second server with mysql replication and rsync.
Don't I need ISPConfig to run all the services? ISPConfig controls them after the install, so if it's on the primary server the second server, even if replicated, wouldn't work. My setup seems to be working as is. The DB replication ignores tables server, monitor_data, and the log. If you can explain how I can run the second server without ISPConfig, I'd be happy to try it.
If it would work why are we having this thread then? In a master slave setup a ispconfig sytsem relicates the data itself, so if you use ispconfig on both servers plus replication from mysql the updates collides and you get the errors that you posted here like that ispconfig tries to insert a database while this databse already exists because you mirrored it. Either you wait for ispconfig 3.0.2 which will provide mirroring or you remove ispconfig from the second server and copy all changed config files, system users etc to the second server with rsync and restart the services on the second server afterwards.
When I said it was working, I meant that it seemed to be working until I did the upgrade. If I remove ISPConfig from the second server, and copy the changed files over, will the second server work in case of failover? Isn't ISPC controlling, for example, the DNS service, Postfix, etc.? Any ideas how long before 3.0.2?
ISPConfig is a controlpanel, this mean that it writes config files etc. It is not controllind any services, it writes just the configuration for these services. In a few months. But you will have to remove your kind of replication in this ca ase anyway as it conflicts with ispconfig. Maybe you should leave your setup just as it is if it works for you and dont upadte ispconfig on the second server for now.
OK Till, Thanks. I'll keep things as they are and hope it all works together in case of failure. In the mean time I'll keep testing my setup.
