Skip to content

scheduled jobs: avoid "top-of-the-hour" service level degradation #54537

@mwang1026

Description

@mwang1026

When creating a schedule it's common to use simple cron syntax of '@daily' or '@hourly'. The downside of that is if every schedule is created with that syntax, cron runs at at the top of the hour / day. And if every service across all of your systems are using similar scheduling syntax then you get times where your services are hosed.

What we're looking for here is something where you can create schedules to avoid the above issues. "Random" or some sort of random jitter is probably a good enough heuristic to spread schedules out to avoid the problem. The ideal is to have a solution that can identify the best times to run to avoid "top of the hour" degradation.

For certain scheduled operations, you also want them to be on a consistent cadence but on staggered start times (e.g. every hour on the 23rd minute) -- namely Backups so that you can target an RPO.

  • Deliverables *
  • A way to specify randomness of the start time within the recurring window
  • That randomness is applied on the initial schedule and the specified cadence determines future schedule times
  • Other alternatives *
  • Load based determination of when a schedule should run
  • Randomness that's always applied on every run

Epic CRDB-7909

Jira issue: CRDB-3742

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-disaster-recoveryA-jobsC-enhancementSolution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)T-jobs

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions