@Rocky If the StarRocks FE Leader is restarted, one of the Followers should be elected as the new Leader. During this failover, are there any side effects or temporary disruptions to read or write operations?

When a StarRocks FE Leader is restarted, a new Leader is automatically elected from the remaining Followers. While this process is designed for high availability, there are several temporary disruptions and side effects to be aware of: 1. Disruption to Write Operations Write operations (such as DDL statements,

INSERT

into tables, or starting new Load jobs) will fail temporarily during the election period. * Reason: Only the Leader FE can process metadata changes and coordinate writes. * Duration: The disruption typically lasts only a few seconds while the BDBJE (Berkeley DB Java Edition) election completes and a new Leader is promoted. * Error: Clients may receive errors such as

UnknownMasterException

or connection timeouts until the new Leader is ready. 2. Disruption to Read Operations The impact on reads depends on how the client is connected to the cluster: * Direct Connection to the Leader: If the client is connected directly to the FE node being restarted, the connection will be severed immediately, and the query will fail. * Connections to Followers/Observers: * By default, Follower and Observer nodes can continue to serve read-only queries. * However, if the election takes longer than expected, non-leader FEs may stop providing services to prevent stale reads. This is governed by the

meta_delay_toleration_second

parameter (default 300 seconds). * If

ignore_meta_check

is set to

false

(default), there may be a very brief window during the leader transition where the entire FE group pauses service to ensure consistency. 3. Connection Handling * Client Retries: Applications should be configured to retry operations. Most StarRocks drivers or MySQL clients will need to re-establish a connection if the specific FE they were talking to went down. * Load Balancing: It is strongly recommended to use a load balancer (like HAProxy, Nginx, or a cloud LB) in front of your FE nodes. A load balancer can automatically route traffic away from the restarting node and toward the remaining Followers/Observers. Summary of Side Effects Operation Type | Impact during Failover Writes/DDL | Unavailable until a new Leader is elected (seconds). Reads (on Leader) | **Connection dropped**; must reconnect to a different FE. Reads (on Followers) | Usually available, but may experience a brief pause. Metadata | No data is lost; metadata is synchronized via BDBJE. To minimize impact, ensure you have at least 3 Follower FEs to maintain a quorum and use a load balancer to manage client connections. References • faq/operation_maintenance_faq.md • administration/Meta_recovery.md • administration/management/FE_configuration.md • deployment/deploy_manually.md