dgraph-io/dgraph · error

Backup request group mismatch. Mine: %d. Requested: %d

Error message

Backup request group mismatch. Mine: %d. Requested: %d

What it means

backupCurrentGroup validates that the local worker's group matches the GroupId in the incoming BackupRequest. If the node receiving the backup request belongs to a different raft group than requested, the request is rejected. This guards against routing mistakes where a backup request lands on the wrong shard/group.

Source

Thrown at worker/backup.go:185

	return errors.Wrapf(err, "cannot export data inside DB at %s", dir)
}

// Backup handles a request coming from another node.
func (w *grpcWorker) Backup(ctx context.Context, req *pb.BackupRequest) (*pb.BackupResponse, error) {
	glog.V(2).Infof("Received backup request via Grpc: %+v", req)
	return backupCurrentGroup(ctx, req)
}

func backupCurrentGroup(ctx context.Context, req *pb.BackupRequest) (*pb.BackupResponse, error) {
	glog.Infof("Backup request: group %d at %d", req.GroupId, req.ReadTs)
	if err := ctx.Err(); err != nil {
		glog.Errorf("Context error during backup: %v\n", err)
		return nil, err
	}

	g := groups()
	if g.groupId() != req.GroupId {
		return nil, errors.Errorf("Backup request group mismatch. Mine: %d. Requested: %d\n",
			g.groupId(), req.GroupId)
	}

	if err := posting.Oracle().WaitForTs(ctx, req.ReadTs); err != nil {
		return nil, err
	}

	closer, err := g.Node.startTaskAtTs(opBackup, req.ReadTs)
	if err != nil {
		return nil, errors.Wrapf(err, "cannot start backup operation")
	}
	defer closer.Done()

	bp := NewBackupProcessor(pstore, req)
	defer bp.Close()

	return bp.WriteBackup(closer.Ctx())
}

View on GitHub (pinned to 759e242be6)

Solutions

  1. Verify the request is being sent to a server that belongs to the requested group (check group membership via Zero)
  2. Refresh cluster state / restart the client so it picks up current group membership
  3. Fix client code to use the group-discovery path (AnyServer) instead of hardcoding a node
  4. Confirm the cluster's group assignments are stable and the client config GroupId matches an existing group

Example fix

// before
res, err := pb.NewWorkerClient(anyNodeConn).Backup(ctx, req) // may hit wrong group
// after
pl := groups().AnyServer(req.GroupId)
if pl == nil {
    return nil, errors.Errorf("no server in group %d", req.GroupId)
}
res, err := pb.NewWorkerClient(pl.Get()).Backup(ctx, req)
Defensive patterns

Strategy: validation

Validate before calling

if groups().groupId() != req.GroupId {
    return errors.Errorf("local group %d cannot serve backup for group %d", groups().groupId(), req.GroupId)
}

Try / catch

resp, err := BackupGroup(ctx, req)
if err != nil && strings.Contains(err.Error(), "group mismatch") {
    // re-route to a server in req.GroupId via AnyServer and retry once
}

Prevention

When it happens

Trigger: A Backup or BackupGroup gRPC request arrives at a worker whose groups().groupId() differs from req.GroupId — e.g. a client sent the backup request to a node not in the target group.

Common situations: Stale cluster membership after a rebalance; client/server group configuration out of sync; load balancer routing the request to an arbitrary Alpha/worker node; calling BackupGroup on a node in the wrong group without letting the AnyServer redirect path run.

Related errors


AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/a7843c20b9dac502. Report an issue: GitHub.