# Raft Log Replication
__*Raft Logs Replication*__
__*raft log*__
__*raft log*__
__*entry*__

![left](./student-guide/diagram/RaftLogReplication01_aa_001_20220511.png)

------------------------------------------------------------
Next, we describe log replication:

When a client (such as TiDB Server) needs to write some data, it will send the operation to the region of the Leader character. This is called in TiKV, and the Leader will encode the operation into an entry and write it into its own Raft Log. This process is called Append.

For raft logs, we can simply understand its format like this. A TiKV will have multiple Regions. We will use the ID of Region as the key prefix in the raft log, and then bring the Raft Log ID to uniquely identify a Raft Log. For example, if we now have two Regions with IDs 4 and 5, then 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. When the follower receives this entry, the Append operation will also be performed, and the Leader Append will be notified of success (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, it thinks that the entry is already committed, and then the operations in the entry can be decoded, executed, and applied to the Data Persistent Storage Engine (State Machine), which we call Apply.