You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2016/09/03 01:58:20 UTC

[jira] [Updated] (KUDU-888) Consensus peers must specify and validate each others' UUIDs when communicating

     [ https://issues.apache.org/jira/browse/KUDU-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Percy updated KUDU-888:
----------------------------
    Description: 
Specifying and validating a remote peer's UUID during communication is required for correctness, because we assume that if a peer has forgotten or lost its durable consensus state then it has also forgotten or lost its UUID, so it will get a new one assigned. Violations of the consensus protocol can occur if a peer has amnesia, but if it refuses requests intended for a prior incarnation of itself then it should be possible to maintain safety.

See more discussion of this amnesia scenario in the remote bootstrap design doc, under "Failure of a disk with consensus metadata is a catastrophic failure": https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md

This also helps guard against bad misconfigurations, such as a tablet sending a DeleteTablet RPC message to itself when it thinks it is deleting a remote replica.

  was:
Specifying and validating a remote peer's UUID during communication is required for correctness, because we assume that if a peer has forgotten or lost its durable consensus state then it has also forgotten or lost its UUID, so it will get a new one assigned. Violations of the consensus protocol can occur if a peer has amnesia, but if it refuses requests intended for a prior incarnation of itself then it should be possible to maintain safety.

See more discussion of this amnesia scenario in the remote bootstrap design doc, under "Failure of a disk with consensus metadata is a catastrophic failure": https://docs.google.com/document/d/1zSibYnwPv9cFRnWn0ORyu2uCGB9Neb-EsF0M6AiMSEE/edit#heading=h.s6ennwonsuz8 

This also helps guard against bad misconfigurations, such as a tablet sending a DeleteTablet RPC message to itself when it thinks it is deleting a remote replica.


> Consensus peers must specify and validate each others' UUIDs when communicating
> -------------------------------------------------------------------------------
>
>                 Key: KUDU-888
>                 URL: https://issues.apache.org/jira/browse/KUDU-888
>             Project: Kudu
>          Issue Type: Bug
>          Components: consensus
>    Affects Versions: Public beta
>            Reporter: Mike Percy
>            Assignee: Mike Percy
>            Priority: Critical
>
> Specifying and validating a remote peer's UUID during communication is required for correctness, because we assume that if a peer has forgotten or lost its durable consensus state then it has also forgotten or lost its UUID, so it will get a new one assigned. Violations of the consensus protocol can occur if a peer has amnesia, but if it refuses requests intended for a prior incarnation of itself then it should be possible to maintain safety.
> See more discussion of this amnesia scenario in the remote bootstrap design doc, under "Failure of a disk with consensus metadata is a catastrophic failure": https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md
> This also helps guard against bad misconfigurations, such as a tablet sending a DeleteTablet RPC message to itself when it thinks it is deleting a remote replica.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)