怎么样做好网站建设服装制作公司

怎么样做好网站建设,服装制作公司,计算机前端,wordpress阿里巴巴图标一、介绍TiDB作为一款分布式、金融级高可用数据库#xff0c;数据采用多副本存储#xff0c;数据副本通过 Multi-Raft 协议同步事务日志#xff0c;多数派写入成功事务才能提交#xff0c;确保数据强一致性且少数副本发生故障时不影响数据的可用性。还可以按需配置副本地理…一、介绍TiDB作为一款分布式、金融级高可用数据库数据采用多副本存储数据副本通过 Multi-Raft 协议同步事务日志多数派写入成功事务才能提交确保数据强一致性且少数副本发生故障时不影响数据的可用性。还可以按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。目前HULK TiDB存在两种型态的集群高可用一种是基于上述理论的单集群同域多机房高可用一种是基于DTS同步工具的跨集群机房高可用。二、TiDB多机房高可用介绍2.1单集群同域多机房同区域三机房方案即同区域有三个机房部署 TiDB 集群机房间的数据在集群内部通过 Raft 协议进行同步。同区域三机房可同时对外进行读写服务任意机房中心发生故障不影响数据一致性感知。图2.1.1 集群机房分布图优点所有数据的副本分布在三个机房具备高可用和容灾能力任何一个AZ 失效后不会产生任何数据丢失 (RPO 0)任何一个AZ 失效后其他两个AZ 会自动发起 leader election并在一定时间内通常 20s 以内自动恢复服务采用区域多机房方案当任意一个机房故障时集群能自动恢复服务不需要人工介入并能保证数据一致性图2.1.2 机房一节点失活缺点性能受网络延迟影响。具体影响如下对于写入的场景所有写入的数据需要同步复制到至少两个 机房由于 TiDB 写入过程使用两阶段提交故写入延迟至少需要两倍机房间的延迟。对于读请求来说如果数据 leader 与发起读取的 TiDB 节点不在同一个 AZ也会受网络延迟影响。TiDB 中的每个事务都需要向 PD leader 获取 TSO当 TiDB 与 PD leader 不在同一个 AZ 时TiDB 上运行的事务也会因此受网络延迟影响每个有写入的事务会获取两次 TSO。2.2DTS多集群数据同步搭建一主一备两个TiDB集群通过DTS数据同步工具将主TiDB集群的数据同步到备TiDB集群目前HULK底层使用的TiCDC工具进行数据同步。图2.2.1 线上ticdc高可用架构图优点同一个集群所有数据副本分布在同一个机房不受网络影响。副集群可以用来提供数据分析任务降低对在线业务的影响。缺点数据同步具有局限性不支持系统表如mysql.*和information_schema.*的 DDL 和 DML 语句。临时表的 DDL 和 DML 语句。DQL (Data Query Language) 语句 和 DCL (Data Control Language)语句。所以需要手动处理主集群的用户权限表同步到备集群。速度同步具有局限性大表同步从 v7.1.0 起TiCDC 支持 MQ sink 按照 TiKV Region 粒度来同步数据变更日志实现处理能力上的可扩展性使得 TiCDC 能够同步 Region 数量庞大的单表开关受enable-table-across-nodes true 参数控制索引操作 (ADD INDEX,CREATE INDEX)为了减少对 Changefeed 同步延迟的影响当下游为 TiDB 时TiCDC 会异步执行创建和添加索引的 DDL 操作。事务同步具有局限性TiCDC 对大事务大小超过 5 GB提供部分支持根据场景不同可能存在以下风险可能导致主从同步延迟大幅增高。当 TiCDC 内部处理能力不足时可能出现同步任务报错ErrBufferReachLimit。当 TiCDC 内部处理能力不足或 TiCDC 下游吞吐能力不足时可能出现内存溢出 (OOM)。虽然从V6.2TiCDC 支持拆分单表事务功能可大幅降低同步大事务的延时和内存消耗。但是这是在牺牲业务对事务原子性要求不高的情况下才能实现可以通过设置 sink uri 参数transaction-atomicity打开拆分事务功能以解决可能出现的同步延迟和 OOM 问题。业务访问具有局限性当主集群异常提升备集群提供服务时业务需要变更VIP地址即使使用域名也会有域名生效时间。三、多机房高可用原理简述下面主要根据以上两种高可用方案进行相关高可用原理简介。3.1单集群同域多机房原理单集群同域多机房主要是使用了TiDB的Labels标签功能。TiKV 是一个 Multi-Raft 系统其数据按 Region默认 96M切分每个 Region 的 3 个副本构成了一个 Raft Group。假设一个 3 副本 TiDB 集群由于 Region 的副本数与 TiKV 实例数量无关则一个 Region 的 3 个副本只会被调度到其中 3 个 TiKV 实例上也就是说即使集群扩容 N 个 TiKV 实例其本质仍是一个 3 副本集群。由于 3 副本的 Raft Group 只能容忍 1 副本故障当集群被扩容到 N 个 TiKV 实例时这个集群依然只能容忍一个 TiKV 实例的故障。2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本整个集群的数据也不再完整访问到这些 Region 上的数据的 SQL 请求将会失败。而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多其可用性是逐渐降低的。正因为 Multi-Raft TiKV 系统局限性Labels 标签应运而出其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中启动后的 TiKV 会将自己最新的 Label 信息上报给 PDPD 根据用户登记的 Label 名称也就是 Label 元信息结合 TiKV 的拓扑进行 Region 副本的最优调度从而提高系统可用性。TiDB的标签使用主要受以下参数控制replication.location-labels: [zone, host]该参数控制隔离级别从左往右依此减弱首先按照zone进行region分布zone都一样再按照host进行数据分布。isolation-level zone控制在物理层面上的最低隔离要求假如isolation-level设置值为zone这样就规定了 Region 副本在物理层面上的最低隔离要求也就是说 PD 一定会保证同一 Region 的副本分散于不同的 zone 之上。即便遵循此隔离限制会无法满足max-replicas的多副本要求PD 也不会进行相应的调度。例如当前存在 TiKV 集群的三个可用区 z1/z2/z3在三副本的设置下PD 会将同一 Region 的三个副本分别分散调度至这三个可用区。若此时 z1 整个可用区发生了停电事故并在一段时间后由max-store-down-time控制默认为 30 分钟仍然不能恢复PD 会认为 z1 上的 Region 副本不再可用。但由于isolation-level设置为了zonePD 需要严格保证不同的 Region 副本不会落到同一 zone 上。此时的 z2 和 z3 均已存在副本则 PD 在isolation-level的最小强制隔离级别限制下便不会进行任何调度即使此时仅存在两个副本。以下是一个TiDB的高可用集群拓扑YMAL文件文件中给TiKV节点设置了lable标签部署之后就会完成数据在三个机房均匀分布。global: user: root ssh_port: 22 deploy_dir: /data/tidb_cluster/tidb-deploy data_dir: /data/tidb_cluster/tidb-dataserver_configs: tikv: server.grpc-compression-type: gzip pd: replication.location-labels: [zone,host] # PD 会根据 TiKV 节点的zone 和 host配置来进行副本的调度。pd_servers: - host: 10.xx.xx.01 name: pd-1 - host: 10.xx.xx.02 name: pd-2 - host: 10.xx.xx.03 name: pd-3tidb_servers: - host: 10.xx.xx.01 - host: 10.xx.xx.01 - host: 10.xx.xx.01tikv_servers: # 在 TiKV 节点中通过 labels 选项来对每个 TiKV 节点所在的 zone 和 host 进行标记 - host: tidb-dr-test1 config: server.labels: { zone: beijing01, host: 10.xx.xx.04 } - host: tidb-dr-test2 config: server.labels: { zone: beijing02, host: 10.xx.xx.05 } - host: tidb-dr-test3 config: server.labels: { zone: beijing03, host: 10.xx.xx.06 }3.2 DTS多集群数据同步原理TiCDC 集群由多个 TiCDC 对等节点组成是一种分布式无状态的架构设计。TiCDC 集群及节点内部组件的设计如下图所示图3.2.1 ticdc集群高可用原理图上图中TiCDC 集群由多个运行了 TiCDC 实例的节点组成每个 TiCDC 实例都运行一个 Capture 进程。多个 Capture 进程中会有一个被选举成为 Owner Capture负责完成 TiCDC 集群的负载调度、DDL 语句同步和其它管理任务。每个 Capture 进程包含一个或多个 Processor 线程用于同步上游 TiDB 集群中的表数据。由于 TiCDC 同步数据的最小单位是表所以 Processor 是由多条 table pipeline 构成的。图3.2.2 单表处理数据流转图各个模块之间是串行的关系组合在一起完成从上游拉取、排序、加载和同步数据到下游的过程其中puller从 TiKV 节点获取 DDL 和行变更信息。Sorter将接收到的变更在 TiCDC 内按照时间戳进行升序排序。Mounter将变更按照对应的 Schema 信息转换成 TiCDC 可以处理的格式。Sink将对应的变更应用到下游系统。为了实现高可用每个 TiCDC 集群都包含多个 TiCDC 节点这些节点定期向 PD 集群中的 etcd 集群汇报自己的状态并选举出其中一个节点作为 TiCDC 集群的 Owner。Owner 采用 etcd 统一存储状态来进行调度并将调度结果直接写入 etcd。Processor 按照状态完成对应的任务如果 Processor 所在节点出现异常集群会将表调度到其他节点。如果 Owner 节点出现异常其他节点的 Capture 进程会选举出新的 Owner如下图所示图3.2.3 ticdc高可用原理图四、HULK云平台TiDB多机房高可用使用目前HULK云平台已经对部分集群实现了以上两种型态的集群高可用。4.1 单集群同域多机房使用目前线上对Serverless等公共集群进行了同域多机房高可用改造。从容量监控图可以看出shrxx、shcxx、shyxx三个机房都是163G因为是基于存量三节点集群进行的改造所以有的机房三个节点有的机房一个节点图4.1.1 节点容量监控图各个机房region数量分布其中shr、shc两个机房每个服务器上9.64K个regionshy机房所有服务器region 数量加和也是9.64K数据均匀分布。图4.1.2 节点region分布图从监控图可以看出三个机房的数据分布是符合预期的每个机房9.6K个region。保证其中一个机房挂掉之后另外两个机房仍然能提供服务相当于region副本3份只缺失一份。而且从SQL耗时来开同区域多机房耗时相对于单机房并没有明显增加95%分布在6.29ms以下图4.1.3 查询耗时图4.2 DTS多集群使用4.2.1主备集群同步监控图目前为保证部分业务线集群高可用以及充分利用备集群进行一些数据分析基于TiDB周边工具TiCDC进行数据同步实现集群高可用。图4-2-1-1 Hulk TiCDC复制节点图图4-2-1-1 Hulk 主备集群复制状态监控图我们可以通过以上监控图确认当前主备集群同步是不是存在延迟延迟较大要及时介入处理防止备集群落后太多增加数据丢失的风险。4.2.2主备集群同步告警图为监测数据同步的有效性和实时性添加了集群可用性和任务延迟告警保证集群高可用有效性。图4-2-2-1延迟性告警图4-2-2-2服务存活告警DBA会实时关注以上告警保证集群高可用正常运行。五、结语目前HULK TiDB数据库服务已实现了以上两种形态的集群高可用DTS这种架构看起来非常简洁写入性能不受影响可用性比较高最大的错误容忍目标可以做到跨区域级别高可用RPO 在秒级别RTO 在分钟级别甚至更低。备集群还可以进行一些复杂的分析查询而不影响主集群。但是进行高可用切换时需要业务变更访问地址即使是域名模式也需要等待域名解析生效如果 RPO 为 0 并不是必须满足的要求推荐在重要生产系统使用该容灾方案。单集群同域多机房方案最大的错误容忍目标可以达到同区域多机房级别同等资源配置下写能力也能够得到扩展当然前提条件是多机房之间的网络延迟较低否则写能力反而下降并且 RPO 为 0RTO 也可以达到分钟级别甚至更低。如果 RPO 为 0 是必须满足的要求推荐在重要生产系统使用该容灾方案。业务可以根据自己的场景选择不同的高可用方案高可用具体构建暂时可以咨询DBA进行人工操作自动化产品型态正在开发中。HULK云数据库产品提供一站式全生命周期数据库服务自助管理能力使用HULK云数据库产品请至智汇云官网https://zyun.360.cn,联系客服为您添加账号权限。更多技术干货请关注“360智汇云开发者”360智汇云是以汇聚数据价值助力智能未来为目标的企业应用开放服务平台融合360丰富的产品、技术力量为客户提供平台服务。目前智汇云提供数据库、中间件、存储、大数据、人工智能、计算、网络、视联物联与通信等多种产品服务以及一站式解决方案。官网https://zyun.360.cn复制在浏览器中打开更多好用又便宜的云产品欢迎试用体验~添加工作人员企业微信get更快审核通道试用包哦~