...
- The capability to re-connect to a database does not imply that JobScheduler will cope with data loss, in fact JobScheduler relies on the job history and job-related status information being consistent and available with the database.
- For use with replicated databases keep in mind that the delay that is caused by replication can result in data loss.
- Depending on the DBMS this delay might be smallshort, 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.
- To our knowledge 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 always re-connect after connection loss or occurrence of a failed transaction.
- Unsupported vendor-specific mechanisms include e.g. SQL Server® multi-subnet clustering or MySQL® with Galera® JDBC fail-over that expect the client to switch the connection to some different address.
- In case of fail-over the clustered database is expected to be available with the same connection attributes, e.g. hostname, port. This can include mechanisms as e.g. DNS switching to make a different database server the primary server in case of fail-over.
- To our knowledge clustered databases are frequently used to achieve a database availability of up to approx. 99.999%.
...