[
https://issues.apache.org/jira/browse/KUDU-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18075440#comment-18075440
]
Gabriella Lotz commented on KUDU-3731:
--------------------------------------
h2. Quiescing leader drain:
Setup: 1 master server, 3 tservers.
Flags:
{code:java}
--default_num_replicas=3 \
--auto_rebalancing_enabled=true \
--auto_rebalancing_interval_seconds=30 \
--auto_leader_rebalancing_enabled=true \
--auto_leader_rebalancing_interval_seconds=30 \{code}
Created user_events table (8 hash buckets, RF=3). tserver-0 (:9870) held 3
leaders. After quiesce start, leaders drained off tserver-0 within ~30s via
Raft leader step-down (idle cluster). After quiesce stop, leaders did not
return until the next leader rebalancer interval fired. 2 leaders were returned
(8 tablets, \{3, 3, 2} is balanced).
Note on previous "no action" observation:
auto_leader_rebalancing_interval_seconds was not set in the test alias and
defaulted to 3600s. Fixed by adding it explicitly to --master-flags.
Possible bug: At 14:40:22, while tserver-0 was still quiescing, the leader
rebalancer scheduled 2 leader transfers to tserver-0. Those transfers were
silently dropped by the Raft layer. The next rebalancer round (14:40:52, after
quiesce stop) succeeded.
Root cause: the master has no visibility into quiescing state.
TSHeartbeatRequestPB has no quiescing field, so TSDescriptor never learns about
it. The exclude_dest_uuids set in RunLeaderRebalancer() only excludes
MAINTENANCE_MODE servers. The same gap affects AvailableForPlacementUnlocked()
in ts_manager.cc, which is the central gate for all master-side placement
decisions.
> Long-running smoke test
> -----------------------
>
> Key: KUDU-3731
> URL: https://issues.apache.org/jira/browse/KUDU-3731
> Project: Kudu
> Issue Type: Sub-task
> Reporter: Gabriella Lotz
> Assignee: Gabriella Lotz
> Priority: Major
>
> h4. Step 0: Start a cluster with 1 master and 3 tablet servers.
> h4. Step 1: Set the following flags.
> --auto_rebalancing_enabled=true
> --auto_rebalancing_interval_seconds=60
> --auto_leader_rebalancing_enabled=true
> h4. Step 2: Create the following tables.
> {code:java}
> kudu table create <master> '{
> "table_name": "user_events",
> "schema": {
> "columns": [
> {"column_name": "user_id", "column_type": "STRING", "is_nullable":
> false},
> {"column_name": "event_id", "column_type": "INT64", "is_nullable":
> false},
> {"column_name": "data", "column_type": "STRING", "is_nullable":
> true}
> ],
> "key_column_names": ["user_id", "event_id"]
> },
> "partition": {
> "hash_partitions": [{"columns": ["user_id", "event_id"], "num_buckets":
> 8}]
> },
> "num_replicas": 3
> }'
> kudu table create <master> '{
> "table_name": "time_series_table",
> "schema": {
> "columns": [
> {"column_name": "ts", "column_type": "UNIXTIME_MICROS",
> "is_nullable": false},
> {"column_name": "sensor_id", "column_type": "STRING",
> "is_nullable": false},
> {"column_name": "value", "column_type": "DOUBLE",
> "is_nullable": true}
> ],
> "key_column_names": ["ts", "sensor_id"]
> },
> "partition": {
> "range_partition": {
> "columns": ["ts"],
> "range_bounds": [
> {"upper_bound": {"bound_type": "exclusive", "bound_values":
> ["1704067200000000"]}},
> {
> "lower_bound": {"bound_type": "inclusive", "bound_values":
> ["1704067200000000"]},
> "upper_bound": {"bound_type": "exclusive", "bound_values":
> ["1735689600000000"]}
> },
> {"lower_bound": {"bound_type": "inclusive", "bound_values":
> ["1735689600000000"]}}
> ]
> }
> },
> "num_replicas": 3
> }' {code}
> h4. Step 3: Start loadgen in tmux
> tmux new -s smoke
> Inside tmux:
> while true; do
> kudu perf loadgen <master> \
> --table_name=user_events \
> --num_threads=4 \
> --num_rows_per_thread=500000 \
> --flush_per_n_rows=1000 \
> --run_cleanup # cleanup so that disk doesn't fill up
> sleep 10
> done
> h4. Step 4: Monitor findings for 2 weeks. (start 2026.03.13.)
> # Is the cluster healthy?
> kudu cluster ksck <master>
> # Check whether auto-rebalancer is running.
> grep -i rebalanc /var/log/kudu/kudu-master.INFO | tail -20
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
