Causal Consistency

Notes Requirements for consistencies Linearizability Global ordering Completion to Invocation globally Sequential Global ordering Completion to Invocation per client Causal Completion to invocation per client Write and then later read dependency Transitivity for 1) #Causal and 2) #Causal Fork-join Causal Eventual

Eventual Consistency

Notes Dynamo is similar to a Distributed Hash Table meaning it uses consistent hashing. Dynamo is called a zero-hop DHT because each node has enough information about the whole consistent hashing ring that it can directly transfer any client to the server responsible for serving that key. Causes for the system not being linearizable Initializing replication factor but not having the same number of writes/reads Membership changes Discovery of membership changes is at different times, due to gossip protocol, causing writes to happen at different servers than intended. When key exchanges are happening and data is being written to the old server. Vector Clock

MongoDB Replication

Notes Background Already existing scheme used db query for replication Replication scheme was in such a way that any follower could query any other follower Due to this when they tried to implement RAFT there was a mismatch between the architecture and algorithm. So they decided to change the algorithm to implement in existing architecture. Problem Querying will not give you the term number meaning you don’t know if you’re pulling from the leader or not and if the log entries are correct or not. Any other follower can pull from this stale follower. Solution Use updateposition RPC to get the term. Implementation Reading can be done by batching read requests with other requests. After lecture Look up TiDB What is mmap? Why fsync twice? TLA+ verification FLP Theorem (https://ilyasergey.net/CS6213/week-03-bft.html)