kaijchen commented on PR #808:
URL: https://github.com/apache/ratis/pull/808#issuecomment-1430674627
> * Then, we don't need a new command.
The old server (prior to 2.4.1) always requires the transferee to have the
highest priority for transfer leadership.
We are keeping the old `transfer` command for backward compatibility. Is
there a way to get the server version?
> * Since we already have the `getRaftGroup()` returned from the server, we
can check priorities to decide whether to call `setConfiguration`. It will
call `setConfiguration` only if the transferee has smaller priority.
Personally I prefer to print a message like "transferee does not have
highest priority, please call `setPriority` first".
Or add a `-force` option, to set the transferee to highest priority.
## Example
let's say we have a cluster like this,
| Peer | A | B | C | D | E |
| --- | --- | --- | --- | --- | --- |
| Priority | 3 | 2 | 2 | 1 | 1 |
### New server
If we want to transfer leader from A to E, we should only raise E's priority
to highest.
So if peer E is down afterwards, the old priority remains.
| Peer | A | B | C | D | E |
| --- | --- | --- | --- | --- | --- |
| Priority | 3 | 2 | 2 | 1 | 3 |
### Old server
Since the old server requires transferee to be the **only** peer with
highest priority.
The best we can do is:
| Peer | A | B | C | D | E |
| --- | --- | --- | --- | --- | --- |
| Priority | 3 | 2 | 2 | 1 | 4 |
However, the old command will reset every node's priority, and the old
priority is erased.
| Peer | A | B | C | D | E |
| --- | --- | --- | --- | --- | --- |
| Priority | 1 | 1 | 1 | 1 | 2 |
--
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]
