# Raft Log Replication


![left](./student-guide/diagram/03-Raft–Log-replication-01-01.png)
------------------------------------------------------------
Below, we describe log replication:

When a client (for example TiDB Server) needs to write some data, it will send the operation to the Region of the Leader role. This is what we call the execution in TiKV, and the Leader will code the operation into an entry and write it into its own Raft Log, this process we call Append。

For Raft Log, we can simply understand its format like this. A TiKV will have multiple Regions, we will use the Region ID as the key prefix in the raft log, and then bring the Raft Log ID to uniquely identify a Raft Log. For example, if you now have two Region with IDs 4 and 5, the format of the 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 copy entries to other Followers via the Raft algorithm, which we call Replicate. After the follower receives this entry, the Append operation will be performed as well, and the Leader will be informed that the Append was successful (note: Append refers to writing the entry to its own Raft Log storage, not applying the entry).

When the Leader discovers that this entry has been appended by most nodes, he thinks that the entry is already committed, and then the operation in the entry can be decoded, executed and applied to the Data Persistent Storage Engine (State Machine), which we call Apply.