Skip to end of metadata
Go to start of metadata

How does JobScheduler behave in the event of a database failure?

Consider the following worst case scenario:

  • Let’s say that JobScheduler and the back-end database failed at 4:00 and that jobs scheduled to run at 3:00 have already run.
  • A job that was scheduled to run at 6:00 has not run.
  • The back-end database was restored from a backup made at 1:00 and JobScheduler was running again at 9:00.

What would happen with the jobs that were scheduled to run between 1:00 and 9:00 when the JobScheduler came back on?

  • Would the 3:00 job and the 6:00 job run?
  • Would only the 6:00 job run?
  • Or would jobs only scheduled for 9:00 and later run?

Job and order start times are not stored in the database but in the JobScheduler configuration files. The job and order history with the job and order states, log files, etc. are stored in the database. (See JobScheduler History and Which information is stored in a database by JobScheduler? for more information.)
This means that the states of jobs and orders that have run in the time between the last database backup that was made before the failure and the failure itself will be lost. This also applies for the jobs and orders that are running when the database fails.

Will jobs that were scheduled for the downtime be run?

Jobs and orders that are scheduled to run whilst JobScheduler is down will not be started after recovery of the JobScheduler and its database. This means that jobs and orders that have not run will have to be started manually once JobScheduler is running again.

JobScheduler Information Dashboard

The JobScheduler Information Dashboard (JID) is a useful aid in the event of database failure. It provides a clearly laid out comparison between the jobs that have been planned and those that have actually been completed. This is easier and less prone to errors than a manual comparison.


Note that reverting to a database backup (rollback) can have significant effects on events, if used by JobScheduler. This could mean that events that have already been processed could be reactivated and that events that have already been set may, in some situations, be deactivated.

For more information see the JobScheduler Events Manual.

Database failure

Note that if the JobScheduler database fails but JobScheduler itself continues to run then the default configuration is that JobScheduler tries to re-establish the database connection a number of times at regular intervals. If this is not successful then JobScheduler will stop. The parameters that define this behaviour are defined in the factory.ini file.


Write a comment…