-
Notifications
You must be signed in to change notification settings - Fork 59
feat(bulk-load): group bulk load request in replica group #460
Conversation
for (const auto &kv : _primary_states.group_bulk_load_pending_replies) { | ||
kv.second->cancel(true); | ||
} | ||
_primary_states.group_bulk_load_pending_replies.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it mean we will resend group_bulk_load_request to sendaries? How does secondary replica deal with duplicate bulk load request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- meta -> primary: send bulk _load_request
- primary -> secondary: send group_bulk_load_request (request 1)
- secondary -> primary : report bulk load state
- primary -> meta: report group bulk load states
- if bulk load not finished, meta send bulk_load_request again
- primary -> secondary: send group_bulk_load_request (request 2)
Primary will not resend group_bulk_load_request, request 1 and request 2 are different.
When primary tries to send request 2, primary will check if there are request 1 pending firstly, if there are pending request 1, primary will cancel tasks and send request 2.
Meta server will not send bulk_load_request too soon, the interval is longer than 5 seconds (will be shown in further pull request), it is safe to cancel the long-time, pending request.
This pull request is about primary broadcast group_bulk_load_request to secondaries.
on_bulk_load
feat(bulk-load): meta server send bulk load request #457)broadcast_group_bulk_load
)on_group_bulk_load
when receive group_bulk_load_requeston_group_bulk_load_reply
when receive group_bulk_load_response, part-implemented in this prWhole bulk load process document can be found in official website: bulk_load_design