共计 3786 个字符，预计需要花费 10 分钟才能阅读完成。
TDSQL-C PG 版产品简介
TDSQL-C PG 版是一款基于计算、存储拆散的云原生数据库产品。相比于传统的 PG，咱们将 PG 数据库集群分为计算节点和存储节点两局部来进行独立的治理和部署。其中在计算节点方面，一个集群内所有计算节点会共用同一份近程数据存储，主备之间日志只会用于更新缓存，从而解脱传统 PG 下主备日志同步时影响集群可用性的问题。
在存储方面，TDSQL-C PG 版独立部署的存储服务以 Segment Group 为根本单元来治理数据库对应的数据存储，一个集群下的数据会拆分到多个 Segment Group，Group 中的 Segment 又能够散布到多个不同存储服务上进行治理，从而实现通过扩大存储服务来实现数据库存储空间扩大，解脱传统 PG 数据库在存储数据容量上受限于单机磁盘空间大小的问题。
另外，在数据库备份回档性能上也是拆分到 Segment Group 维度上来实现，Segment Group 能够并发进行备份和数据回档，从而极大的缩短数据库备份回档耗时。
TDSQL-C PG 版高可用性能改良
基于上述架构在产品个性上，咱们的近程存储应用多正本机制解决了数据可靠性问题，同时计算节点互相不依赖日志同步，从而解决了可用性问题，最终达到可靠性和可用性兼顾成果。在应用老本上，一个集群下不论多少个实例，都是共用同一份存储，并且依照存储理论使用量免费。相比于惯例主备集群下每个实例都须要独自占用存储空间，咱们极大的升高了集群的应用老本。
在最大存储数据量上，存储服务能够实现独自程度扩大，从而使整个集群数据存储量失去大幅度晋升。另外，在数据库集群计算能力扩大上，新增备实例都无需同步数据，能够实现秒级疾速扩大。最初，在数据库的回档操作中，咱们是基于 Segment Group 并行回档，能够将回档速度能够晋升到 GB 每秒。
基于此产品架构，咱们在高可用方面又有哪些相应改良？
咱们先看看在惯例主备模式下的常见高可用计划。在惯例主备模式下，主备都是通过数据流复制形式来实现数据同步，其中同步数据流复制模式下，主实例的每一次提交都要等到备实例实现日志落盘之后才可能返回，这样才可能强行保障主备数据一致性。但同样也带来了，备实例异样时，会影响主实例可用性的问题。而在异步数据流复制模式下，主实例是能够不放心备实例的日志落盘状况。这样尽管能够防止可用性问题，但也会造成主备实例数据的一致性问题。
基于此，咱们会应用额定的 Warm Standby，和主实例之间放弃同步数据流复制。同时咱们的 Warm Standby 不会对外提供服务，尽量减少 Warm Standby 实例影响主实例的状况产生，而其余提供对外服务的备实例则通过异步数据流复制形式来实现和主实例数据同步。当主实例出现异常时，能够应用和主实例保持数据强统一的 Warm Standby 实例来进行备提主，疾速复原主实例可用性。之后咱们会再异步进行 Warm Standby 实例重建，最终将整个集群复原成失常状态。这种解决流程尽管尽可能保障了可用性，但依然存在一些问题是没有方法解决的，例如 Warm Standby 实例尽管没有提供对外服务，但还是可能会存在比方机器、网络等硬件故障导致不可用的危险，从而影响主实例的可用性。
另外，Warm Standby 实例重建也须要工夫，当其没有实现重建时，如果新的主实例再次出现异常，就没方法疾速复原可用性。除此之外，一个不提供对外服务的 Warm Standby 实例也要占用资源，所以必不可少会带来多余的老本开销。
那么在 TDSQL-C PG 版计算存储拆散架构下，这个问题是否有更好解决形式？得益于咱们做了计算存储拆散，主备实例会应用同一份远端存储数据，它们之间不存在数据同步的前置依赖。而在数据可靠性方面，咱们交由独自存储服务来实现。当在主实例上进行数据写入时，咱们会把日志发给存储服务，存储服务实现日志落盘后，就能够返回响应给客户端，同时存储服务再本人以异步日志回放形式去更新磁盘数据，而备实例接管主实例日志只用于更新缓存，在异样时也能够间接应用远端存储服务数据。这样下来主备之间就没有数据同步依赖，从而也就不存在备实例异样影响主实例状况。
另外在这个架构下，也不须要额定 Warm Standby 实例。集群当中，每个备实例都能够在既提供给业务应用的同时，也成为主实例异样时的备份。同时每减少一个备实例，不仅可能晋升集群整体读取性能，也可能更洼地保障整个集群的高可用。当主实例出现异常时，会选取任意备实例来做备提主操作，疾速复原主实例可用性。在备实例被提成主之后，得益于存储计算拆散架构，咱们无需数据同步就可能疾速实现新的备实例补充。最初，会通过下层负载平衡的路由切换，来保障业务拜访数据链路失常，在极短时间内将整个集群复原成故障之前的样子。
在产品能力方面，业务应用方也能够依照本人流量散布来设置备实例切换优先级，从而尽可能减少异样时对于业务的影响。在外部管控实现上，原来的高可用管控也就拆分成了独立两局部，其中存储管控是负责存储节点的高可用，它会负责对于根底的存储组件 Store Node、外部 Segment 存储单元、以及备份回档等模块进行衰弱状态查看及异样解决。总体来说，其会站在存储角度，来保障整个分布式存储服务的可用性。在实例管控方面，更多是负责计算节点的可用性，它会通过多种手段去实时检测计算节点衰弱状态。当呈现某些波及到存储读写异样场景时，会联合存储管控衰弱信息来综合决策咱们的高可用 HA 执行逻辑，联合起来保障整个数据库产品服务的高可用。
除了上述优化，接下来还有曾经打算的优化空间，比方以后做 HA 切换时，必不可免会波及到工夫重启、主从切换这些操作，这些操作都会导致业务对实例的连贯断开。尽管目前通过下层负载平衡服务来防止切换影响业务拜访地址问题。但繁多的负载平衡服务是没方法做到连贯放弃，所以须要验方来做重连机制，才可能在 HA 产生之后复原对数据库的拜访。当初有打算在减少 Proxy 模块来实现连贯放弃，从而解决 HS 用户连贯断开问题。再往前一步，Proxy 退出也为后续实现主动读写拆散等个性提供根底。另外，跨可用区、跨地区容灾也在打算中进一步晋升数据库服务可用性个性。
保障业务高可用
在介绍完利用计算存储拆散架构劣势带来的高可用优化之后，接下来聚焦疾速扩大这个产品个性给业务高可用带来的价值。
在通常的在线业务服务上，最容易碰到的场景是超出预期的流量突增，从而给整个零碎带来非预期的申请压力，这种压力很容易会传导到数据库服务上，从而造成数据库性能的瓶颈。呈现这样场景时，对于业务方来说，可能最迫切的需要就是疾速加大数据库实例规格，或者减少备实例来应答数据库压力，解决业务可用性问题。这个时候数据库实例扩大的耗时就会极大影响业务的可用性。
在惯例主备模式下，退出一个新备实例或进行主实例跨机迁徙时，是须要串行实现两个步骤，第一个是通过 basebackup 去同步数据，另一个是同步后的数据恢复。这两个步骤，尤其是同步数据耗时是和数据量的大小呈反比。例如用 1TB 数据量的一个数据库来举例，在机器带宽为 25G 前提下，须要至多 5 分钟能力实现数据同步，而随同着数据库数据量越大，这一步破费工夫会变得更长。另外在云上，一个宿主机上往往不只会部署一个数据库实例，思考到对于整个宿主机的影响，咱们不可能满带宽进行数据同步，所以实在工夫往往会变得更长，这样同时也就意味着咱们复原业务可用性的耗时会变得更长。
在 TDSQL-C PG 版产品下，这里会有什么样改善？在 TDSQL-C PG 版产品下，咱们的主备实例会共用远端存储，这意味着新增实例时，只须要减少计算节点，而无需经验耗时最长的数据同步过程。同时不须要数据同步，就意味着集群数据量增长并不会导致整个耗时减少。整个新增实例耗时等同于启动一个新的 PG 实例过程。咱们能够将整体的耗时放大到秒级，以最快的速度来满足业务对于疾速扩大的需要。另外，TDSQL-C PG 版最大是反对 15 个备实例，备实例能够依照业务须要调配到不同负载平衡组提供给业务应用，最大满足业务对读取性能的灵便要求。
基于以上个性，能够疾速满足业务对数据库的性能调整要求，但在整个过程中，还须要依赖于业务方对于数据库应用状况的监控以及时的染指操作来实现扩容，从整体上来说，还是要靠人工来保障可用性。那么是否有更好计划能够在无需人工染指操作的状况来解决这种问题？答案就是 Serverless。
Serverless 是云原生倒退的一种高级状态，可能充沛展示云原生能力，让用户更专一于业务上，而无需关怀资源状况。在 Serverless 模式下，咱们计算节点性能会追随业务流量进行主动调整，当业务流量回升，对于数据库计算资源需要减少时，会主动进步计算节点资源规格。而当业务流量下降时，对于资源需要缩小的时候，会主动升高计算节点的资源规格。
在存储方面，TDSQL-C PG 自身就是按 Segment Group 来调配存储资源，当发现现有的存储资源不够用时，就会主动新调配 Segment Group 来满足业务对于数据寄存的需要。从而在整个数据库服务上，实现了资源自适应，用户齐全无需关注资源状况，防止须要人为染指能力保障业务高可用场景。另外在应用老本下面，Serverless 是齐全按需应用免费的。流量低时，理论规格低，费用天然也就跟着降落。相比于人为去调整理论规格，在费用下面也会有大幅度节俭。
