Replication flow-control tickets and majority-commit lag diagnosis

Parent: MongoDB Replication · Published reference · snapshot 2026-10-27

Source-anchored research for Replication flow-control tickets and majority-commit lag diagnosis. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Structure and components

Diagnose throttling with both flow-control statistics and member progress: run rs.printSecondaryReplicationInfo(), inspect member reachability and writeMajorityCount, and examine ticket-wait growth. Reachable-member lag, majority availability, and actual admission waits answer different parts of the diagnosis. (medium confidence) [source]

How it works

On the primary, isLagged reports engagement; isLaggedCount counts engagements since restart and isLaggedTimeMicros accumulates engaged duration. Historical totals therefore do not by themselves establish that flow control is active now. (medium confidence) [source]
Start diagnosis on the primary with rs.printSecondaryReplicationInfo() and db.runCommand({serverStatus:1}).flowControl.isLagged. Replication lag can occur without enough load to engage flow control; if isLagged is false, investigate secondary hardware, network and application constraints. (medium confidence) [source]
Reachable secondaries showing zero lag do not exclude flow-control throttling. Percona reproduced a seven-member configuration with six data-bearing members and an arbiter where only three data-bearing members remained reachable, while writeMajorityCount was four; surviving secondaries were current but the majority commit point could not advance normally. (medium confidence) [source]
The MongoDB master admission README separates flow-control tickets from execution-control tickets: when both are needed, flow control precedes execution control and is required for MODE_IX global-lock requests. Diagnose the relevant admission mechanism before interpreting a generic ticket shortage. This source describes master, not a pinned release. (low confidence) [source]
Flow-control admission applies to global MODE_IX lock requests. The ticket rate is therefore a lock-admission budget, not a direct document-write throughput measurement; locksPerKiloOp estimates locks acquired per 1000 operations. (high confidence) [source]
The documented flow-control budget calculation considers majority-commit lag relative to its target, operations applied by the secondary sustaining the commit point, and locks per operation. The Mydbops description says exhausted tickets block acquisition until the next one-second refresh; verify this implementation detail against the deployed server branch. (low confidence) [source]
isLagged reports whether flow control is engaged; isLaggedCount and isLaggedTimeMicros record engagement count and time since restart. Engagement can begin at a percentage of flowControlTargetLagSeconds, so the target must not be interpreted as an exact on/off threshold. (high confidence) [source]
Replication lag can exist while flowControl.isLagged is false, including when an unresponsive secondary lags but the set has insufficient load to engage flow control. A false flag does not prove that secondaries are current. (high confidence) [source]
A successful election and a custom numeric write concern do not establish that the configured write majority is available. In Percona's outage example, w:2 writes succeeded while majority-commit lag still engaged flow control; inspect rs.status().writeMajorityCount and all member states alongside secondary lag. (medium confidence) [source]
ApsaraDB's parameter guidance dated 2026-09-11 documents a default flowControlTargetLagSeconds of 10 and says increasing the target makes flow control less sensitive. Persistent throttling after increasing it calls for replication performance investigation; increasing the target alone does not repair that bottleneck. (medium confidence) (verified as of 2026-09-11) [source]

Problems, failure modes and limitations

In a PSA replica set, losing a data-bearing node can leave a primary able to accept w:1 writes while majority writes cannot succeed and the commit point lags. Election success alone does not establish majority-write availability. (medium confidence) [source]
For a slow operation, compare flowControl.timeAcquiringMicros with durationMillis after converting units. Alibaba's example records 959000 microseconds waiting for flow control in a 959-millisecond request, demonstrating that ticket waits can account for nearly the entire operation duration. Do not compare those raw numbers without unit conversion. (medium confidence) [source]
MongoDB issue SERVER-92061 records an investigation where flowControlMinTicketsPerSecond=100 did not reduce secondary lag for large batched inserts. This is evidence of a workload-specific limitation, not proof that flow control always bounds lag or that a particular released version fixes it. (low confidence) [source]

Comparisons and alternatives

Flow control throttles write admission on the primary to keep majority-committed replication lag near a configurable target. It limits tickets issued per second before writes take locks; it attempts to bound lag rather than guaranteeing a hard ceiling. (high confidence) [source]

Facts and statements

On the primary, serverStatus.flowControl.targetRateLimit is the maximum tickets acquired per second; timeAcquiringMicros is total write-operation time waiting for tickets. Secondary values are placeholders and should not diagnose primary throttling. (medium confidence) [source]
The primary flowControl.sustainerRate approximates operations applied per second by the secondary sustaining the commit point; locksPerKiloOp approximates locks per 1000 operations. A ticket rate is therefore not simply an application request-throughput metric. (medium confidence) [source]
The default flowControlTargetLagSeconds is documented as 10 seconds in Alibaba Cloud parameter guidance dated September 11, 2026; this is a target for majority-commit lag, not a guarantee that every secondary stays within ten seconds. (medium confidence) (verified as of 2026-09-11) [source]
Inspect db.serverStatus().flowControl on the primary: targetRateLimit is the maximum ticket acquisition rate, timeAcquiringMicros measures accumulated ticket wait time, and sustainerRate approximates the apply rate of the secondary sustaining the commit point. Secondary values for these metrics are placeholders. (high confidence) [source]

Children

Flow-control sustainer selection and ticket-rate calculation (frontier)
Flow-control admission accounting versus execution-control ticket pools (frontier)
Batched insert workloads and minimum-ticket limitations (frontier)
Flow-control ticket refresh and lock-to-operation sampling (frontier)
Sustaining-secondary throughput and majority-commit progress (frontier)
Topology failures that stall majority commit while reachable secondaries stay current (frontier)

Frontier under this node: Batched insert workloads and minimum-ticket limitations, Flow-control admission accounting versus execution-control ticket pools, Flow-control sustainer selection and ticket-rate calculation, Flow-control ticket refresh and lock-to-operation sampling, Sustaining-secondary throughput and majority-commit progress, Topology failures that stall majority commit while reachable secondaries stay current

← the whole tree · 3D view· how to read this page