# `Raft` Log Replication

![`smart`](RaftLogReplication01_aa_002_20220511.png)

----------------------------------------------------------------------------
Below, we describe log replication:

When a client (e.g. TiDB server) needs to write some data, it will send the operation to the Leader role's Region, which in TiKV we call `Propose`.

The leader will encode the operation into an entry, and write it into its own Raft Log, which process we call `Append`.

We can simply understand the format of the Raft Log like this: a TiKV will have multiple Regions, and we will use the Region's ID as the prefix of the key, and then add the Raft Log ID to uniquely identify a Raft Log.
- For example, assuming there are two Regions, with IDs 4 and 5 respectively, then the format of Raft Log is as follows:

```
4_1, log { PUT key = 1, name = tom }
4_2, log { PUT key = 2, name = andy }
4_3, log { PUT key = 1, name = jack }
...
4_N, log { DEL key = 3 }
5_1, log { PUT key = 100, name = tim }
5_2, log { PUT key = 100, name = jim }
5_3, log { PUT key = 200, name = tony }
...
5_N, log { PUT key = 100, name = mark }
```

The leader will also replicate the entries to other followers through the Raft algorithm, which we call `Replicate`.

After receiving the entry, the Follower will also perform an `Append` operation, and will inform the Leader of success (`Append` refers to writing the entry into its own Raft Log, not applying the entry).

When the Leader finds that this entry has been `Append`ed by the majority of the nodes, it considers that this entry has already been committed, then it can decode the operations in the entry, execute and apply them to the data persistence storage engine, which we call `Apply`.