swuferhong opened a new issue, #3399: URL: https://github.com/apache/fluss/issues/3399
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Motivation During Kubernetes StatefulSet rolling upgrades, the next `TabletServer` pod should not restart until all replicas from the previously restarted pod have fully recovered (leaders re-elected, ISR restored). Without this, cascading restarts can cause data unavailability or prolonged under-replication. Currently there is no server-side API to determine whether the cluster has finished recovery. Operators rely on TCP-only readiness probes, which pass as soon as the process binds its port — long before replica recovery completes. ### Solution Add a `GetClusterHealth` RPC to the Coordinator that computes cluster health from in-memory state (CoordinatorContext). The API returns replica statistics and an overall health status: - **GREEN** — all replicas are in-sync and all leaders are active. - **YELLOW** — all leaders are active, but some replicas have not yet rejoined ISR. - **RED** — one or more leaders have not been confirmed active (election or KV recovery in progress). - **UNKNOWN** — health could not be determined. A readiness-probe shell script (`readiness-check.sh`) performs a two-step check: 1. TCP port check (local liveness) 2. Cluster Health API query (only pass on GREEN) This gates StatefulSet rolling upgrades: the next pod only restarts when the cluster is fully healthy. ### Anything else? _No response_ ### Willingness to contribute - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
