For the datalog, only the highest value in the updated column matters, so it's ok if jobs were skipped. There must be either a server in the server column that does not exits anymore physically so it can't process it's jobqueue or on of the other servers fails to pick up the changes, so there must be a server in server table where updated column is lower than the max value of sys_datalog_id if the red bubble shows up.
my case is: i have a master server(primary dns,web,mail and database server) and a slave server(only secondary,mirrored dns server). I wont to set ipv6 address for the secondary in the server ip menu but i noticed false configured and configured again and again (maybe to quick) it wasn't a good idea. the sysdatalog id is now the same with the server/updated column (serverid: 1) when i set it up back to with the same value as the datalogid with this actions, the jobs starts to run but stop by these unsuccesfully actions. all other function work, i tried
If there are any unsuccessful actions, then you can see in debug output what these actions are and why they fail to fix them.
so the 2nd server can not read the data from the master or update some data on the master. you can compare the updated-value from the master and slave server (dbispconfig.server)
That is normal, a slave server works through tasks in the sys_datalog table directly in the master's database.
this jobs cannot be processed again because i delete the 2.server ip finally. when i try to add the2.server ip again,this job is pending in the admin panel(jobsqueue and red bubble) but in the database are the jobs updated
The view you posted is the result of a query of the same database. maybe you looked into the wrong database? You have to check in master database, if that#s a multiserver system.
yes,it's a multiserver system. the screenshot is from primary server(web+mail+mysql+dns) and the web interface is running on it. on the other server is running only dns service (secondary dns,it's mirrored). when i try to configure something with server ip will proceed (i'm see in database) but the notification stay displayed
Then your slave servers have probably issues connecting to the master database to update the status. Run an ispconfig update on the slave systems and choose to reconfigure permissions in the master database.
