[kudu-CR] [RaftPeerPB] introduce replica health status
Alexey Serbin has uploaded this change for review. ( http://gerrit.cloudera.org:8080/8561 Change subject: [RaftPeerPB] introduce replica health status .. [RaftPeerPB] introduce replica health status Introduced replica health status. The health status is a non-persistent optional field in RaftPeerPB which is set by leader replica. This commit introduces a single change in the RaftPeerPB protobuf message. It provides necessary interface to start working on the new scheme of automatic replacement of tablet replicas, so it would be possible to work in parallel in accordance with the v1 implementation plan. Change-Id: Id82f838fd3612ab9bc3f91cac7a840cb9f36ff4c --- M src/kudu/consensus/metadata.proto 1 file changed, 12 insertions(+), 0 deletions(-) git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/61/8561/1 -- To view, visit http://gerrit.cloudera.org:8080/8561 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: newchange Gerrit-Change-Id: Id82f838fd3612ab9bc3f91cac7a840cb9f36ff4c Gerrit-Change-Number: 8561 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin
[kudu-CR] [RaftPeerPB] introduce replica health status
Todd Lipcon has posted comments on this change. ( http://gerrit.cloudera.org:8080/8561 ) Change subject: [RaftPeerPB] introduce replica health status .. Patch Set 1: (1 comment) http://gerrit.cloudera.org:8080/#/c/8561/1/src/kudu/consensus/metadata.proto File src/kudu/consensus/metadata.proto: http://gerrit.cloudera.org:8080/#/c/8561/1/src/kudu/consensus/metadata.proto@75 PS1, Line 75: This is run-time : // only field, it should not be persisted or read from the persistent storage. is this true even on the master? or would we expect the master to persist it? if the master doesn't persist it somehow, and the master fails over, how does the new master not get super confused about what's going on with the "extra" replicas? -- To view, visit http://gerrit.cloudera.org:8080/8561 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Id82f838fd3612ab9bc3f91cac7a840cb9f36ff4c Gerrit-Change-Number: 8561 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy Gerrit-Reviewer: Todd Lipcon Gerrit-Comment-Date: Thu, 16 Nov 2017 01:30:32 + Gerrit-HasComments: Yes
[kudu-CR] [RaftPeerPB] introduce replica health status
Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/8561 ) Change subject: [RaftPeerPB] introduce replica health status .. Patch Set 1: (1 comment) http://gerrit.cloudera.org:8080/#/c/8561/1/src/kudu/consensus/metadata.proto File src/kudu/consensus/metadata.proto: http://gerrit.cloudera.org:8080/#/c/8561/1/src/kudu/consensus/metadata.proto@75 PS1, Line 75: This is run-time : // only field, it should not be persisted or read from the persistent storage. > is this true even on the master? or would we expect the master to persist i Ah, I see -- it seems I missed the PROMOTE and REPLACE attributes. I'll add them for the complete picture, sure. By my understanding, master does not need to persist the health status. Overall, it's not necessary to know the previous state of the health status of a replica, it's enough to see what current status is. Do you have some use case in mind when master would get super-confused with 'extra' replicas? If the leader master changes, master is about to receive non-incremental report on all tablets in the system. -- To view, visit http://gerrit.cloudera.org:8080/8561 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Id82f838fd3612ab9bc3f91cac7a840cb9f36ff4c Gerrit-Change-Number: 8561 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin Gerrit-Reviewer: Alexey Serbin Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy Gerrit-Reviewer: Todd Lipcon Gerrit-Comment-Date: Thu, 16 Nov 2017 01:45:57 + Gerrit-HasComments: Yes
