case 1
当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。
- 30分钟是否可调？ 配置中max-store-down-time设置
- 怎么判断失效的？ 每个tikv会定期给pd汇报节点信息，一个tikv region group中的leader也会汇报group信息。pd不断通过这两种信息判断。
- 误判会导致什么后果？当disable-remove-extra-replica设置为true时,会补充多余的副本。
补充：并不应该是迁移，而是pd会在其他节点补充副本。
case 2
测试官方跨数据中心部署方案的各种场景：
1、三中心部署方案
所有数据的副本分布在三个数据中心，任何一个数据中心失效后，另外两个数据中心会自动发起 leader election，并在合理长的时间内（通常情况 20s 以内）恢复服务，并且不会产生数据丢失。
避免网络抖动带来的重新选举就是依靠20s超时吗？能否配置？
是指20s内恢复服务，无法配置。
对于写入的场景，所有写入的数据需要同步复制到至少 2 个数据中心，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要 2 倍数据中心间的延迟。
对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个数据中心，也会受网络延迟影响。
TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个数据中心时，它上面运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。
在陌陌同城机房的场景下，以上延迟具体多少？
2、三中心+读性能优化
如果不需要每个数据中心同时对外提供服务，可以将业务流量全部派发到一个数据中心，并通过调度策略把 Region leader 和 PD leader 都迁移到同一个数据中心（我们在上文所述的测试中也做了这个优化）。这样一来，不管是从 PD 获取 TSO 还是读取 Region 都不受数据中心间网络的影响。当该数据中心失效后，PD leader 和 Region leader 会自动在其它数据中心选出，只需要把业务流量转移至其他存活的数据中心即可。
调度策略是自动的吗？PD能干预选举？
pd能根据配置变更tikv，pd成员身份。
同时也会根据tikv上报的信息，增加或者减少replica。
调度策略可以配置，比如 https://pingcap.com/docs-cn/v2.1/op-guide/location-awareness/#pd-%E7%90%86%E8%A7%A3-tikv-%E6%8B%93%E6%89%91%E7%BB%93%E6%9E%84
支持”PD会优先把每一份数据的不同副本调度到不同的数据中心“这种调度策略。
官方文档里没说一开始承载读的数据中心挂了之后的leader分布情况，如果leader随机在另外两个数据中心里产生，那又回到了跨机房读的场景。我们能不能尝试做到这个优化：“2线上/冷备互切中心+1冷备中心+读集中在一个中心”？
例如，m6，rw和dx各部署1个TiKV和PD，读写一开始都在m6。配置调度策略，使得m6挂了，leader全在rw。rw和m6线上冷备互切，dx只做冷备+辅助选举。
实现：
pd 使用pd-ctl member leader_priority这个命令设优先级，raft根据这个优先级可以对成员进行变更。
kv 配置，使得某些节点不会成为leader。
[label-property]
Do not assign region leaders to stores that have these tags.
[[label-property.reject-leader]]
key = "zone"
value = "cn1
case 3
1. tikv扩容缩容
1.新增一个tikv不会立即平均分配数据。
通过pd-ctl新增tikv是pd的主动行为，因为什么原因导致不会立即分配数据？
2. tikv异常下线
2.杀掉超过最少可提供服务的tikv,tidb会崩溃。
3.杀掉其中一个 tikv，会有10s左右读取不到数据。
针对2，tidb不提供服务即可，为什么会导致崩溃。
3. tikv掉线节点恢复
是否自动加入集群，是否会造成Replica过多？
case 4
tidb
- 增加tide，业务无感知，增加成功之后，可以立即使用。但是如果你直接删除你访问的那个节点。
- 节点退出或者崩溃，tidb是无状态服务，也就是说能直接添加或者删除tidb。
由于tidb是无状态的，测试中无需过多关注。如何实现无状态？其实是否又有需要注意的点，延时？
case 5
1. pd扩容缩容
1.通过pd-server增加pd，超过一定数目pd。新增pd在pd集群不可见，并需滚动升级整个集群。
2.通过pd-ctl主动删除pd，滚动升级，集群故障数次。
针对1.2是否由于tidb整个通信机制导致tikv,tidb无法获取pd更新信息。导致pd扩容缩容之后，必须通过重启更新tikv,tidb？
针对1，pd存在n个replica时。如何配置于与代码，调试replica数目。避免过多新增。
针对2，需要增加删除pd leader和pd replica测试。
以及pd重启之后，如何选择自己最大的epoch。
2. pd性能测试
pd做为调度，应该在一开始就规划好。没有必要也无需在线上做缩容扩容。应该更关注pd的性能。
增加pd新能测试。
3. pd异常下线
kill一个pd，从节点无感知。主节点会断开链接。
如果kill 是两个pd从节点不影响线上正常业务
如果其中一个节点是主节点，则程序将会退出,需要在次发起连接。
测试除了业务，应该关注tikv,tipd是否会向kill 掉的pd发送信息，以及后续集群恢复该怎么处理。
集群如何，才是真正的恢复正常。
case 6
集群在做负载均衡的时候，数据迁移会不会造成带宽，磁盘io以及cpu的问题？进而影响服务？
参考测试文档：
https://docs.google.com/document/d/1FB_uTaj-m7il1Y3ZXlVFsV2W_tx2hHS0zwfUnY40vkw/edit#
文档会继续更新
网友评论