In Airflow 2, how can several schedulers run at once without duplicating task instances?

## Before Airflow 2 In Airflow 1.10 the scheduler was a singleton. Running two was unsafe, so high availability meant an active/passive pair with an external supervisor, and scheduling latency for a large deployment was bounded by one process's loop time. Airflow 2.0's scheduler rewrite made active-active operation a supported, first-class deployment mode. ## The mechanism: database row locks There is no leader election and no partitioning of DAGs across schedulers. Every scheduler runs the same loop: find DAG runs that need creating, find task instances whose dependencies are met, queue them. Correctness comes from the metadata database. Before a scheduler acts on a set of rows it takes **row-level locks** with `SELECT ... FOR UPDATE`. Because the locks are held only for the duration of a short critical section and use `SKIP LOCKED`, a second scheduler issuing the same query simply receives a disjoint set of rows rather than blocking behind the first. The consequence is straightforward: exactly one scheduler transitions any given task instance to `queued`, so no task is dispatched twice, and work spreads across schedulers naturally by whoever grabs rows first. ## What that requires of the database Because the guarantee lives in the database, the backend must actually implement the locking semantics — in practice PostgreSQL or MySQL 8. This is the main reason Airflow's documentation is explicit that certain older or alternative backends are not supported for multi-scheduler deployments, and why SQLite is out of the question. It also means the metadata database becomes the scaling bottleneck. Every additional scheduler adds queries, locks and writes. Symptoms of over-subscribing look like scheduling latency going *up* as you add schedulers, lock waits in `pg_stat_activity`, and autovacuum falling behind on the `task_instance` table. Tuning `[scheduler] max_tis_per_query` and giving the database more headroom usually matters more than adding a fourth scheduler. ## What each scheduler must see All schedulers must have access to the same DAG files (baked image, git-sync, shared volume) and the same provider packages. If one scheduler cannot import a DAG, the behaviour is confusing rather than dramatic: that scheduler simply never contributes work for it while the others do, and you get intermittent, hard-to-explain scheduling gaps. The same rule applies to workers, so most deployments distribute one artefact to everything. Running a **standalone DAG processor** (`airflow dag-processor`) separates parsing from scheduling, which makes multi-scheduler setups cleaner: parsing happens once, in its own process, and schedulers work from serialized DAGs in the database. Airflow 3 makes that separation mandatory. ## What it buys you - **Failover.** Killing a scheduler — a node dying, a rolling upgrade — degrades throughput but never stops scheduling. Tasks in flight are unaffected; tasks the dead scheduler had queued are adopted or reset when it comes back or by its peers. - **Latency.** With thousands of task instances per loop, more schedulers means the queue-eligible set is drained faster, cutting the time between "dependencies satisfied" and `queued`. ## What it does not buy you It does not increase execution capacity — that is the executor's and workers' job. It does not remove the metadata database as a single point of failure; the database is still the thing to make highly available. And it does not protect against a bad DAG file: a DAG whose parse takes 60 seconds slows every scheduler that parses it. ## How many to run Two is the usual starting point, purely for availability. Go to three or more only with evidence: a measured scheduling delay (Airflow exposes scheduler loop and task-queueing metrics via StatsD/OpenTelemetry) and a database with the headroom to absorb it.