参赛日记day3-tidb性能竞赛-tikv/pd#2950

参赛日记day3-tidb性能竞赛-tikv/pd#2950git

在线版：https://www.processon.com/view/link/5f8d9cb9e401fd06fd941265github

changelog

2020/10/18 day7 继续补day3的参赛日记，把几个相关issue翻译成中文理解，有了DeepL减轻很大的翻译恐惧，DeepL翻译的像人话
2020/10/17 day6 继续补day3的参赛日记，准备翻译issue的，拖延了
2020/10/16 day5 补day3的参赛日记
2020/10/15 day4 没看
2020/10/14 day3 gaosong老师讲zoom讲了issue来源和思路

gaosong老师提议晚上zoom讲下这个issue需求的来源和思路，因此须要白天看完三篇文章。因此中午看下第三篇，按道理应该昨天看完的，毕竟文章不长。网络

建立分支

先建立仓库分支，不能搞了半天代码都没准备好。按照 community/high-performance-tidb-challenge-cn.md at master · pingcap/community ，须要以特定hash版本为开发起点，因此用“github 克隆指定hash”关键词搜到Git clone particular version of remote repository - Stack Overflow，因此下面是操做步骤：负载均衡

# fork https://github.com/tikv/pd.git
git clone https://github.com/eatcosmos/pd.git
cd ~/git/pd
git reset --hard c05ef6f95773941db5c1060174f5a62e8f864e88
git checkout -b dev
git push --set-upstream origin dev
git push
# git clone --single-branch --branch dev https://github.com/eatcosmos/pd.git
# git checkout dev

阅读文章

三篇文章了解 TiDB 技术内幕 - 谈调度 | PingCAP运维

请思考下面这些问题：性能

如何保证同一个 Region 的多个 Replica 分布在不一样的节点上？这个应该简单吧，标记不一样就行了吧。
更进一步，若是在一台机器上启动多个 TiKV 实例，会有什么问题？操做会冲突。
TiKV 集群进行跨机房部署用于容灾的时候，如何保证一个机房掉线，不会丢失 Raft Group 的多个 Replica？什么意思？
添加一个节点进入 TiKV 集群以后，如何将集群中其余节点上的数据搬过来? 直接拷贝吧，为何要搬，搬哪些？
当一个节点掉线时，会出现什么问题？整个集群须要作什么事情？若是节点只是短暂掉线（重启服务），那么如何处理？若是节点是长时间掉线（磁盘故障，数据所有丢失），须要如何处理？若是是leader replica掉线须要从新分配leader。万一replica group都掉线呢？
假设集群须要每一个 Raft Group 有 N 个副本，那么对于单个 Raft Group 来讲，Replica 数量可能会不够多（例如节点掉线，失去副本），也可能会过于多（例如掉线的节点又回复正常，自动加入集群）。那么如何调节 Replica 个数？设置个固定值吧。
读/写都是经过 Leader 进行，若是 Leader 只集中在少许节点上，会对集群有什么影响？会频繁切换leader。
并非全部的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，这个时候咱们须要作什么？须要配置索引。
集群在作负载均衡的时候，每每须要搬迁数据，这种数据的迁移会不会占用大量的网络带宽、磁盘 IO 以及 CPU？进而影响在线服务？怎么作负载均衡的？

先简单浏览下上面的问题，给大脑留一个映像，再看后面的，题目读不懂也没事。学习

感受PD就是运维，维护tikv节点。翻译

Store都已经下线了，PD怎么把上面的Region都调度走？code

信息->策略orm

一个 Raft Group 中的多个 Replica 不在同一个位置

这个没看明白，大概意思就是讲Region副本的位置。

副本在 Store 之间的分布均匀分配

Leader 数量在 Store 之间均匀分配

各个 Store 的存储空间占用大体相等

控制调度速度，避免影响在线服务

支持手动下线节点

调度的实现

总结

2020/10/16~2020/10/19 补全zoom会议笔记

issue背景

#2950 来自于 #19805，由于知识点太多，因此须要所有围绕这两个issue查找资料，不能扩散，还有就是affinity based range placement · Issue #19805 · pingcap/tidb和Supports co-balance range group · Issue #2950 · tikv/pd。翻译了 Supports co-balance range group #2950 · Issue #1 · eatcosmos/pd 翻译了 affinity based range placement #19805 · Issue #2 · eatcosmos/pd 翻译了 process cop request by tikv instance instead of region #19381 · Issue #3 · eatcosmos/pd

翻译了几个issue，好像懂了很多，其实啥都没懂，看来仍是要把高老师讲的复习下，学习就是不断输入信息，输入多了，会自动地联系起来就理解了。

绘制了一个流程图：

还有一些感受矛盾的地方，不要急着解决，放着问老师队友，或者多看几遍而后出去走走大脑会自动理解。

在线版：https://www.processon.com/view/link/5f8d89981e085307a095bfef