Skip to content

RATIS-2599. Add design for listener delegation from followers#1513

Open
spacemonkd wants to merge 1 commit into
apache:masterfrom
spacemonkd:RATIS-2599
Open

RATIS-2599. Add design for listener delegation from followers#1513
spacemonkd wants to merge 1 commit into
apache:masterfrom
spacemonkd:RATIS-2599

Conversation

@spacemonkd

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Add design for listener delegation from followers

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/RATIS-2599

How was this patch tested?

N/A

@spacemonkd

Copy link
Copy Markdown
Contributor Author

@szetszwo could you take a look at the high level design document?
I can start working if it looks good to you

@szetszwo szetszwo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spacemonkd , thanks for working on this! Please see the comments inlined.

Comment on lines +54 to +55
│ │──appendEntries──► Listener1 │ │──heartbeat-only──► Listener1
│ │──appendEntries──► Listener2 │ │──heartbeat-only──► Listener2

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is good to have heartbeat directly from the leader 👍


### Key Invariants

1. **Leader authority:** The leader makes all delegation decisions. Followers do not self-elect to serve listeners.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a good start to have Leader making all delegation decisions.

Later on, we may let the Listener to select which follower to get appendEntries from.

BTW, use short lines for doc. It is easier to comment and make changes.

1. **Leader authority:** 
   The leader makes all delegation decisions.
   Followers do not self-elect to serve listeners.

Comment on lines +69 to +73
3. **Term safety:** Listeners validate that `leaderTerm >= currentTerm` in delegated entries. A deposed leader's follower will have a stale term, so listeners reject stale entries automatically.

4. **Log consistency:** The standard Raft log consistency check (`previousLog` matching) still runs on the listener side preventing any divergence regardless of the source.

5. **Full catch-up support:** The follower replicator can serve listeners from any `nextIndex` using its local log — not limited to near-real-time forwarding.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it the same as before? If yes, let's emphasize it as the "same as before".

Comment on lines +91 to +96
message ListenerProgressProto {
RaftPeerIdProto listenerId = 1;
uint64 matchIndex = 2;
uint64 nextIndex = 3;
uint64 commitIndex = 4;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may not be needed since the Leader heartbeat to the listeners. The listeners can reply to the Leader directly.

| `follower-lag-threshold` | `100` | Max entries a follower can lag behind leader and still be eligible |
| `reassignment-interval` | `30s` | How often the leader re-evaluates assignments |

### 3. Leader-side: Selection and Assignment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just change setConf to let the admin setting. They could set it according to the topology. Automatic selection may not be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants