在线写作网站,如何卸载和重装wordpress,开发运营一个app大概需要多少钱,想学做电商怎么入手目录
一 PD的架构与功能
PD架构
PD作用
名词解释
路由功能
二 TSO的分配
概念
分配过程
性能问题
高可用问题
三 PD的调度原理
总流程
1 信息收集 2 生成调度
3 执行调度
四 Label的作用
Label的配置
给TiKV打标签
PD配置 一 PD的架构与功能
PD架构 PD集群…目录
一 PD的架构与功能
PD架构
PD作用
名词解释
路由功能
二 TSO的分配
概念
分配过程
性能问题
高可用问题
三 PD的调度原理
总流程
1 信息收集 2 生成调度
3 执行调度
四 Label的作用
Label的配置
给TiKV打标签
PD配置 一 PD的架构与功能
PD架构 PD集群至少由三个节点构成PD通过集成了etcd支持自动故障转移PD 通过etcd的raft保障数据的强一致性所以在生产中建议奇数个。PD中会有leader角色其实是个单点只有在发生故障的时候才会发生选举。PD是TiDB数据库的总控是整个集群的大脑
PD作用 1 元数据的存储tidb的执行计划或者SQL语句他怎么知道去哪个Region中找到相应的数据哪个region存储在哪个TiKV中
2 全局时钟 查询开始事务开始结束的时间都是由PD授时
3 对Region进行调度例如某些TiKV的Region较多产生了热点需要向其他TiKV进行调度
名词解释 Store :对应TiKV 实例同一个服务器上部署多个TiKV则这个服务器上有多个store。
Region每个Region负责存储集群一段连续的数据默认96M.没份数据会在不同的TIKV存储多个副本默认是3副本每个副本叫peer,peer是有角色的peer也特指raft中的成员
leader :读写都在leader上
follower:
raft Group :通过raft协议构成raft Group
multi Raft: 多个raft组构成multi Raft
以上就是PD需要管理的重要的一些概念
路由功能 路由功能执行SQL的时候 SQL想要读取的数据所在的Leader Region在哪个TiKV上是需要问PD的。TiDB server生成执行计划传到Executor 执行器然后执行器去执行执行计划例如此时需要读取key123存储在region1 上的数据TIKV Client 就是会去PD中问PD 告诉这个Key的位置。
如果每次查询都要去PD中查询region的位置难免会产生很多的网络开销网络压力太大了就会把key123的位置从PD中取出来然后缓存在TiKV Client的 Region Cache中。下次再读取就不用从PD中读取。但是这种方法虽然节约了网络开销但如果key123数据所在的Region发生了漂移此时按cache中的位置去读就会找不到数据需要重新从PD中取出来 这种现象叫做 Back Off。back off 越多读取的延迟越多。或者Region分裂Leader的信息过旧等都会产生BackOff 二 TSO的分配
概念
需要为大量的事务提供TSO事务都是并发的
保证TSO单调递增
TSO physical time logical time 是一个int64的整型数时钟精确到毫秒logical time 1ms分成 262144个TSO 这个可以满足大多数场景的使用了
分配过程 为我们提供服务的只是PD集群的中的Leader 角色。
谁会请求TSO SQL事务等。
TSO 请求者 请求TSO 并不是直接发送到PD而是到 PD client 。PD client 可以认为是 TiDB Server 和 PD 集群交互的中间代理模块。
性能问题 如果SQL并发很高 所以有一个优化 PD client 会有一个批处理会把100个SQL请求TSO的组合整一个请求去PD中获取TSO。
无论是批处理还是申请一次都需要进行一次持久化会产生磁盘IO并发越高 磁盘IO越大。如何处理了这个问题
将一段TSO放到缓存中 磁盘IO 变为3秒一次
高可用问题
当我的PD leader挂了怎么办
保证不了连续性 但是可以保证增长性 三 PD的调度原理
总流程 1 信息收集
TiKV Server 会周期性的向PD汇报心跳信息里面包含Store Heartbeat (TiKV 本身的心跳信息 包括 容量剩余空间读写流量等通过这些信息大概可以知道TiKV的繁忙程度)和 Region Heartbeat 每个Region都会向PD汇报 比如副本的分布状态 读写流量这样就可以知道Region的繁忙程度 以及 Region在TiKV的分布是否均匀所以PD是通过心跳的信息收集获取这些信息 2 生成调度
根据收集到的信息 生成Operator 均衡读写均衡 存储均衡热点均衡集群拓扑缩容故障恢复 Region merge 3 执行调度
将这些调度发送给region然后执行这些调度 四 Label的作用 DC 数据中心
Rock 机柜
TIKV 服务器
看上面的图 发现不同的region分布对可用性是有影响的比如上图中的Rock 4机柜损坏后region1的两个副本不可用。
region不可用这么可怕吗是的 比如某个region中存储了集群的元数据信息 information_schema用户密码等导致整个数据库不可用。
默认region是随机分布PD只能保证同一个TiKV节点上不会有同一个region的两个Peer,但是不能保证region的分布。那如如何让region按自己的意愿分配呢
通过打标签为每个TiKV 实例设置一个标签 Label,用于表示这个TiKV在哪个机房哪个机柜哪个服务器上这样PD 就会按照标签约定好的方式将Region分布到不同DC、不同机柜、不同的TiKV上。实际上我的标签是为了让PD 去感知集群的拓扑结构的。
Label的配置 Label的配置是要在两个组件上进行配置
给TiKV打标签
server.lables:{zone:1,rack:1,host:1}
zone代表DC 数据中心 rack 代表机柜 host代表服务器
PD配置
location-labels [zone,rack,host]
[replication]
isolation-levelzone
隔离级别设置 zone,rack,host代表副本的分布
