vitessio/vitess · error
target_replication_lag_sec must not be higher than max_repli
Error message
target_replication_lag_sec must not be higher than max_replication_lag_sec: invalid: %v > %v
What it means
Returned by throttler config validation when target_replication_lag_sec exceeds max_replication_lag_sec, which is an inconsistent configuration; both values must satisfy target <= max.
Source
Thrown at go/vt/throttler/max_replication_lag_module_config.go:93
func NewMaxReplicationLagModuleConfig(maxReplicationLag int64) MaxReplicationLagModuleConfig {
config := defaultMaxReplicationLagModuleConfig.Clone()
config.MaxReplicationLagSec = maxReplicationLag
return config
}
// TODO(mberlin): Add method which updates the config using a (partially) filled
// in protobuf.
// Verify returns an error if the config is invalid.
func (cfg MaxReplicationLagModuleConfig) Verify() error {
if cfg.TargetReplicationLagSec < 1 {
return errors.New("target_replication_lag_sec must be >= 1")
}
if cfg.MaxReplicationLagSec < 2 {
return errors.New("max_replication_lag_sec must be >= 2")
}
if cfg.TargetReplicationLagSec > cfg.MaxReplicationLagSec {
return fmt.Errorf("target_replication_lag_sec must not be higher than max_replication_lag_sec: invalid: %v > %v",
cfg.TargetReplicationLagSec, cfg.MaxReplicationLagSec)
}
if cfg.InitialRate < 1 {
return errors.New("initial_rate must be >= 1")
}
if cfg.MaxIncrease <= 0 {
return errors.New("max_increase must be > 0")
}
if cfg.EmergencyDecrease <= 0 {
return errors.New("emergency_decrease must be > 0")
}
if cfg.MinDurationBetweenIncreasesSec < 1 {
return errors.New("min_duration_between_increases_sec must be >= 1")
}
if cfg.MaxDurationBetweenIncreasesSec < 1 {
return errors.New("max_duration_between_increases_sec must be >= 1")
}
if cfg.MinDurationBetweenDecreasesSec < 1 {View on GitHub (pinned to 01a25a7d17)
Solutions
- Raise max_replication_lag_sec to be >= target_replication_lag_sec.
- Lower target_replication_lag_sec to be <= max_replication_lag_sec.
- Call Verify() on your config early (at flag-parsing time) to fail fast with a clear message.
Example fix
// before MaxReplicationLagSec: 2, TargetReplicationLagSec: 10 // 10 > 2 -> error // after MaxReplicationLagSec: 10, TargetReplicationLagSec: 5
Defensive patterns
Strategy: validation
Validate before calling
if cfg.TargetReplicationLagSec > cfg.MaxReplicationLagSec {
return errors.New("target_replication_lag_sec must be <= max_replication_lag_sec")
}
if err := cfg.Verify(); err != nil { return err } Try / catch
if err := cfg.Verify(); err != nil {
return vterrors.Errorf(vtrpcpb.Code_INVALID_ARGUMENT, "bad throttler config: %v", err)
} Prevention
- Pick target as a fraction of max (e.g. target = max/2) in your config templates.
- Validate both fields together at flag-parse time.
- Document units (seconds) in tooling so operators don't mix ms and s.
When it happens
Trigger: Constructing MaxReplicationLagModuleConfig with TargetReplicationLagSec > MaxReplicationLagSec and calling Verify() (via NewMaxReplicationLagModule or newThrottlerFromConfig). Also fires when MaxReplicationLagSec < 2 validation order puts target above an already-too-small max.
Common situations: Operators set a tight target_replication_lag_sec (e.g. 5) but forgot to raise max_replication_lag_sec (e.g. left at 2), or disabled lag throttling on one field but not the other.
Related errors
- invalid NewMaxReplicationLagModuleConfig: %v
- invalid max replication lag config: %w
- maxRate must be >= 0: %v
- ignoring higher good rate of %v because we assume that the k
- ignoring lower bad rate of %v because such a high degradatio
AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01).
Data as JSON: /api/errors/d80e45eae48dfdff.
Report an issue: GitHub.