[
https://issues.apache.org/jira/browse/KUDU-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18067788#comment-18067788
]
Alexey Serbin edited comment on KUDU-3731 at 3/23/26 6:25 PM:
--------------------------------------------------------------
Thanks for putting together the description of the test setup. It look
reasonable to me, just a few notes:
* I'd think of simulating tablet servers going offline, so tablet replicas are
migrated from the downed tablet server elsewhere in the cluster (lowering the
value for the {{follower_unavailable_considered_failed_sec}} flag helps to
expedite the migration of the tablet replicas). After replicas have been
migrated from a downed tablet server, start it up and make sure the
auto-rebalancer eventually evens out the distribution of the tablet replicas.
* I'd also think of creating more ranges for the range-partitioned
{{time_series_table}} table and creating more replicas overall, and see how the
auto-rebalancer keeps up with many replicas being migrated upon tablet server
going down, to get an idea of how many runs/invocations it takes to bring the
cluster into a well-balanced state. Essentially, that's about assessing how
the current auto-rebalancing approach scales up with the size of the cluster:
should we expect to tweak any parameters related flags for larger Kudu clusters?
* One more scenario to test is to see how the auto-rebalancer behaves when
multiple tablet servers are down. Ideally, the auto-rebalancer should still
working and evening out the distribution of tablet replicas among still
available tablet servers unless the downed tablet servers are in the
maintenance mode.
* Also, double-check that the auto-rebalancer honors the quiescing and the
maintenance mode states for tablet servers.
was (Author: aserbin):
Thanks for putting together the description of the test setup. It look
reasonable to me, just a few notes:
* I'd think of simulating tablet servers going offline, so tablet replicas are
migrated from the downed tablet server elsewhere in the cluster (lowering the
value for the {{follower_unavailable_considered_failed_sec}} flag helps to
expedite the migration of the tablet replicas). After replicas have been
migrated from a downed tablet server, start it up and make sure the
auto-rebalancer eventually evens out the distribution of the tablet replicas.
* I'd also think of creating more ranges for the range-partitioned
{{time_series_table}} table and creating more replicas overall, and see how the
auto-rebalancer keeps up with many replicas being migrated upon tablet server
going down, to get an idea of how many runs/invocations it takes to bring the
cluster into a well-balanced state.
> 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)
