Scheduler

7.2.1.1 Scheduler

monitoring-scheduler (2.1)

Note: The scheduler is disabled by default. On a fresh install, no maintenance jobs (backups, optimize, analyze, schema monitoring, etc.) will run until monitoring-scheduler is explicitly set to true in the configuration. The individual cron toggles (e.g. scheduler-db-servers-logical-backup) only take effect when the global scheduler is enabled.

Warning: When the scheduler is enabled and prov-db-config is true (default), the dbjobs script will also track and deploy database configuration files from compliance tags. This means configuration files may be pushed to your database servers. If you manage your own my.cnf and don't want the configurator to modify your database config, set prov-db-config = false in your configuration or disable it via Settings > Scheduler > Enable Configurator in the GUI. See Config Tracking for details.

7.2.1.2 CRON Expression Format

A cron expression represents a set of times, using 6 space-separated fields.

Note: Month and Day-of-week field values are case insensitive. "SUN", "Sun", and "sun" are equally accepted.

Special Characters Asterisk ( * )

The asterisk indicates that the cron expression will match for all values of the field; e.g., using an asterisk in the 5th field (month) would indicate every month.

Slash ( / )

Slashes are used to describe increments of ranges. For example 3-59/15 in the 1st field (minutes) would indicate the 3rd minute of the hour and every 15 minutes thereafter. The form "*\/..." is equivalent to the form "first-last/...", that is, an increment over the largest possible range of the field. The form "N/..." is accepted as meaning "N-MAX/...", that is, starting at N, use the increment until the end of that specific range. It does not wrap around.

Comma ( , )

Commas are used to separate items of a list. For example, using "MON,WED,FRI" in the 5th field (day of week) would mean Mondays, Wednesdays and Fridays.

Hyphen ( - )

Hyphens are used to define ranges. For example, 9-17 would indicate every hour between 9am and 5pm inclusive.

Question mark ( ? )

Question mark may be used instead of '*' for leaving either day-of-month or day-of-week blank.

7.2.1.3 Default Schedule Summary

The following table summarizes all scheduler defaults:

On startup, if no cached table metadata exists (e.g. after a fresh upgrade), a one-time schema scan is triggered automatically regardless of the cron schedule.

7.2.1.4 CRON Jobs Configuration

scheduler-db-servers-logical-backup (2.1)

Logical backup in Replication-manager (2.1) are done via mysqldump client from the replication-manager host to the master database with non blocking and replication position options.

It's alway safer to backup the master despite it was advice to backup slaves, Signal18 don't think this a best practice to backup slave.

Yes Logical backup are slow, but for good reason it's supposed not to get all your databases CPU and IO so that you may take it without trouble to your workload!

Logical backup are needed for long time archiving of your data, it's the only way to prevent physical data corruption that can happen with hardware issues, databases bugs, Kernel and FS bugs.

scheduler-db-servers-logical-backup-cron (2.1)

scheduler-db-servers-physical-backup (2.1)

scheduler-db-servers-physical-backup-cron (2.1)

Physical backups are day to day backups in MySQL & MariaDB and works like FS snapshots, tracking database changes while copying physical pages. It is non blocking when InnoDB storage engine is mostly used for most tables , big non transactional table will be lock for WRITES a (READ LOCK) will still enable to READ non transactional tables.

Physical backups like innodbhotbackup, xtrabackup and mariabackup need to take place on the database host itself but can be stream to replication-manager for archiving or reused for re-seeding new slaves or old died masters.

scheduler-db-servers-logs (2.1)

scheduler-db-servers-logs-cron (2.1)

replication-manager take care of monitoring replication but can be extend to a central point for database error logs and query log analyze, using this option the logs of the database are requested on this schedule to replication-manager for a central point of analyze and alerting. We will provide the tools to classify the queries and understand databases miss configuration and workload

Our donor script will purge the log on the database server after sent out so that growing logs don't consume the disk space and memory of the db host itself.

scheduler-db-servers-optimize (2.1)

scheduler-db-servers-optimize-cron (2.1)

scheduler-db-servers-analyze (2.1)

scheduler-db-servers-analyze-cron (2.1)

scheduler-db-servers-logs-table-rotate (2.1)

scheduler-db-servers-logs-table-rotate-cron (2.1)

monitoring-schema-scheduler (2.1)

monitoring-schema-scheduler-cron (2.1)

Schema monitoring detects table additions, removals, and structural changes (columns, indexes). On startup, if no cached table metadata exists (e.g. after a fresh upgrade), a one-time schema scan is triggered automatically regardless of the cron schedule.

monitoring-checksum-scheduler (2.1)

monitoring-checksum-scheduler-cron (2.1)

scheduler-rolling-restart (2.1)

scheduler-rolling-restart-cron (2.1)

scheduler-rolling-reprov (2.1)

scheduler-rolling-reprov-cron (2.1)

scheduler-jobs-ssh (2.1)

The database jobs keep their logs, checkpoints and locks on the database host, in <datadir>/.system/jobs. The configuration replication-manager generates hides .system from the databases (ignore_db_dirs=.system). A MariaDB server configured without it would list .system as a database, #mysql50#.system, on which mariadb-dump --all-databases and mysqlcheck --all-databases fail (error 1102, "Incorrect database name"). So on a MariaDB server whose ignore_db_dirs does not name .system, the jobs use /var/lib/replication-manager-jobs instead, as with the nosplitpath tag. MySQL and Percona list no hidden folder as a database.

A physical reseed or flashback stages the backup in <datadir>/.system, which must be on the datadir's disk. When .system did not exist before, the restore removes it when it ends, whether it succeeded or failed, or at the next job run once every process of a killed restore is gone. A .system that was already there is never removed.

A .system folder left from an earlier version can be moved out of the datadir once no job runs, or hidden by adding to the server configuration (restart needed):

[mariadb]
ignore_db_dirs=.system

While the folder is listed, a logical backup names its databases instead of --all-databases, so the backup still runs.

scheduler-jobs-ssh-cron (2.1)

scheduler-sla-rotate (2.1)

scheduler-sla-rotate-cron (2.1)

scheduler-alert-disable (2.1)

scheduler-alert-disable-cron (2.1)