ljluestc
commented
4 weeks ago # TiDB Configuration
server_configs:
log_level: "info"
read_only: false
# Other configurations...
# Raft Configuration
raft_store:
max_leader_lease: 3s
# Other raft configurations...
# Placement of Leader Nodes
pd:
leader_priority: "data_center_1"
# Define priority for leader placement
# Replication and Data Distribution
tikv:
storage:
max_background_jobs: 8
# Adjust background jobs based on your data center setup
when we deploy tidb in multi-datacenter case. it definitely provides the benefits of data disaster recovery. but it seems not able to promote write performance or read performance. according to raft protocol. all writes and reads from client was always proposed to the leader node. followers only receive log entries from leader. it means all clients wherever they are sends request to the leader node. if the raft leader is in datacenter A and some clients in datacenter B, the network latency between datacenter A and datacenter B definitely leads to write latency and read latency.
If we read from followers but write to the leader. the reads from followers maybe follows behind far from the reads from leader. and the write latency across different datacenter still exists. if we construct raft group separately for each datacenter, data-consistency couldn't be achieved among multi-datacenter. It seems impossible to achieve strong consistency and high write/read performance when we need multi-datacenter for the business all over the world.