0

Suppose we have only two nodes A and B.

When we issue these two commands on the node A,

$ curl -X PUT -d one .../v1/kv/key1
$ curl -X PUT -d two .../v1/kv/key2

(ie. PUT one key1 happens-before PUT two key2) and then GET of /v1/kv/key2 on the node B returned two, is it guaranteed that GET of /v1/kv/key1 on the node B returns one ? In other words, does Consul KVS honor happens-before relationship between the two writes on the node A?

Consul uses a consensus protocol to provide Consistency (as defined by CAP).

Yeah, but my understanding is the CAP theorem doesn't talk about multiple registers. These two writes may eventually propagate to the node B, but is it guaranteed we will never see an unexpected intermediate state?

nodakai
  • 7,773
  • 3
  • 30
  • 60
  • 1
    AFAIK Consul only has a single Raft log, so that ensures that writes will always be ordered among each other no matter the resource. One would have to go out of their way to make those writes unordered simply because of the nature of consensus. – kuujo Sep 14 '16 at 17:11
  • 1
    Not sure if needed for you, but consul 0.7 (which was just released) also has new transactional key/value api - https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#070-september-14-2016 – deniszh Sep 15 '16 at 11:38

1 Answers1

1

Consul claims linearizability. "All servers participate in the Raft consensus algorithm to ensure that transactions occur in a consistent, linearizable manner."

If the puts were synced in another order than they were received, you could see them out of order when reading from another node, violating the linearizability guarantee. Thus, they should always be observed in order.

However, since previous linearizability violations have been "solved" by decreasing a timeout value and then lying in marketing, claiming Jepsen never found any bugs, I wouldn't count on it being completely linearizable, at least for the next few years.

Filip Haglund
  • 13,919
  • 13
  • 64
  • 113