Hi, Updated a few days ago to 3.0.5.1 and now wanted to add a new VServer. Followed this guide : Installing-openvz-plus-management-of-vms-through-ispconfig-3-debian-6.0. The error I am getting is : What seems a bit strange is that I do not have a database user named : c6armbrust. This one has been deleted some time ago. From the new VServer I have checked that MySQL connection is working to the master. I have testet and have no problem creating to my other 2 VServers. What have I missed / done wrong?
Did you update both servers to 3.0.5.1 and did you choose to update permissions in master database on at least one of the servers?
All servers have been updated to 3.0.5.1. I did not choose to update permissions in master database on at least one of the servers. My server setup consists of master server and 3 OpenVZ Servers. All have 3.0.5.1 - same goes for all containers on the 2 OpenVZ Servers working fine (got 14 containers). The fault only happens to the newly installed OpenVZ Server. Just tried on the 2 other OpenVZ Servers and can create containers / ip's and so on.
[solved] I was about to give up on this - but gave it a new try. I had been searching for one of the words from the error message but used the setting "exact match" in phpmyadmin - did a new search but with "one of the words". It turned out that some "old" items was listed in "sys_datalog". I deleted these and everything is now working fine. New question : Should "sys_datalog" be empty? - noted that mine has a little over 16.000 lines all with status "pending"
Hi! Just FYI. I've had the same problem. And the solution was about to update the new server install because I've connected it to the master without updating the slave, so it gives me that error. So, my solution was: Set ACTIVE: NO in Master ISPConfig server configuration update the ispconfig of the new slave to last version Set ACTIVE: YES in Master ISPConfig server config That solved my issue.
No, sys_datalog shall not be empty and you may never empty it in phpmyadmin with the "truncate" function as this resets the counter for all new items and the slaves will stop the mirroring. The sys_datalog is managed by ispconfig internally, so never touch it. The solution from DaWy is the right one: all servers in a cluster must run the same ispconfig version. If thats not the case, the replication will fail.
