东平县建设局网站,简述网页设计的流程,广州网站建设设计厂家,域名备案需要有网站吗一. TiDB的核心特性 高度兼容 MySQL 大多数情况下#xff0c;无需修改代码即可从 MySQL 轻松迁移至 TiDB#xff0c;分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展#xff0c;按需扩展吞吐或存储无需修改代码即可从 MySQL 轻松迁移至 TiDB分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。 水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展按需扩展吞吐或存储轻松应对高并发、海量数据场景。 分布式事务 TiDB 100% 支持标准的 ACID 事务。 高可用 相比于传统主从 (M-S) 复制方案基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证且在不丢失大多数副本的前提下可以实现故障的自动恢复 (auto-failover)无需人工介入。 一站式 HTAP 解决方案 TiDB 作为典型的 OLTP 行存数据库同时兼具强大的 OLAP 性能配合 TiSpark可提供一站式 HTAP 解决方案一份存储同时处理 OLTP OLAP无需传统繁琐的 ETL 过程。 云原生 SQL 数据库 TiDB 是为云而设计的数据库同 Kubernetes 深度耦合支持公有云、私有云和混合云使部署、配置和维护变得十分简单。 二.TiDB 整体架构 TiDB Server TiDB Server 负责接收SQL请求处理SQL相关的逻辑并通过PD找到存储计算所需数据的TiKV地址与TiKV交互获取数据最终返回结果。TiDB Server 是无状态的其本身并不存储数据只负责计算可以无限水平扩展可以通过负载均衡组件LVS、HAProxy或F5对外提供统一的接入地址。 PD Server Placement Driver简称PD是整个集群的管理模块其主要工作有三个一是存储集群的元信息某个Key存储在那个TiKV节点二是对TiKV集群进行调度和负载均衡如数据的迁移、Raft group leader的迁移等三是分配全局唯一且递增的事务ID。 PD 是一个集群需要部署奇数个节点一般线上推荐至少部署3个节点。PD在选举的过程中无法对外提供服务这个时间大约是3秒。 TiKV Server TiKV Server 负责存储数据从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region每个Region负责存储一个Key Range从StartKey到EndKey的左闭右开区间的数据每个TiKV节点会负责多个Region。TiKV使用Raft协议做复制保持数据的一致性和容灾。副本以Region为单位进行管理不同节点上的多个Region构成一个Raft Group互为副本。数据在多个TiKV之间的负载均衡由PD调度这里也就是以Region为单位进行调度 三. 存储结构 一个 Region 的多个 Replica 会保存在不同的节点上构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader其他的 Replica 作为 Follower。所有的读和写都是通过 Leader 进行再由 Leader 复制给 Follower。 Key-Value 模型 TiDB对每个表分配一个TableID每一个索引都会分配一个IndexID每一行分配一个RowID(如果表有整形的Primary Key那么会用Primary Key的值当做RowID)其中TableID在整个集群内唯一IndexID/RowID 在表内唯一这些ID都是int64类型。每行数据按照如下规则进行编码成Key-Value pair Key tablePrefix_rowPrefix_tableID_rowID Value: [col1, col2, col3, col4] 其中Key的tablePrefix/rowPrefix都是特定的字符串常量用于在KV空间内区分其他数据。对于Index数据会按照如下规则编码成Key-Value pair Key: tablePrefix_idxPrefix_tableID_indexID_indexColumnsValue Value: rowID Index 数据还需要考虑Unique Index 和 非 Unique Index两种情况对于Unique Index,可以按照上述编码规则。但是对于非Unique Index通常这种编码并不能构造出唯一的Key因为同一个Index的tablePrefix_idxPrefix_tableID_indexID_都一样可能有多行数据的ColumnsValue都是一样的所以对于非Unique Index的编码做了一点调整 Key: tablePrefix_idxPrefix_tableID_indexID_ColumnsValue_rowID Valuenull 这样能够对索引中的每行数据构造出唯一的Key。注意上述编码规则中的Key里面的各种xxPrefix都是字符串常量作用都是用来区分命名空间以免不同类型的数据之间互相冲突定义如下 var( tablePrefix []byte{t} recordPrefixSep []byte(_r) indexPrefixSep []byte(_i) ) 举个简单的例子假设表中有3行数据 1,“TiDB”, “SQL Layer”, 10 2,“TiKV”, “KV Engine”, 20 3,“PD”, “Manager”, 30 那么首先每行数据都会映射为一个Key-Value pair注意这个表有一个Int类型的Primary Key所以RowID的值即为这个Primary Key的值。假设这个表的Table ID 为10其中Row的数据为 t_r_10_1 -- [TiDB, SQL Layer, 10] t_r_10_2 -- [TiKV, KV Engine, 20] t_r_10_3 -- [PD, Manager, 30] 除了Primary Key之外这个表还有一个Index假设这个Index的ID为1其数据为 t_i_10_1_10_1 -- null t_i_10_1_20_2 -- null t_i_10_1_30_3 -- null Database/Table 都有元信息也就是其定义以及各项属性这些信息也需要持久化我们也将这些信息存储在TiKV中。每个Database/Table都被分配了一个唯一的ID这个ID作为唯一标识并且在编码为Key-Value时这个ID都会编码到Key中再加上m_前缀。这样可以构造出一个KeyValue中存储的是序列化后的元数据。除此之外还有一个专门的Key-Value存储当前Schema信息的版本。TiDB使用Google F1的Online Schema变更算法有一个后台线程在不断的检查TiKV上面存储的Schema版本是否发生变化并且保证在一定时间内一定能够获取版本的变化如果确实发生了变化。 四. SQL 运算 用户的 SQL 请求会直接或者通过 Load Balancer 发送到 tidb-servertidb-server 会解析 MySQL Protocol Packet获取请求内容然后做语法解析、查询计划制定和优化、执行查询计划获取和处理数据。数据全部存储在 TiKV 集群中所以在这个过程中 tidb-server 需要和 tikv-server 交互获取数据。最后 tidb-server 需要将查询结果返回给用户。 五. 调 度 调度的流程 PD 不断的通过 Store 或者 Leader 的心跳包收集信息获得整个集群的详细数据并且根据这些信息以及调度策略生成调度操作序列每次收到 Region Leader 发来的心跳包时PD 都会检查是否有对这个 Region 待进行的操作通过心跳包的回复消息将需要进行的操作返回给 Region Leader并在后面的心跳包中监测执行结果。 注意这里的操作只是给 Region Leader 的建议并不保证一定能得到执行具体是否会执行以及什么时候执行由 Region Leader 自己根据当前自身状态来定。 信息收集 调度依赖于整个集群信息的收集需要知道每个TiKV节点的状态以及每个Region的状态。TiKV集群会向PD汇报两类信息 1每个TiKV节点会定期向PD汇报节点的整体信息。 TiKV节点Store与PD之间存在心跳包一方面PD通过心跳包检测每个Store是否存活以及是否有新加入的Store另一方面心跳包中也会携带这个Store的状态信息主要包括 a) 总磁盘容量 b) 可用磁盘容量 c) 承载的Region数量 d) 数据写入速度 e) 发送/接受的Snapshot数量Replica之间可能会通过Snapshot同步数据 f) 是否过载 g) 标签信息标签是否具备层级关系的一系列Tag 2每个 Raft Group 的 Leader 会定期向 PD 汇报Region信息 每个Raft Group 的 Leader 和 PD 之间存在心跳包用于汇报这个Region的状态主要包括下面几点信息 a) Leader的位置 b) Followers的位置 c) 掉线Replica的个数 d) 数据写入/读取的速度 PD 不断的通过这两类心跳消息收集整个集群的信息再以这些信息作为决策的依据。 除此之外PD 还可以通过管理接口接受额外的信息用来做更准确的决策。比如当某个 Store 的心跳包中断的时候PD 并不能判断这个节点是临时失效还是永久失效只能经过一段时间的等待默认是 30 分钟如果一直没有心跳包就认为是 Store 已经下线再决定需要将这个 Store 上面的 Region 都调度走。但是有的时候是运维人员主动将某台机器下线这个时候可以通过 PD 的管理接口通知 PD 该 Store 不可用PD 就可以马上判断需要将这个 Store 上面的 Region 都调度走。 调度策略 PD 收集以上信息后还需要一些策略来制定具体的调度计划。 一个Region的Replica数量正确 当PD通过某个Region Leader的心跳包发现这个Region的Replica的数量不满足要求时需要通过Add/Remove Replica操作调整Replica数量。出现这种情况的可能原因是 A.某个节点掉线上面的数据全部丢失导致一些Region的Replica数量不足 B.某个掉线节点又恢复服务自动接入集群这样之前已经弥补了Replica的Region的Replica数量过多需要删除某个Replica C.管理员调整了副本策略修改了max-replicas的配置 访问热点数量在 Store 之间均匀分配 每个Store以及Region Leader 在上报信息时携带了当前访问负载的信息比如Key的读取/写入速度。PD会检测出访问热点且将其在节点之间分散开。 各个 Store 的存储空间占用大致相等 每个 Store 启动的时候都会指定一个 Capacity 参数表明这个 Store 的存储空间上限PD 在做调度的时候会考虑节点的存储空间剩余量。 控制调度速度避免影响在线服务 调度操作需要耗费 CPU、内存、磁盘 IO 以及网络带宽我们需要避免对线上服务造成太大影响。PD 会对当前正在进行的操作数量进行控制默认的速度控制是比较保守的如果希望加快调度(比如已经停服务升级增加新节点希望尽快调度)那么可以通过 pd-ctl 手动加快调度速度。 支持手动下线节点 当通过 pd-ctl 手动下线节点后PD 会在一定的速率控制下将节点上的数据调度走。当调度完成后就会将这个节点置为下线状态。 一个 Raft Group 中的多个 Replica 不在同一个位置 以上内容为个人梳理总结于TiDB官网 https://www.pingcap.com/docs-cn/ 转载于:https://www.cnblogs.com/xuliuzai/p/10022875.html
