Slave Server Status not Actualised / Scheduled Backups not Working

Discussion in 'ISPConfig 3 Priority Support' started by Ralph Keck, Aug 16, 2019.

Tags:
  1. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    In a IPSConfig multiserver setup (master/slave) jobs on slave server are no longer be executed. Database and mail replication are working fine, so does unison.
    I had configured backup to run on both servers at different times, but these backups are no longer executed on the slave. Also the slave health status is not actual (updates, services, ISPConfig version...)

    Big question mark in my eyes! o_O

    Thanks for helping
    Ralph
     
    Ralph Keck, Aug 16, 2019
    #1
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    try to connect from slave to master server with the mysql command by using the master database login details from ISPConfig config.inc.php file of the slave server.
     
    till, Aug 16, 2019
    #2
  3. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    I can connect to the master server with the above mentioned details. This user is seeing 16 tables in the ISPConfig schema. Is that ok?
     
    Ralph Keck, Aug 16, 2019
    #3
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    That should be ok. Please take a look into the dbispconfig database on the slave, in the sys_cron table. Each record has a next_run date, these dates should be max 24 hours in the future.
     
    till, Aug 16, 2019
    #4
  5. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    These entries are ok, but the jobs are executed only on the master. As by the cluster setup for Debian 8.4 there is a master-master replication between the two servers and any change to the sys_cron table in the slave's dbispconfig database is replicated instantly to the master and the job is executed there. I am running Debian Buster on both machines. To get the chance to reconfigure the services, I updated to the git-stable repo and back to the stable 3.14p2 release. Each time on the slave first. Now I am back on the current stable but in the monitoring overview the slave still shows 3.1dev
     
    Ralph Keck, Aug 16, 2019
    #5
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Sorry, I meant you have to look into the dbispconfig2 database as that's the one which is used by the slave. The dbispconfig database that is replicated from master to slave is not used by the slave. There is a bug in current dev version which prevent cronjobs from being executed as it sets the next run time to January 2020, I'm quite sure that you have that issue too when you had dev branch on your servers. Take a look at
     
    till, Aug 16, 2019
    #6
    Ralph Keck likes this.
  7. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    That's the trick...
    Thanks a lot, Till!
     
    Ralph Keck, Aug 16, 2019
    #7
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    We have no fix for that yet, when the fix is available later today, then I'll post instructions on how to fix it.
     
    till, Aug 16, 2019
    #8
  9. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    That is no problem. After an UPDATE 'sys_cron' SET 'next_run' = 'actual date and time plus five minutes', the jobs are executed and next_run is set correctly. For me this is ok as a workaround.
     
    Ralph Keck, Aug 16, 2019
    #9
  10. till

    till Super Moderator Staff Member ISPConfig Developer

    Ok, you updated to stable, right? This fixes it as well in combination with setting the next_run date, the problem exists in dev only.
     
    till, Aug 16, 2019
    #10
  11. Ralph Keck

    Ralph Keck New Member HowtoForge Supporter

    Yes, as this is a production environment.
     
    Ralph Keck, Aug 16, 2019
    #11

Share This Page