...
- If the connection to a database gets lost or if a database failure occurs the JobScheduler Master will try to re-connect.
- A Master single instance can be configured to repeat an unlimited number of connection attemps.
- A Master Active Cluster member requires the database connection to become available within 120s. Otherwise the cluster member terminates in order to prevent duplicate execution of jobs.
- For use with replicated databases keep in mind that the delay that is caused by replication might result in data loss.
- Depending on the DBMS this delay might be small, however, it might result in duplicate execution of jobs if the information about a previous job run is not available with the replicated database in case of fail-over.
- Replicated databases are frequently used to achieve a database availability of up to approx 99.9%.
- For use with clustered databases JobScheduler does not rely on vendor-specific connection continuity mechanisms but complies with JDBC standards and will simply re-connect after connection loss.
- Unsupported vendor-specific mechanisms include e.g. SQL Server Server® multi-subnet clustering or MySQL Galera MySQL® with Galera® JDBC fail-over that expect the client to switch the connection to some different address.
- Instead, in case of fail-over the clustered database is expected to be available with the same connection attributes. This could include e.g. DNS switching to make a different database server the primary server in case of fail-over.
- Clustered databases are frequently used to achieve a database availability of up to approx. 99.999%.
...