PACIFIAA Reading notes

Pacifica is a consistent agreement developed by Microsoft Research, and Kafka is said to be inspired by this article as a reading note. Architecture

Pacifica, as a consistency protocol, differs from traditional consistency (Paxos, raft) in that it focuses on the consistency of a log-based storage system, unlike a protocol that Paxos only focuses on agreeing on a value. The machines in the Pacifica have 2 roles: Configuration Manager, Data Server. In Pacifica, the data exists in the database server, logically speaking, there are replication group. Each data server can have multiple replication group, with 1 leader and multiple slave in each replication group, scattered across different data servers. This data server is solely responsible for storing and copying the information, and each replication group's leader election is given to Configuration Manager. Replication of data

The leader in each replication group processes the update and read requests and translates the update request into a log sent to slave. Unlike Paxos, Pacifica requires that the log be written to local by all slave to be counted as a commit. So what if there is a node that partion or hangs out. Here we use an example to illustrate the security of Pacifica.

We assume that a replication group has a, B, c three nodes, where a is the leader of Version=1. The lease mechanism is used in Pacifica to failure detection. When c occurs partition, a will send a request to Configuration Manager to modify the configuration of this replication group to a, B, and version 2;c will also send a request to modify the configuration of this replication group C , the version is 2. No matter which of the 2 requests come first, Configuration manager approves only one and rejects the other. At any one time still there is still only one leader for each replication group, so writing is still safe. This we assume that a's configuration modification succeeds, then C should be how to deal with it. The original text is not detailed in this case, this should be determined by the implementation, for example, C can try to join the original group for a certain time, if still fail to automatically exit and so on.

Another guarantee of security is that if at least one node in the replication group survives, the committed message must be preserved. This is guaranteed by the synchronization algorithm, that is, when the new leader election, the first thing to do is to let all the slave synchronous leader their own local log, and this must contain the log has been committed, so it is well understood. Some optimizations typically log-based systems maintain a state machine locally and do checkpoint at regular intervals to truncate older logs. The state of the update state machine needs to consume CPU and memory, so an optimization is to not maintain the state machine in slave, but only accept the log, and periodically accept checkpoint. Consolidating multiple logical logs into a single physical log file, reducing the number of files, and reducing disk random reads and writes can be stored in a shared file system like BigTable, which has the advantage of simplifying system logic, but the downside is that it complicates the logic of system recovery, because when a machine hangs, Multiple replication group on this machine will be dispersed to different machines, and if a 2 optimization strategy is adopted, it will cause multiple machines to read the same log.