Skip to content

[client] Expose all coordinator servers (leader and standbys) via the client API #4117

Description

@affo

Search before asking

  • I searched in the issues and found nothing similar.

Motivation

Since coordinator HA (1.0), a cluster may run several coordinator servers, but the client API still surfaces exactly one: MetadataResponse carries a single coordinator_server (the current leader), and Admin#getServerNodes() returns that node plus the alive tablet servers. Standby coordinators are invisible to clients — they reject every request except apiVersions with NotCoordinatorLeaderException.

Operational tooling (consoles, operators, CLIs) needs to display and verify the HA topology: how many coordinators exist, which one is the leader, and whether the standbys are alive. Today the only sources are out-of-band — ZooKeeper or the deployment platform (for example, Kubernetes pods) — which not every client can or should reach.

Solution

  1. Expose all registered coordinator servers with a role marker (leader/standby) through the client API — either by extending getServerNodes/MetadataResponse, or as part of the cluster-info API proposed in [rebalance] Change the implementation of Admin#getServerNodes() as introducing a new API to get cluster information #1389, or as a dedicated Admin#describeCoordinators().
  2. Include a liveness signal per coordinator (for example, presence in the election group), so a dead standby is distinguishable from a live one.

Related: #4105 needs a readiness signal that is valid for standby coordinators; a client-visible role/liveness API could serve that consumer too. The request handler's blanket rejection of all non-leader requests is already marked as provisional in a code comment (FlussRequestHandler) — serving this (read-only) call from a standby would be consistent with narrowing that check.

Anything else?

Affected areas: fluss-rpc (FlussApi.proto: metadata or a new describe message), fluss-server (CoordinatorService, election-group state), fluss-client (Admin).

Willingness to contribute

  • I'm willing to submit a PR!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions