请问各位大佬，为了负载均衡，TIKV会对region进行调度迁移，将region从高负载的节点迁移到低负载的节点，对于leader角色的region，如何保证region leader迁移前后的数据一致性呢，因此在调度的过程中原节点还会接收到写入请求，会在调度过程中会禁止对应的数据写入嘛。
也就是一个拥有写入能力的region在从一个高负载节点迁移到低负载节点的时候，怎么做到不停止写入的情况下同时保证迁移前后的数据一致性
在 TiKV 中，当进行 region leader 的调度时，TiKV 会确保在调度前后的数据一致性。TiKV 使用了一种称为 “Raft 协议” 的一致性算法来保证数据的一致性。
在 Raft 协议中，每个 Region 都有一个 Leader 节点，负责处理读写请求。当进行 region leader 的调度时，TiKV 会先将新的 Leader 节点选举出来，然后进行数据的复制和同步，以确保新的 Leader 节点拥有最新的数据。
具体来说，当进行 region leader 的调度时，TiKV 会执行以下步骤来保证数据的一致性：
-
选举新的 Leader：TiKV 会根据 Raft 协议的规则，在集群中选举出一个新的 Leader 节点来接管该 Region。
-
数据复制和同步：新的 Leader 节点会与其他节点进行数据的复制和同步，以确保新的 Leader 节点拥有最新的数据。这个过程中，TiKV 会使用 Raft 协议中的日志复制机制，将数据从旧的 Leader 节点复制到新的 Leader 节点。
在这个过程中，TiKV 会确保数据的一致性，并且不会禁止对应的数据写入。即使在 region leader 的调度过程中，仍然可以对数据进行写入操作。这是因为 Raft 协议能够保证在 Leader 节点切换的过程中，数据的一致性和可用性。
我说的这个leader调度 和 leader选举是两个意思， 我说的leader调度是负载均衡的那个调度
那你可能要把问题描述清楚一下~
好滴 我重新编辑一下
重新编辑好啦
tidb本来就是默认3副本，一般来说3个副本都是一致的，所以leader切换到其他副本很快影响很小
1 个赞
感谢大佬回复，我想讨论的不是leader选举切换，而是一个拥有写入能力的region在从一个高负载节点迁移到低负载节点的时候，怎么做到不停止写入的情况下同时保证迁移前后的数据一致性
应该也是通过tso来控制的不同的版本和事务
1 个赞
大佬，能大概展开说下嘛
有大佬知道嘛 帖子要沉了嘛 
raft log
大佬能展开说说嘛
https://docs.pingcap.com/zh/tidb/v6.1/high-concurrency-best-practices
写region也是先写raft log日志，你可以看下这个文档，高并发写入，调度和选举肯定分不开的，pd-ctl里也有控制调度的参数，可以看看
感谢大佬回复，这篇文档还是没解决我的疑问，文章写的比较笼统，只说了通过split把region拆开，具体怎么调度并保持数据一致性的没有细说
看看这个
1 个赞
因此在调度的过程中原节点还会接收到写入请求，会在调度过程中会禁止对应的数据写入嘛。这个不会禁止写入，因为是写日志的，先写raft log日志，后面region应用日志，和region调度要分开看。数据并不是直接写入region。
没太明白《后面Region应用日志》 是什么意思，是调度后的region是调度前的region的一个Follower嘛？
大佬，我对TIKV的代码不太熟，读了几遍，感觉下来是 每次leader region调度 是在目标Store上先add一个follower状态的peer，然后同步数据，然后将这个peer弄成新leader，接着将老leader给remove掉是嘛，请大佬批评指正！
大概过程就是，先切换到其他负载低的 follow上，先接管leader；之后会在找个负载低的服务器，创建个副本，raft 同步好后，把最开始高负载的副本删除。大概就这个过程