git-hulk opened a new pull request, #3543: URL: https://github.com/apache/kvrocks/pull/3543
### What does this PR do? Currently, while a slot migration is running, `CLUSTER INFO` only reports `migrating_slot(s)`, `destination_node`, and `migrating_state: start`. All progress details (key counters, sent bytes/batches, WAL catch-up) exist internally but are only written to server logs at the end of each phase, so operators have no way to observe an in-flight migration or estimate how far along it is. This PR exposes the detailed progress of the ongoing migration task via `CLUSTER INFO` while the migration state is `start`: ``` migrating_slot(s): 1 destination_node: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx01 migrating_state: start migrating_stage: snapshot migrating_elapsed_ms: 1202 migrating_keys_migrated: 0 migrating_keys_expired: 0 migrating_keys_empty: 0 migrating_sent_bytes: 1257196 migrating_sent_batches: 74 migrating_sent_entries: 3568 migrating_rate_kbps: 1021.98 migrating_wal_sequence_gap: 12 ``` - `migrating_stage`: the current stage of the state machine (`start`/`snapshot`/`wal`/`success`/`failed`/`clean`). - `migrating_keys_*`: snapshot key counters, only counted by the redis-command migration type. - `migrating_sent_bytes/batches/entries`: data sent to the destination node. For the redis-command type, a batch is a pipeline of commands and an entry is a command; for the raw-key-value type, a batch is an APPLYBATCH write batch and an entry is a write batch operation. - `migrating_wal_sequence_gap`: the distance between the latest sequence number and the WAL sequence the migration has caught up to, i.e. the pending incremental data. The existing fields are unchanged, and the new fields are only emitted while the task is ongoing, so existing tools polling `migrating_state` are unaffected. All counters are emitted in both migration types (zeros where a type doesn't use them) so that parsers don't need to be aware of the `migrate-type` config. This also makes `current_stage_` and `wal_begin_seq_` atomic since they are now read from other threads while the migration thread updates them (`current_stage_` was already read cross-thread by `Server::WaitNoMigrateProcessing`). ### Testing Added two integration tests that hold a migration in flight (via `migrate-speed` / `migrate-batch-rate-limit-mb`) and verify the progress counters go non-zero during the migration for both migration types, and that the fields disappear after the task finishes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
