Status: foundation only. Everything below works today except the actual propagation -- turning sync on records your intent, but no changes are pushed to another node yet. That part is still being built.
Keeps a job's steps, security, and/or schedules matching across other Minion Agent installations -- so the same job installed on every node of an Availability Group (or paired with a dev box) doesn't quietly drift apart when someone edits one copy.
Concepts
- Sync Peer (Admin -> Sync Peers) -- another Minion Agent installation, reached over its own Api at a URL you enter, authenticated with a regular SqlLogin credential. Not a SQL Server job-execution target.
- Job Sync Group (Admin -> Job Sync Groups) -- a named set of Sync Peers. Not every job needs the same partners, so a job picks a group rather than syncing to the whole fleet.
- Job Sync (the Sync button on a job) -- per-job participation: pick a group, a role, and which of three independent things to keep in sync -- Job/Steps, Security (step credentials, matched by name on each node), and Schedules. Each is its own checkbox.
Role: Editor vs. Receive-only
Editor -- this copy's edits push out to the rest of the group. A group where every member is an Editor is full multi-master sync. Receive-only -- this copy only ever receives changes, for a deliberate one-way relationship like prod to dev.
Setting it up
- Admin -> Sync Peers: add each other node you want to reach (host name + a SqlLogin credential).
- Admin -> Job Sync Groups: create a group, add the peers that should be members.
- On the job: click Sync, pick the group, pick a role, check whichever of Job/Steps, Security, Schedules you want kept in sync.
See also: Glossary for related terms.