Update iproto replication doc #4635
Conversation
| To register an anonymous replica in a replica set so that it's not anonymous anymore, | ||
| it must send an IPROTO_REGISTER request to any (TODO: or master?) node in the replica set: | ||
|
|
||
| TODO: request structure diagram |
There was a problem hiding this comment.
@bitgorbovsky @sergepetrenko please assist with TODOs:
- which instances can accept IPROTO_REGISTER?
- what is the request structure?
There was a problem hiding this comment.
The request should be sent to master (like JOIN).
REGISTER contains
MP_STR instance uuid of the sender
(optional) MP_STR instance name (this only applies to 3.0 docs)
MP_MAP vclock of the instance to be registered.
A response to REGISTER contains everything from a JOIN response that is not covered by FETCH_SNAPSHOT response
Basically, IPROTO_FETCH_SNAPSHOT + IPROTO_REGISTER are equivalent to IPROTO_JOIN.
IPROTO_FETCH_SNAPSHOT performs the "initial join" stage, where a stream of snapshot rows is sent to a replica, and IPROTO_REGISTER performs the "final join" stage, where the node is registered, and a follow-up stream of xlog contents is fed to the replica (until it receives a row with its own registration).
sergepetrenko
left a comment
sergepetrenko
left a comment
There was a problem hiding this comment.
Thanks for the patch!
| To register an anonymous replica in a replica set so that it's not anonymous anymore, | ||
| it must send an IPROTO_REGISTER request to any (TODO: or master?) node in the replica set: | ||
|
|
||
| TODO: request structure diagram |
There was a problem hiding this comment.
The request should be sent to master (like JOIN).
REGISTER contains
MP_STR instance uuid of the sender
(optional) MP_STR instance name (this only applies to 3.0 docs)
MP_MAP vclock of the instance to be registered.
A response to REGISTER contains everything from a JOIN response that is not covered by FETCH_SNAPSHOT response
Basically, IPROTO_FETCH_SNAPSHOT + IPROTO_REGISTER are equivalent to IPROTO_JOIN.
IPROTO_FETCH_SNAPSHOT performs the "initial join" stage, where a stream of snapshot rows is sent to a replica, and IPROTO_REGISTER performs the "final join" stage, where the node is registered, and a follow-up stream of xlog contents is fed to the replica (until it receives a row with its own registration).
sergepetrenko
left a comment
sergepetrenko
left a comment
There was a problem hiding this comment.
Thanks for the fixes!
LGTM.
|
|
||
| 6. The new vclock's MP_MAP in a response similar to the one above. | ||
|
|
||
| Then the instance closes the socket. |
There was a problem hiding this comment.
Соединение не закрывается, так как при поднятии репликации по тому же соединению потом посылаются запросы на SUBSCRIBE
There was a problem hiding this comment.
Спасибо, убрал это предложение из всех трёх описаний.
|
|
||
| #. The new vclock's MP_MAP. | ||
|
|
||
| Then the instance closes the socket. |
| :start-after: iproto_fetch_snapshot_response_sequence_start | ||
| :end-before: iproto_fetch_snapshot_response_sequence_end | ||
|
|
||
| Then the instance closes the socket. |
There was a problem hiding this comment.
Аналогичное замечание. Откуда вообще информация, что после каждого такое взаимодействия закрывается соединение?
Resolves #4495, #2275, #2276, #4011
Update Reference > Internals > Binary protocol > Replication requests and responses:
Note
These fixes are to be cherry-picked to 2.11 documentation. 3.x iproto replication updates will be made in a separate PR.
Deployment: https://docs.d.tarantool.io/en/doc/gh-4495-iproto-replication/reference/internals/iproto/replication/