直播回顾|TDSQL的交付-创新互联
腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，0622毕汉斌的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。
关注“腾讯云数据库”公众号，回复“0622毕汉斌”，即可下载直播分享PPT
整 个部署过程最快仅需9 分钟， TDSQL全球灵活部署实践
为帮助开发者更好地了解和学习分布式数据库技术，2020年3月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密，都在这！》邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CDB/CynosDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。本文将带来直播回顾第七篇，分享TDSQL的部署实践。
大家好，我是腾讯云TDSQL DBA毕汉斌。我们本次是围绕着TDSQL交付的话题分享三个方面内容。包括TDSQL曾经面临的交付要求和挑战，以及我们开发沉淀的自动化交付方案，最后更重要的是这套质量保障体系后续可以如何继续在交付后的用户的全生产流程中为用户提供全方位质量保障。
首先我们想讲的是TDSQL的交付挑战，我们也是以三个方面去展开，第一个我们遇到的挑战是我们TDSQL产品架 构所带来 的特点： 一是产品化不断完善带来的特点——组件多，包括拥有数据库内核，任务分发、冷备中心、平台告警、性能诊断等； 二是组件之间的相互依赖的关系比较复杂。
首先我们从层次上把这些组件进行划分：赤兔、监控采集、OSS、metacluster、扁鹊、onlineddl等可以划分为一个角色，叫管理节点。我们从业务层去讲的话，对业务来说，实际访问数据库从业务层去讲的话，的过程是，先是负载均衡层，然后负载均衡层会做负载均衡到我们的到SQL引擎层，而SQL引擎层会直接访问到我们底层的db底层DB，db上也DB上会部署agentAgent，像。图中左侧列这些我们叫做dbDB管理节点。像右侧列如冷备中心、消息队列、多源同步等，我们一般划分为数据节点。而日志分析平台其实就是一个其他的模块，可划分为其他的节点。 像这些节点之间的也是依赖关系比较复杂，像我们的管理节点之前有讲到，像这些。比如管理节点，其实主要做的工作就是负责元原数据管理，像元原数据包括很多，比如以监控采集模块为核心的监控数据，还有、以任务分发系统为核心的任务节点的数据。第二个是我们的DB模块，DB会和管理节点有一些交付交互，首先——所有的角色不仅是除了DB节点，还有其他的节点都会向管理节点发送他的监控信息，因为都会把监控信息发送上去。而管理节点也会下发一些任务，比如说客户在前台进行一些的变更，比如说垂直扩容、水平扩容、主备切换，像这些的等变更动作也是会到实际的DB上进行的交付，也会到实际的DB进行交互。数据节点首先会像向管理节点发送数据，会和DB节点做一些交付互，比如我们最常用的就是数据库数据的备份和回档，这个就是DB的节点和数据节点进行交付。日志分析平台也会和DB节点去交付，他分析DB节点产生的日志，具体会做一些用户的日志分析、SQL分析，甚至会给用户带来一些SQL审计的功能，也会向管理节点上报他的监控信息…… 所以大家再简单看一下，其实各个组件之间的依赖关系，可以看得出来他们还是比较复杂的。其实就是因为像我们这样比较复杂的依赖关系。他，这对于我们的交付是带来一定的难处。在TDSQL早期我们是通过自身TDSQL产品团队给客户做交付。其实按照这样的要求，这会对交付的人力带来很大的要求，既即使是我们去的话，部署一个交付的环境也要两天以上。
TDSQL多个场景主要来源于使用TDSQL的对象是不同的，这个对象可以划分未使用TDSQL的人群是不同的，有个人使用，也有企业使用，也有第三方平台使用，包括个人、企业、第三方平台。其实这些不同的对象使用TDSQL的过程中，他们的需求和场景也是不同的。以个人使用为例，个人使用TDSQL的话，他更多强调的是我想了解你的产品，学习你的产品，体验你的产品，个人使用可能更想我能尽量的低门槛快速上手你的产品，尽量的简单。企业使用最主要的两个场景，一个是POC测试，另一个就是我们的和生产场景。POC测试是，关注我们的的是整个产品的性能和功能，包括高可用性、容灾能力、国产化适配等。从性能和功能的出发，也会带来不同的场景需求。生产其实我们更多关注的是整个交付、整个产品、整个集群，是否有高可用性，是否有容灾能力，是否有一次性的保证。我们的平台接入会带来更多的挑战，我们的平台可能会涉及到一些国产化交付的项目，国产化其实会对我们带来一些兼容性的问题，还会对我们的标准对接、接入带来一些需求。 所以由于不同的对象使用我们TDSQL的产品，就会带来不同场景的需求如何高效满足？ 我 们当时想的是我们TDSQL在交付的场景下，我们是要做多个分支去适配不同的场景，还是用一个分支去适配不同 的场景？ 当然我们是用一个分支去适配不同的场景。
第三个挑战也是，由于时间的推移，我们负责TDSQL去交付的人产生了变化。早期我们TDSQL交付是由我们TDSQL产品研发团队，我们、DBA同学去现场给客户做交付。其实在我们的产品研发团队和DBA团队，大家都是一个团队，团队内由于长期的的合作协同是有是形成了标准和质量可靠，他的交付质量也是有保证的。而随着我们TDSQL产品化，做大做强，对外推广用户规模不断扩大以后，其实会产生交付人员的不同交付人员会发生变化，当然也有一部分是我们产品研发团队直接交付。还有一部分是由我们腾讯专门的交付团队去交付，还有是由我们腾讯内部的第三方平台以及腾讯外部客户自己的第三方平台接入了TDSQL产品，他们第三方平台负责交付。还有也是客户自己本身去做交付。不同的交付实施方，他们的操作和使用的过程中就会带来一些隐患，这些隐患主要体现在以下方面如果不够标准化，则容易带来隐患，体现在几个方面： 第一个是安全的方面。比如说我们环境的安全，我们知道数据库场景是一个对内存、CPU、硬盘、LOIO的等能力，都是要求比较高的场景。之前遇到的一个case，一个客户在数据库的场景下，他（9：22）没有关，在压力比较高的情况下，由于性能问题，最终在一定的场景下带来的一些风险的问题，其实这些就是对环境的优化。其实不仅仅是这种环境优化，包括数据库进程会读大量的文献，他大的文献数继承的是系统用户的大文件数。像这些的设置，包括数据库场景对TCP的一些内核参数的优化等这些工作都是作为潜在风险来统一考虑的。像这些优化其实是作为式一个潜在的风险去考虑的。 第二个是监控方面。对整个集群、进程、机器的监控，提到监控还有一个以及自动的拉起，有很多即机械机器级别等的故障，故障之后一个，进程快速恢复的能力，其实要考虑到完善的自动拉起的体系这些都要作为完善的体系来考虑。其他还有比如一些定时任务，比如说包括定时去清理一些日志文献，清理一些历史上的数据，否则磁盘就会撑满的情况，这在生产的环境上也是风险很大的。还有我们最后是如何保障整个集群的高可用性、容灾性、（10：56）能力。刚才说到的是不同的实施人可能会带来不同的风险，其实除了实施人以外，还有发布的版本也需要控制。有的时候我们是作为第一方去交付这个产品，有的时候我们有外部的客户，他们的平台会交付，不管谁去交付，这个版本是否是一个历史版本，这个版本是否会有一些历史的问题和隐患；如何杜绝这些潜在的旧版本带来的隐患，检测到这些版本的漏洞等等方面，也是我们交付质量的一个挑战都是交付质量体系中需要解决的问题。 其实我们TDSQL交付质量服务和保障就是围绕着上述的一些各方面问题方面，实现由在不同的实施人、实施方去交付我们TDSQL的产品下，都能保证我们TDSQL的投产的质量。这是我们在做的一个事情。
刚才也说到TDSQL的交付过程中遇到的一些挑战，我们针对这些上述的挑战，TDSQL沉淀出了一套TDSQL自动化交付方案。
刚才说我们TDSQL是基于一个分支去做的来实现多场景、复杂关系下的自动化交付的，其实也可以说是基于三个分支去做的。我们TDSQL内核包，当前有三个分支，是：基于CPU的多分支进行发布，当前支持X86、arm、power。其实在我们TDSQL对客户的发布包中，一个包自动的集成了不同CPU版本的TDSQLpocketpacket，是——以ansible组件为基础，加上了条件检测、操作系统调优、环境依赖的解决、安全规范、兼容性问题，我们对外做的是TDSQL私有云标准的发布包。像这个包我们是，可针对于客户不同的场景，刚才说到的不同场景和不同的环境做的适配。
TDSQL的组件我们刚才分为四个角色，如果想要快速的交付TDSQL集群，大家只要搞清楚一件事情，打个比方说就是把不同的鸡蛋放到不同的篮子里。鸡蛋其实就是我们说的是指这些组件，分为这四个；篮子就是我们准备的机器，可以是虚拟机，也可以是物理机。 首先首先说一下我们的个人体验的环境，个人体验的环境刚才也说了，在这样的环境下可能：个人体验环境更注重的是较低门槛比较低，其实在这里我们在这里我们只需要一台虚拟机的配制配置就可以达到这个目的。我们会然后可以把管理节点、DB节点、数据节点和其他的节点都部署在这台机器上。当然在体验的环境下，数据节点和其他的节点，这两个功能根据机器的配制来看，我们可以不进行部署。 在测试环境：该环境换机下注重的是性能、功能。 首先从管理节点来看，其实管理节点提供的是元原数据的管理和任务的分发功能，他对于性能要求不是很强，他其实要求的是一个稳定性和容灾的能力。在测试环境可以稍微弱化这个要求，我们，比如可以准备一台或者三台的虚拟机，配置4C/8G普通磁盘就可以了，配制4C/8G；在测试环境下，我们要去要做DB节点的话，其实在DB节点我们要考虑到TDSQL的性能问题，这里我们就会推荐一个使用物理机；我们TDSQL做进行性能测试的时候要求一定是SSD盘，否则我们的性能数据是没有任何参考性的。——这也是由数据库的场景决定的，因为SSD和普通的磁盘，一个是随机，他们方面主要表现在随机读写的能力上，的差距会比较大一点；数据节点和其他的节点方面，如果有一些客户可能对测试他的功能要求不是那么强没有那么强，他就可以不部署这些节点的功能，而如果我想体验一个完整的TDSQL的功能，则我需要准备这些机器，以体验完整的TDSQL的功能；如果我们要部署数据节点的话，我们可以选择一台机器或者三台机器，虚拟机，以及准备大一较大容量点的磁盘做一个数据节点；其他的节点，这里我们提的是比如负载均衡和日志分析平台，日志分析平台的作用刚才也说了，是做一些SQL审计，DB日志分析等等。其实我们TDSQL的负载均衡会比较灵活，他是在我们的位于SQL引擎层上的上一层，这里推荐的有开源自身的LVS，当然也有很多客户会使用的F5。最后，像这些以上环境我们的推荐是部署两节点来实现，做一个容灾能力。这个其实就是总体而言，为了保证测试的性能，测试环境的要求，要求最多的就是DB这个节点模块，保证测试的性能。 最终是大家最关心的生产环境的要求，我们这里要求的是：生产环境中要求管理节点，可以部署在三台或者五台是虚拟机，但三台或者五台，最好是跨三个机房，比如说“1+1+1”的模式或者“2+2+1”的模式，因为我们的原元数据集群是一个基于多数选举的机制来保障高可用，如果是只有两个机房的话，则会失去了他本身容灾的意义，因此我们建议生产环境这里是中部署三个机房。DB节点生产环境更推荐的是NVME接口的SSD，因为传统的SSD和NVME的SSD可能体现他的在接口性能上，会有比较大的性能差距。这里而数量上我们推荐的数量是3*N台，其实——事实上这个是我们要去评估的生产环境TDSQL集群的数据量。因为我们，TDSQL是一个分布式的数据库，他的数据量级可以根据用户是根据你的机器数量实现做一个水平拓展扩容。 举个例子，比如说我们假设客户有3T的数据，如果（19：39）单台物理机是1T的话，一个（？）set内做的是一主两备三个节点，我们此时就需要三个（？）set，三个（？）set可以承担3T的数据量，同时会有两个副本复本的冗余，我们DB节点的这些数数就需要9台这样的机器，这三个set会组成group shard。数据节点也是的机器也是推荐物理机，这里数据节点在同时在生产环境也需要考虑容灾能力，我们因此推荐是三台机器台机器以上，这就不推荐1台机器了，考虑数据节点的容灾能力。此外，需要的是一个高性能磁盘，来保证回档和备份的效率；最后这边也是推荐物理机，访问链路上接入层是非常重要的一层，我们强烈推荐推进物理机，来提高他的稳定性。
刚才其实也讲到了我们前文讲到了TDSQL不同的组件，他分成不同的层次，我们以及我们怎样去管理这些层次等等其中的层次逻辑。在TDSQL真正交付过程中，为了保证交付质量，结合金融级场景的安全合规、高可用容灾考虑，我们沉淀出一些基本要求和特性： 1.网络：离线部署无外网依赖，机器互通； 2.存储：支持单磁盘、多磁盘和raid； 3.冷备中心：支持hdfs和挂载式分布式存储(如ceph)； 4.机器分布：支持跨机架和跨机房上架服务器，支持多种机器分布模式下的高可用容灾； 5.CPU：在国产化趋势下，目前机器CPU除了适配x86，还包括arm、power，而且首要推荐以上其中一款； 6.操作系统：适配支持centos、ubuntu、以及包括国产化操作系统在内的诸多主流操作系统 。
其实我们在真正去交付TDSQL的时候，用我们交付方案去交付TDSQL的时候，有一些注意点大家也要注意一下。 第一个是我们TDSQL的网络是没有外网依赖，因为很多客户，像一些金融和证券的客户是不能连通外网，我们在TDSQL的发布包里已经解决了这个依赖。 我们只需要一个网络互通即可，也没有网端的要求。 第二个是存储，TDSQL既支持读取物理机上的单磁盘，也支持读取多磁盘，当然也支持我们多磁盘的raid，然后读取这个raid的路径，这些都是可以的。 冷备中心这一块我们TDSQL支持两种，第一种是hdfs，第二种是远端挂载式的分布式存储，比如说ceph的文件系统，他是一种挂载式的文件存储，比如说以前的NAS、NFS这些也算。 我们建议TDSQL要去跨机架和跨机房上架服务器，我们是有做TDSQL的IDC管理，如果按照我们规范的要求去做，你的实例满出来的时候，实例内的主备节点本身就是跨机房的关系。当前我们TDSQL支持的CPU有三种，一种是X86系列，这个是之前的主流系列，第二个是arm，arm也是我们现在很多国产化的厂商去做的架构，第三个是power，power目前的主力还是在浪潮这边。当前客户主要用的操作系统都做过适配，像centos、ubuntu、红帽等一些国产化的操作系统，这些我们都有做适配。 右边这张图上图右侧展示了我们简单的简要分布关系，其实我们就像这样的规划一样，交付过程中我们只要理清楚我们如何把鸡蛋放到对应的篮子里就可以了，即可实现自动化交付：我们先选出篮子，一组物理机就是一个例子篮子，我们就随之把一组的组件DB节点放到这个篮子里，其实这样就完成了自动化的交付。
当然这边其中有很多的细节，客户最关心的问题是我该怎样交付这个产品，大家要做的事情就是规划，其实大家填写的配置客户要做的，是自由决定模块的机械机器分布和集群规模。我们，TDSQL可以通过一个模块之间填写的数量不同的数量差异，会自适应地做但点做出单点方案和多节点高可用容灾方案。这个过程是用户在操作上是无感知的。 举个例子，比如说刚才说的TDSQL是支持HDFS作为做他的冷备中心，如果我们HDFS选的是一个节点的话，他系统会做的一个HDFS的一个但点单点方案。我们知道HDFS的但点方案主要是由（25：38）组成。如果我们这边填的是三节点的配置规划，他它会自动感知到我要做的是一个高可用的容灾方案。当时HDFS主流的用的高可用容灾方案，一个是QJM，一个是基于（？）做的方案。我们当前是用是基于的QJM的方案，他其实包含了（26：07）高可用的方案方式。
刚才说了TDSQL其实除了我们要做一个做完部署规划，把怎样的组件放到哪一组机器上，我们要做的，第二件事情是解决各个组件之间的一些关系，包括一些兼容性的等问题。我举个例子，这次如果部署的TDSQL环境是基于ARM国产服务器的操作系统的国产化的环境，是急于arm平台的操作系统。我怎样我们如何通过一个交付的物料包去适配不同的环境？其实秘密就在这个配置文件里： 1.用户无需关注TDSQL较为复杂的各模块的互相依赖和配置管理问题，只需要根据实际，填写变量文件配置即可； 2.用户填写一个机器规格配置文件、一个变量配置文件，填写后可以适配操作系统和CPU实现一键自动化交付； 3.操作简单用户可独立完成，自动化部署命令可重复执行，在北京信通院机构现场对TDSQL产品化的测试显示，整个部署过程最快仅需9分钟。
客户就可以通过填写我们的配置文件。其实已经做了一些适配，包括对我们的内核包，首先对我们的TDSQL的内核包是出了不同CPU架构的内核包。还有对我们交付逻辑上做了对各个操作系统和CPU的兼容。其实客户无须关心TDSQL比较复杂的模块之间的依赖和配置关系，只要根据实际情况填写变量的配置文件就可以了，填写完了以后就可以执行我们交付的发起命令，可以一键自动化交付。 整个交付过程是非常简单的过程，之前我们有对整个TDSQL的自动化交付过程进行测试，当时是在北京的信通院的一个机构，对TDSQL产品化的交付进行测试，整个过程在搭建TDSQL核心交付场景的情况下，只需要9分钟就可以完成一个交付的场景。其实到这里我们核心的交付流程已经给大家介绍完了，其实很简单，我们根据自己的需求把不同的鸡蛋放到不同的篮子里，将不同角色的组件放到我们准备好的一组一组机器上，这是第一件事情，填写规划的配置文件。第二件事情是填写依赖的变量文化，包括一些环境和操作系统CPU的变量文件，以帮助我们自适应的调整当前的环境是怎样的，去调整一些交付的逻辑。第三个我们真正执行交付命令，这个步骤都一键化的。
刚才有说到我们TDSQL在国产化方面也做了很多工作，当前国产化已经成为一个趋势，TDSQL在国产化适也做了很多工作，从我们底层的服务器到存储器、操作系统、CPU、行业软件、数据库软件等，都是在相关部门指导下国家的领导下进行了联系与各个厂商合作实现从下层到上层全方位的做国产化适配。在国产化的浪潮下，我们TDSQL作为一个腾讯自研分布式数据库，他作为一个优秀的国产化数据库，其实我们也是义不容辞的担当了我们国产化的责任。我们当前其实是从CPU、操作系统都去做兼容，操作系统刚才有几个没有说到。centos、ubuntu、suse，像这几个可能是大家常见的主流操作系统，包括腾讯内部的操作系统tlinux是腾讯内部的一个操作系统，以及中标麒麟、银河麒麟、UOS是等常见的主流国产化操作系统，我们都有TDSQL都完成了适配。除了我们列出来的这些CPU的适配、操作系统的适配，适配全系国产操作系统，TDSQL同时已相继完成对全系国产芯片，全系列国产服务器等的兼容适配工作。而在完成适配工作的同时，腾讯也提供了对应的技术服务，帮助行业用户更好地迁移到国产基础技术生态当中。刚才提到有很多服务器CPU的一些硬件厂商做国产化，我们和浪潮也做了一些测试和认证，并且拿到了浪潮的认证，除了浪潮的以外，我们还在很多其他的国产化的客户项目中，可能更多偏向于政府和国企相关，也同时并行做这些国产化的项目，并且已经拿到了一定的成果。这个些是我们对国产化的方面的工作。 技术服务生态方面，TDSQL其实不仅可作为一个独立发布的产品，在TDSQL发展的历程中，也其实他已经被很多其他的很多平台厂商各种和合作伙伴接纳，包括腾讯内部主要是的TCE、Tstack、MDB架构等。TCE是腾讯云基于金融级别的一个平台，TDSQL也是和TCE进行高度的集成，包括从我们的在部署方案、告警、用户权限等等各种维度和TCE进行了深度的集成，可为金融政务机构提供全方位的PaaS基础技术服务，在完成高性能的分布式架构转型升级的同时保障金融级稳定高可用。Tstack和MDB也是我们内部的一些平台，除了我们内部的平台，还有很多客户自己的一些平台。除了客户自己的业务在使用TDSQL以外，有些TDSQL许多客户合作伙伴是做一些的行业的解决方案，在他们的解决方案中也集成了TDSQL，把我们TDSQL的能力输入到他们自己的平台。
TDSQL在发展中对交付场景做了许多优化： 1.条件检测： 首先会自动对规划的TDSQL集群下的所有机器做前置检测，包括机器时间同步、时区一致、端口占用、系统默认sh、机器规格等做检；
2.环境优化：针对关系型数据库场景，对系统50处左右进行针对性调优，并解决一些基础的依赖； 3.机器秒级监控：大部分的监控平台都是基于分钟级的，对于金融级数据库这种敏感场景，分钟级的监控是不够的。 我们在交付的场景下也做了一些优化，首先我们会对整个TDSQL规划的集群下的所有机器做前置检测，包括常见的机器的时间同步、机器的时区、端口占用、系统默认sh、机器规格。我们会对环境进行优化，刚才有提到一些操作系统的内核参数，针对于关系型数据库场景，比如说TCB的一些优化，像一些内存参数的优化，其实我们做了一些调优，并解决了一些技术的依赖。还做了一个秒级的监控。其实客户自己的监控平台，包括我们本身给客户提供的监控中心，大部分的监控体系是基于一个分钟级的，但是数据库这样的场景比较特殊，其实很多的问题在分钟级的监控下，问题的现场就会丢掉，不能暴露问题的本身。所以我们针对这样的场景做了提供了秒级的监控，我们做了几个维度，有包括针对机器的IO、CPU、网络、内存等等多个维度。
前文刚才讲的是我们在TDSQL在单集群下的交付场景和交付细节，之前在架构课上的时候我们也介绍了TDSQL多集群的交付方案。其实接下来介绍在多集群下的，我们来看一下交付具体是怎样进行的。
“同城两地三中心”部署体系
“
同城三中心”架构顾名思义：
在一个城市有A、B、C三个机房，TDSQL仍采用“一主两备”结构，很显然我们需要将三个数据节点分别部署在三个机房，其中主节点在一个机房，两个备节点分别部署在另外两个机房。
同城双中心的架构下我们是有两套集群，第一套集群是蛇口这个集群，我们是交付一套集群。
然后在观澜集群是交付另一个集群。
我们在两个集群之间做了一个异步复制，这个是同城双中心。
第二个是“同城三中心”，我们是架构的部署下，是在一个大集群内，在这个数据库实例下，我们数据库实例使用使用的是同IDC异步、跨IDC强同步的方式，然后在这边上海会有一个强同步的实例，实例之间会做一个DCN的复制实现金融级高可用容灾。
“两地三中心”架构顾名思义：
在一个城市有A、B两个机房，另一个城市有C机房，在第一个城市中TDSQL数据库实例采用同IDC异步、跨IDC强同步的方式，我们需要在第一个城市将四个数据节点部署在二个机房，其中主节点和一个备节点在一个机房，另外两个备节点在另一个机房。
并且在第一个城市和第二个城市的数据库实例间，采用的是异步复制，保障金融城市级高可用容灾。
“两地四中心”部署体系
“最后一种就是两地四中心”的架构，是一个自动化切换的强同步架构，我们也是两个实例，第一个实例是深圳的实例，我们是分成三个IDC。
举个例子，一个是福田，一个是蛇口，一个是观澜，一个实例跨三的IDC，我们做的一个强同步。
第二个实例是在上海，在这两个实例上也是用的DCN做的实例之间的同步，对任何数据中心及故障都能30秒内切换，并且数据零丢失，性能也稳定可靠，对业务和用户来说是实现更高的可用性和更低的成本。
刚才有讲到了我们TDSQL的一些交付的场景，交付的需求和一些做TDSQL国产化和兼容性一些特性的交付考虑。其实在最重要的地方就是最后，最重要的是我们如何保证TDSQL的交付质量，不仅是交付质量和服务的质量，这一块我是单独拿到最后一章给大家介绍。
首先我们TDSQL的交付质量，我们是通过一个叫自动化巡检的方案保证。TDSQL自动化巡检的方案我们是通过三个维度控制我们的保障交付质量。
1.监控指标分析
第一个维护维度基于是依赖TDSQL现有的监控中心，从我们现有的监控体系中去做一些进行相关指标性的分析，包括。当前我们这个指标性的分析也分为两个维度，第一个维度是当前时刻的指标分析，第二个维度是和历史时刻的指标分析。什么意思？其实这里就会涉及到一个问题，我们当我们要在验证一个集群，一个TDSQL的集群是否有问题的时候，我们往往除了要分析此时此刻的集群是否存在有一些异常，是否有一些和告警，是、是否存在有一些资源负载过重等等情况。其实往往，还需要分析历史性的问题，比如说在历史我过去在历史七天中各个指标的曲线是如何的。为什么要分析过去历史七天的指标曲线？举个简单的场景案例，我这边例如一个场景是在每天下午三点到五点的时候，是业务高峰期，在这个业务高峰期的期间，我可能有很多业务的慢查询，甚至有一些慢查询带来的性能的问题。系统我如何监控在历史某个时刻出现的问题？比如说我那么我们发起自动化巡检方案的时候，我是比如是上午8点钟发起，其实上午8点钟是我的，适逢业务低峰期，此时是发现不了问题的，所以我们需要对历史上的指标做进行分析。 方案中具体看一下我们有分析的哪些指标，我们从哪些维度进行分析。我们包括检测前台连通性如何，我们、确认告警有没有正确的发送到客户手中，我们看一下实例的复制方式。我们的TDSQL有几种实例的复制方式，有强同步，有异步，也有同IDC异步、跨IDC强同步的复制方式。其实我们在复制方式之间又很多的选项，比如说我们强同步有可推化的选项，其实当强同步发生了可推化以后，他其实是一个潜在的风险，我们要把这种潜在的风险弄出来。还有实例免切节点，当发生主备切换的时候，会产生一个免切节点，如果有这个免切节点的话，我们就知道之前历史上发生过主备切换，会阻止接下来的自动主备切换方式等，影响我们整个集群的高可用性。 慢查询是很多性能问题，甚至是一些线网问题比较常见的原因，备延迟，HDFS使用率，还有告警策略对比。其实监控主要分为两个方面： 第一个是监控指标的采集、上报、搜集，这是我们的监控中心在管负责。除了我们拿到这个监控的数据，我们要对这个。 第二是对监控数据进行分析，我们对我们，并对认为异常的分析进行告警，其实在这些。分析和告警下，就会有一个过程中会遵循一定的策略的问题，我们认为——怎样的监控数据才是异常的，才有必要告出来告警的？当然我前们TDSQL维护了一套私有云的告警模板。我们，也给客户提供了一些可配置的、定制化的选项，客户可以根据自己的实际情况进行告警策略的修改；同时提供基于实践经验积累的告警策略对比，以防用户做出不合理的修改，暴露告警策略的潜在风险。 在这个维度，TDSQL多源同步等模块可以对数据同步情况进行监控，他们当前同步的稳定性、同步的性能如何，等其他就是各个模块的告警的监控指标。但是为了以防客户误操作或者不合理的修改，我们在这边也会对告警策略进行对比，将一些明显不合理或者极为不合理的改动暴露出来，提示给客户，告诉客户这条告警策略什么时候被改过，我们建议这边告警策略是有风险的。
还有我们在TDSQL的同步方式上会有监控，DCN的同步和多源同步的监控，他们当前的同步的稳定性、同步的性能如何，其他就是各个模块的告警的监控指标。第一个维度就是我们说的从监控数据的角度来进行分析，第二个维度相当于是对第一个维度的补充，第二个维度就比较多，我们首先分析的是机器级的，我们不是采的监控数据，是直接真刀访问服务器后台，我们会对机器基的LO、CPU、内存、磁盘、稳定性这些进行检测。稳定性就表现在有一些服务器可能是一些老服务器，比如说已经运行五年了，我们要告知客户运行五年的机器可能有风险，还有一些机器可能会经常重写，我们告诉客户从各种信息里面看这台服务器本身的稳定性是有问题的。我们从进程级去考虑，我们关键要看的是进程本身的情况，一般进程是有守护进程和工作工程组成的，工作进程是否是正常的，守护进程是否是正常的，当前进程开通的端口是否可以正常的访问。除了进程本身的问题，还要看一下关键进程的配置文件的问题，其实很多的配置文件关系到我们整个TDSQL集群的可用性。
2. 集群环境
还有我们在TDSQL的同步方式上会有监控，DCN的同步和多源同步的监控，他们当前的同步的稳定性、同步的性能如何，其他就是各个模块的告警的监控指标。第一个维度就是我们说的从监控数据的角度来进行分析，第二个维度相当于是对第一个维度的补充。第二个维度就比较多，我们首先分析的是的分析是机器级的，我们不是通过采的监控数据，是直接真刀访问服务器后台，我们会对机器级基的LIO、CPU、内存、磁盘、稳定性这些等进行检测。稳定性就表现在有一些服务器可能是一些老服务器，比如说已经运行五年了，我们要告知客户运行五年的机器可能有风险，还有一些机器可能会经常重写，我们告诉客户从各种信息里面看这台服务器本身的稳定性是有问题的。我们从进程级去考虑，我们关键要看的是进程本身的情况，一般进程是有守护进程和工作工程组成的，工作进程是否是正常的，守护进程是否是正常的，当前进程开通的端口是否可以正常的访问。除了进程本身的问题，还要看一下关键进程的配置文件的问题，其实很多的配置文件关系到我们整个TDSQL集群的可用性。
我们会对一些关键的进程进行扫描，防止客户手动的误改或者人为的删除修改一些关键配置错改、误改。除了机器级和进程级，我们还会进行实例级进行一的些定制化的扫描，其实这个就体现在实例的体检模块。之前我们的课程也有分享过扁鹊的工具，实例的体检就是TDSQL智能诊断分析平台“扁鹊”工具的接口，可以为实例提供他会给我们从一个实例，从运营、开发、性能等各个指标做一些的系统性的分析。第四个维度是 集群级层面，我们会关注从低到高，最高就是集群性的维度，在集群性的维度下我们要关注的问题，这个集群各个机器之间是否是同步的，时间是否是同步的，TDSQL是要求各个机器要时间同步。还有、实例下源元数据集群是否是有备份的，他、的备份是否是正常的，以及我们这边会手工触发此时此刻的源数据集群的备份。我们会在四个维度对第一个监控项从四个方面做一个补充的扫描等。
3. 自动化演练
在我们以各个维度去扫描当前集群没有问题的情况下，我们还是要从结果出发TDSQL还会从结果出发，我们会对整个集群做一次P0级别（最高级别）的自动化的演练，演练的场景就是我们正常运营和管理的场景。比如说，包括购买实例、创建用户、用户授权、创建库表，在这个库表上做一些表结构的变更。在这个实例上我们会做一些、水平的扩容，做一些、垂直的扩容，把他扩到不同的机器上，还会做一些、重做备机，模拟一些重做备机的场景，还有、慢查询入库，是否慢查询，我们可以在制度的分析页面上可以入库，还有、备份和回档，我们会模拟把当年的实例做一次手动的备份，并且拿这个备份是否能回档到之前我们备份的点以及保证整个回档和备份的过程，他的数据是一致的等。最后我们系统会对购买的实例进行删除，他其实实现了闭环，对P0级别的场景做了进行闭环的自动化的演练。
总结来说，TDSQL自动化巡检方案 我们从这三个方面，从我们的指标级，从补充到整个集群环境的进行扫描，以及我们的通过自动化演练，这三个维度确保我们整个交付的集群是安全、稳定、可靠、高可用OK的，并且会生成一个我们的质量报告到客户以及我们TDSQL的产品研发团队去参考。
除了我们TDSQL的质量保证除了技术上的保障方案，我们还会做一些产品化的TDSQL同时沉淀了大量产品化工作，帮助用户快速、方便地使用分布式数据库。
比如说当我们的客户从0到1，他是完全的交付。从交付以后从1到多的话，就是运营和使用的过程了。在这些交付和运营的过程中，我们又会带来很多的问题，比如说怎么交付？刚才我们只是讲了一些交付的特点，交付的概念，怎么去操作呢？其实我们也会做一些产品化的文档的输出。第一个文档就是我们大部分的交付、运营在我们TDSQL的产品文档上，他还包括我们的巡检，刚才我们说的自动化巡检的方案，还有故障处理。当遇到一个告警和故障，我们怎么样去处理，怎么样解读这个故障还有一些前台的操作指导，我们告警的异常解读，我们的日常变更扩容等等，他是在我们的产品文档上。如果我们想做一些POC的测试，我们要对一些场景进行适配的话，可能要考虑到业务侧的开发问题，我们有输出TDSQL最佳实践的开发指南。还有对标准化测试这样的情况下我们输出我们POC的用例，提供了性能的用例、功能用例、高可用容灾用例。 我们也会对客户的信息进行定期的维护，首先我们会对客户定期发起一个集群的巡检，通过这个巡检我们可以保证客户当前以及历史一段时间内，客户的环境是没有问题的。刚才也说了巡检主要进行功能性和容灾性的演练。通过自动的我们的定期的巡检，会搜集到客户的环境和版本信息，我们会把这些信息更新到我们的客户管理系统中，更新的信息是用来之后做客户私有云的版本推送。在我们的管理系统内部会自动进行扫描客户当前的版本，如果我们扫描到有建议客户要升级的版本，我们则会自动推送到客户代表，然后由客户代表推送推动客户升级。
最后是跟我们客户最后，在客户日常运营、日常变更相关的中，可能大部分运营面临的大部分问题是怎么去扩容、升级、处理告警？怎么扩容？我们TDSQL会对各个节点的扩容有一个提供了自动化的扩容方案，可以一键的扩容。同样升级也是提供了前台化一键操作的功，功能，既可以进行点对点的升级，也可以进行整个集群的批量升级，这个也是我们有一个前台化的升级工具。TDSQL的高可用性一方面在于自身的弹性架构和容灾能力，以及数据强一致性。
可用性方面TDSQL提供了自动化告警处理方案告警其实TDSQL的可用性一方面在于他自身的架构和容灾能力，在于他的强浓度告一致的特性，还有我们的监控系统。在我们的监控系统中难免会产生告警的问题，告警问题处理及时与否，处理的方式其实是影响到我们TDSQL集群的可用性。其实在这个问题上，我们自身也是做了很多探索，我们既要平衡客户实际的告警处理、告警解读的工作量，也要帮助客户保证整个集群的质量。我们这边提出了一个自动化告警分析，将一部分的告警可以自动化的处理，减少客户自己线网运行的工作量，可实现自动化告警分析，并对部分告警自动处理，减少现网运营的工作量 。 刚才我们是以上我们以交付为核心介绍了我们TDSQL在历史过程中遇到的几个交付上的挑战，和针对这些交付挑战，我们提出的了我们自动化的交付方案，这些交付方案的特性是什么，我们如何完成我们的交付，我们在这个交付上可以使用的特性，他的兼容性场景有哪些。以及最后我们对整个TDSQL标准化交付的质量和客户的服务进行了提供了一系列的机制和能力的提升机制和能力方面的提升，关于更多我们TDSQL的细节，可以关注我们TDSQL数据库公众号，我们在这个公众号会有一些定期的推送文章跟大家分享。
Q：TDSQL支持数据库离线备份吗？ A：我们TDSQL支持多种备份方式。我们，可以基于物理式的（56：22）的备份，也可以基于逻辑备份。但是我们备份的介质是备份到HDFS或者挂载式的存储上。整个备份过程其实是在备机上进行备份，备份是，不会影响到我们正常的业务访问，也不会对业务访问的性能带来影响。 Q： TDSQL的告警信息如何接入短信、语音、邮件告警平台？
A：我们TDSQL的告警接入是比较灵活的，首先我们TDSQL的告警信息是一个文本的形式，他可以发送到任何的平台，我们当前已经适配过的客户已经适配过的告警接入方式有很多，比如说客户有HTTP接口的告警平台，也有一些其他接口的。其实我们只要根据我们的指引手册，把我们的告警信息以你根据客户想要的接口，比如说HTP，我们就发一个HPT的TDSQL可以对应地发一个包，包含了我们的告警信息，发到你的告警接收平台就可以了。怎么样告警的接受介质？其实短信、语音、邮件，这个还是由每个客户自身的告警平台的能力有影响，比如说自身客户已经有了一个微信的告警接收的平台，此时我们TDSQL是接入到客户微信的告警接收平台，对于不同的告警接收平台，TDSQL我们自身针对不同的语音、短信和邮件分别做了不同的告警信息发送。
特惠体验云数据库
网页题目：直播回顾|TDSQL的交付-创新互联
本文URL：http://mswzjz.cn/article/ccposg.html
关注“腾讯云数据库”公众号，回复“0622毕汉斌”，即可下载直播分享PPT
1
峨边彝族ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！直播回顾：https://v.qq.com/x/page/v31023ovs5l.html
前言
整 个部署过程最快仅需9 分钟， TDSQL全球灵活部署实践
为帮助开发者更好地了解和学习分布式数据库技术，2020年3月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密，都在这！》邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CDB/CynosDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。本文将带来直播回顾第七篇，分享TDSQL的部署实践。
大家好，我是腾讯云TDSQL DBA毕汉斌。我们本次是围绕着TDSQL交付的话题分享三个方面内容。包括TDSQL曾经面临的交付要求和挑战，以及我们开发沉淀的自动化交付方案，最后更重要的是这套质量保障体系后续可以如何继续在交付后的用户的全生产流程中为用户提供全方位质量保障。
1
TDSQL交付要求和挑战：快速给、灵活、安全给
首先我们想讲的是TDSQL的交付挑战，我们也是以三个方面去展开，第一个我们遇到的挑战是我们TDSQL产品架 构所带来 的特点： 一是产品化不断完善带来的特点——组件多，包括拥有数据库内核，任务分发、冷备中心、平台告警、性能诊断等； 二是组件之间的相互依赖的关系比较复杂。
1.1 复杂产品组件交付
首先我们从层次上把这些组件进行划分：赤兔、监控采集、OSS、metacluster、扁鹊、onlineddl等可以划分为一个角色，叫管理节点。我们从业务层去讲的话，对业务来说，实际访问数据库从业务层去讲的话，的过程是，先是负载均衡层，然后负载均衡层会做负载均衡到我们的到SQL引擎层，而SQL引擎层会直接访问到我们底层的db底层DB，db上也DB上会部署agentAgent，像。图中左侧列这些我们叫做dbDB管理节点。像右侧列如冷备中心、消息队列、多源同步等，我们一般划分为数据节点。而日志分析平台其实就是一个其他的模块，可划分为其他的节点。 像这些节点之间的也是依赖关系比较复杂，像我们的管理节点之前有讲到，像这些。比如管理节点，其实主要做的工作就是负责元原数据管理，像元原数据包括很多，比如以监控采集模块为核心的监控数据，还有、以任务分发系统为核心的任务节点的数据。第二个是我们的DB模块，DB会和管理节点有一些交付交互，首先——所有的角色不仅是除了DB节点，还有其他的节点都会向管理节点发送他的监控信息，因为都会把监控信息发送上去。而管理节点也会下发一些任务，比如说客户在前台进行一些的变更，比如说垂直扩容、水平扩容、主备切换，像这些的等变更动作也是会到实际的DB上进行的交付，也会到实际的DB进行交互。数据节点首先会像向管理节点发送数据，会和DB节点做一些交付互，比如我们最常用的就是数据库数据的备份和回档，这个就是DB的节点和数据节点进行交付。日志分析平台也会和DB节点去交付，他分析DB节点产生的日志，具体会做一些用户的日志分析、SQL分析，甚至会给用户带来一些SQL审计的功能，也会向管理节点上报他的监控信息…… 所以大家再简单看一下，其实各个组件之间的依赖关系，可以看得出来他们还是比较复杂的。其实就是因为像我们这样比较复杂的依赖关系。他，这对于我们的交付是带来一定的难处。在TDSQL早期我们是通过自身TDSQL产品团队给客户做交付。其实按照这样的要求，这会对交付的人力带来很大的要求，既即使是我们去的话，部署一个交付的环境也要两天以上。
1.2 多场景交付
TDSQL多个场景主要来源于使用TDSQL的对象是不同的，这个对象可以划分未使用TDSQL的人群是不同的，有个人使用，也有企业使用，也有第三方平台使用，包括个人、企业、第三方平台。其实这些不同的对象使用TDSQL的过程中，他们的需求和场景也是不同的。以个人使用为例，个人使用TDSQL的话，他更多强调的是我想了解你的产品，学习你的产品，体验你的产品，个人使用可能更想我能尽量的低门槛快速上手你的产品，尽量的简单。企业使用最主要的两个场景，一个是POC测试，另一个就是我们的和生产场景。POC测试是，关注我们的的是整个产品的性能和功能，包括高可用性、容灾能力、国产化适配等。从性能和功能的出发，也会带来不同的场景需求。生产其实我们更多关注的是整个交付、整个产品、整个集群，是否有高可用性，是否有容灾能力，是否有一次性的保证。我们的平台接入会带来更多的挑战，我们的平台可能会涉及到一些国产化交付的项目，国产化其实会对我们带来一些兼容性的问题，还会对我们的标准对接、接入带来一些需求。 所以由于不同的对象使用我们TDSQL的产品，就会带来不同场景的需求如何高效满足？ 我 们当时想的是我们TDSQL在交付的场景下，我们是要做多个分支去适配不同的场景，还是用一个分支去适配不同 的场景？ 当然我们是用一个分支去适配不同的场景。
1.2 TDSQlL交付质量保障：安全、合规、多层级实时扫描
第三个挑战也是，由于时间的推移，我们负责TDSQL去交付的人产生了变化。早期我们TDSQL交付是由我们TDSQL产品研发团队，我们、DBA同学去现场给客户做交付。其实在我们的产品研发团队和DBA团队，大家都是一个团队，团队内由于长期的的合作协同是有是形成了标准和质量可靠，他的交付质量也是有保证的。而随着我们TDSQL产品化，做大做强，对外推广用户规模不断扩大以后，其实会产生交付人员的不同交付人员会发生变化，当然也有一部分是我们产品研发团队直接交付。还有一部分是由我们腾讯专门的交付团队去交付，还有是由我们腾讯内部的第三方平台以及腾讯外部客户自己的第三方平台接入了TDSQL产品，他们第三方平台负责交付。还有也是客户自己本身去做交付。不同的交付实施方，他们的操作和使用的过程中就会带来一些隐患，这些隐患主要体现在以下方面如果不够标准化，则容易带来隐患，体现在几个方面： 第一个是安全的方面。比如说我们环境的安全，我们知道数据库场景是一个对内存、CPU、硬盘、LOIO的等能力，都是要求比较高的场景。之前遇到的一个case，一个客户在数据库的场景下，他（9：22）没有关，在压力比较高的情况下，由于性能问题，最终在一定的场景下带来的一些风险的问题，其实这些就是对环境的优化。其实不仅仅是这种环境优化，包括数据库进程会读大量的文献，他大的文献数继承的是系统用户的大文件数。像这些的设置，包括数据库场景对TCP的一些内核参数的优化等这些工作都是作为潜在风险来统一考虑的。像这些优化其实是作为式一个潜在的风险去考虑的。 第二个是监控方面。对整个集群、进程、机器的监控，提到监控还有一个以及自动的拉起，有很多即机械机器级别等的故障，故障之后一个，进程快速恢复的能力，其实要考虑到完善的自动拉起的体系这些都要作为完善的体系来考虑。其他还有比如一些定时任务，比如说包括定时去清理一些日志文献，清理一些历史上的数据，否则磁盘就会撑满的情况，这在生产的环境上也是风险很大的。还有我们最后是如何保障整个集群的高可用性、容灾性、（10：56）能力。刚才说到的是不同的实施人可能会带来不同的风险，其实除了实施人以外，还有发布的版本也需要控制。有的时候我们是作为第一方去交付这个产品，有的时候我们有外部的客户，他们的平台会交付，不管谁去交付，这个版本是否是一个历史版本，这个版本是否会有一些历史的问题和隐患；如何杜绝这些潜在的旧版本带来的隐患，检测到这些版本的漏洞等等方面，也是我们交付质量的一个挑战都是交付质量体系中需要解决的问题。 其实我们TDSQL交付质量服务和保障就是围绕着上述的一些各方面问题方面，实现由在不同的实施人、实施方去交付我们TDSQL的产品下，都能保证我们TDSQL的投产的质量。这是我们在做的一个事情。
1
TDSQL自动交付方案：全球灵活部署、实时巡检，最快9分钟
刚才也说到TDSQL的交付过程中遇到的一些挑战，我们针对这些上述的挑战，TDSQL沉淀出了一套TDSQL自动化交付方案。
2.1 自动化交付方案规划
这是TDSQL自动化交付方案的架构图：
刚才说我们TDSQL是基于一个分支去做的来实现多场景、复杂关系下的自动化交付的，其实也可以说是基于三个分支去做的。我们TDSQL内核包，当前有三个分支，是：基于CPU的多分支进行发布，当前支持X86、arm、power。其实在我们TDSQL对客户的发布包中，一个包自动的集成了不同CPU版本的TDSQLpocketpacket，是——以ansible组件为基础，加上了条件检测、操作系统调优、环境依赖的解决、安全规范、兼容性问题，我们对外做的是TDSQL私有云标准的发布包。像这个包我们是，可针对于客户不同的场景，刚才说到的不同场景和不同的环境做的适配。
TDSQL的组件我们刚才分为四个角色，如果想要快速的交付TDSQL集群，大家只要搞清楚一件事情，打个比方说就是把不同的鸡蛋放到不同的篮子里。鸡蛋其实就是我们说的是指这些组件，分为这四个；篮子就是我们准备的机器，可以是虚拟机，也可以是物理机。 首先首先说一下我们的个人体验的环境，个人体验的环境刚才也说了，在这样的环境下可能：个人体验环境更注重的是较低门槛比较低，其实在这里我们在这里我们只需要一台虚拟机的配制配置就可以达到这个目的。我们会然后可以把管理节点、DB节点、数据节点和其他的节点都部署在这台机器上。当然在体验的环境下，数据节点和其他的节点，这两个功能根据机器的配制来看，我们可以不进行部署。 在测试环境：该环境换机下注重的是性能、功能。 首先从管理节点来看，其实管理节点提供的是元原数据的管理和任务的分发功能，他对于性能要求不是很强，他其实要求的是一个稳定性和容灾的能力。在测试环境可以稍微弱化这个要求，我们，比如可以准备一台或者三台的虚拟机，配置4C/8G普通磁盘就可以了，配制4C/8G；在测试环境下，我们要去要做DB节点的话，其实在DB节点我们要考虑到TDSQL的性能问题，这里我们就会推荐一个使用物理机；我们TDSQL做进行性能测试的时候要求一定是SSD盘，否则我们的性能数据是没有任何参考性的。——这也是由数据库的场景决定的，因为SSD和普通的磁盘，一个是随机，他们方面主要表现在随机读写的能力上，的差距会比较大一点；数据节点和其他的节点方面，如果有一些客户可能对测试他的功能要求不是那么强没有那么强，他就可以不部署这些节点的功能，而如果我想体验一个完整的TDSQL的功能，则我需要准备这些机器，以体验完整的TDSQL的功能；如果我们要部署数据节点的话，我们可以选择一台机器或者三台机器，虚拟机，以及准备大一较大容量点的磁盘做一个数据节点；其他的节点，这里我们提的是比如负载均衡和日志分析平台，日志分析平台的作用刚才也说了，是做一些SQL审计，DB日志分析等等。其实我们TDSQL的负载均衡会比较灵活，他是在我们的位于SQL引擎层上的上一层，这里推荐的有开源自身的LVS，当然也有很多客户会使用的F5。最后，像这些以上环境我们的推荐是部署两节点来实现，做一个容灾能力。这个其实就是总体而言，为了保证测试的性能，测试环境的要求，要求最多的就是DB这个节点模块，保证测试的性能。 最终是大家最关心的生产环境的要求，我们这里要求的是：生产环境中要求管理节点，可以部署在三台或者五台是虚拟机，但三台或者五台，最好是跨三个机房，比如说“1+1+1”的模式或者“2+2+1”的模式，因为我们的原元数据集群是一个基于多数选举的机制来保障高可用，如果是只有两个机房的话，则会失去了他本身容灾的意义，因此我们建议生产环境这里是中部署三个机房。DB节点生产环境更推荐的是NVME接口的SSD，因为传统的SSD和NVME的SSD可能体现他的在接口性能上，会有比较大的性能差距。这里而数量上我们推荐的数量是3*N台，其实——事实上这个是我们要去评估的生产环境TDSQL集群的数据量。因为我们，TDSQL是一个分布式的数据库，他的数据量级可以根据用户是根据你的机器数量实现做一个水平拓展扩容。 举个例子，比如说我们假设客户有3T的数据，如果（19：39）单台物理机是1T的话，一个（？）set内做的是一主两备三个节点，我们此时就需要三个（？）set，三个（？）set可以承担3T的数据量，同时会有两个副本复本的冗余，我们DB节点的这些数数就需要9台这样的机器，这三个set会组成group shard。数据节点也是的机器也是推荐物理机，这里数据节点在同时在生产环境也需要考虑容灾能力，我们因此推荐是三台机器台机器以上，这就不推荐1台机器了，考虑数据节点的容灾能力。此外，需要的是一个高性能磁盘，来保证回档和备份的效率；最后这边也是推荐物理机，访问链路上接入层是非常重要的一层，我们强烈推荐推进物理机，来提高他的稳定性。
2.2 TDSQlL自动化交付特性与要求
刚才其实也讲到了我们前文讲到了TDSQL不同的组件，他分成不同的层次，我们以及我们怎样去管理这些层次等等其中的层次逻辑。在TDSQL真正交付过程中，为了保证交付质量，结合金融级场景的安全合规、高可用容灾考虑，我们沉淀出一些基本要求和特性： 1.网络：离线部署无外网依赖，机器互通； 2.存储：支持单磁盘、多磁盘和raid； 3.冷备中心：支持hdfs和挂载式分布式存储(如ceph)； 4.机器分布：支持跨机架和跨机房上架服务器，支持多种机器分布模式下的高可用容灾； 5.CPU：在国产化趋势下，目前机器CPU除了适配x86，还包括arm、power，而且首要推荐以上其中一款； 6.操作系统：适配支持centos、ubuntu、以及包括国产化操作系统在内的诸多主流操作系统 。
其实我们在真正去交付TDSQL的时候，用我们交付方案去交付TDSQL的时候，有一些注意点大家也要注意一下。 第一个是我们TDSQL的网络是没有外网依赖，因为很多客户，像一些金融和证券的客户是不能连通外网，我们在TDSQL的发布包里已经解决了这个依赖。 我们只需要一个网络互通即可，也没有网端的要求。 第二个是存储，TDSQL既支持读取物理机上的单磁盘，也支持读取多磁盘，当然也支持我们多磁盘的raid，然后读取这个raid的路径，这些都是可以的。 冷备中心这一块我们TDSQL支持两种，第一种是hdfs，第二种是远端挂载式的分布式存储，比如说ceph的文件系统，他是一种挂载式的文件存储，比如说以前的NAS、NFS这些也算。 我们建议TDSQL要去跨机架和跨机房上架服务器，我们是有做TDSQL的IDC管理，如果按照我们规范的要求去做，你的实例满出来的时候，实例内的主备节点本身就是跨机房的关系。当前我们TDSQL支持的CPU有三种，一种是X86系列，这个是之前的主流系列，第二个是arm，arm也是我们现在很多国产化的厂商去做的架构，第三个是power，power目前的主力还是在浪潮这边。当前客户主要用的操作系统都做过适配，像centos、ubuntu、红帽等一些国产化的操作系统，这些我们都有做适配。 右边这张图上图右侧展示了我们简单的简要分布关系，其实我们就像这样的规划一样，交付过程中我们只要理清楚我们如何把鸡蛋放到对应的篮子里就可以了，即可实现自动化交付：我们先选出篮子，一组物理机就是一个例子篮子，我们就随之把一组的组件DB节点放到这个篮子里，其实这样就完成了自动化的交付。
2.2.1 灵活交付
当然这边其中有很多的细节，客户最关心的问题是我该怎样交付这个产品，大家要做的事情就是规划，其实大家填写的配置客户要做的，是自由决定模块的机械机器分布和集群规模。我们，TDSQL可以通过一个模块之间填写的数量不同的数量差异，会自适应地做但点做出单点方案和多节点高可用容灾方案。这个过程是用户在操作上是无感知的。 举个例子，比如说刚才说的TDSQL是支持HDFS作为做他的冷备中心，如果我们HDFS选的是一个节点的话，他系统会做的一个HDFS的一个但点单点方案。我们知道HDFS的但点方案主要是由（25：38）组成。如果我们这边填的是三节点的配置规划，他它会自动感知到我要做的是一个高可用的容灾方案。当时HDFS主流的用的高可用容灾方案，一个是QJM，一个是基于（？）做的方案。我们当前是用是基于的QJM的方案，他其实包含了（26：07）高可用的方案方式。
2.2.2 简单高效：整个部署过程最快仅需9分钟
刚才说了TDSQL其实除了我们要做一个做完部署规划，把怎样的组件放到哪一组机器上，我们要做的，第二件事情是解决各个组件之间的一些关系，包括一些兼容性的等问题。我举个例子，这次如果部署的TDSQL环境是基于ARM国产服务器的操作系统的国产化的环境，是急于arm平台的操作系统。我怎样我们如何通过一个交付的物料包去适配不同的环境？其实秘密就在这个配置文件里： 1.用户无需关注TDSQL较为复杂的各模块的互相依赖和配置管理问题，只需要根据实际，填写变量文件配置即可； 2.用户填写一个机器规格配置文件、一个变量配置文件，填写后可以适配操作系统和CPU实现一键自动化交付； 3.操作简单用户可独立完成，自动化部署命令可重复执行，在北京信通院机构现场对TDSQL产品化的测试显示，整个部署过程最快仅需9分钟。
2.2.3适配与集成：国产化、全栈式
客户就可以通过填写我们的配置文件。其实已经做了一些适配，包括对我们的内核包，首先对我们的TDSQL的内核包是出了不同CPU架构的内核包。还有对我们交付逻辑上做了对各个操作系统和CPU的兼容。其实客户无须关心TDSQL比较复杂的模块之间的依赖和配置关系，只要根据实际情况填写变量的配置文件就可以了，填写完了以后就可以执行我们交付的发起命令，可以一键自动化交付。 整个交付过程是非常简单的过程，之前我们有对整个TDSQL的自动化交付过程进行测试，当时是在北京的信通院的一个机构，对TDSQL产品化的交付进行测试，整个过程在搭建TDSQL核心交付场景的情况下，只需要9分钟就可以完成一个交付的场景。其实到这里我们核心的交付流程已经给大家介绍完了，其实很简单，我们根据自己的需求把不同的鸡蛋放到不同的篮子里，将不同角色的组件放到我们准备好的一组一组机器上，这是第一件事情，填写规划的配置文件。第二件事情是填写依赖的变量文化，包括一些环境和操作系统CPU的变量文件，以帮助我们自适应的调整当前的环境是怎样的，去调整一些交付的逻辑。第三个我们真正执行交付命令，这个步骤都一键化的。
刚才有说到我们TDSQL在国产化方面也做了很多工作，当前国产化已经成为一个趋势，TDSQL在国产化适也做了很多工作，从我们底层的服务器到存储器、操作系统、CPU、行业软件、数据库软件等，都是在相关部门指导下国家的领导下进行了联系与各个厂商合作实现从下层到上层全方位的做国产化适配。在国产化的浪潮下，我们TDSQL作为一个腾讯自研分布式数据库，他作为一个优秀的国产化数据库，其实我们也是义不容辞的担当了我们国产化的责任。我们当前其实是从CPU、操作系统都去做兼容，操作系统刚才有几个没有说到。centos、ubuntu、suse，像这几个可能是大家常见的主流操作系统，包括腾讯内部的操作系统tlinux是腾讯内部的一个操作系统，以及中标麒麟、银河麒麟、UOS是等常见的主流国产化操作系统，我们都有TDSQL都完成了适配。除了我们列出来的这些CPU的适配、操作系统的适配，适配全系国产操作系统，TDSQL同时已相继完成对全系国产芯片，全系列国产服务器等的兼容适配工作。而在完成适配工作的同时，腾讯也提供了对应的技术服务，帮助行业用户更好地迁移到国产基础技术生态当中。刚才提到有很多服务器CPU的一些硬件厂商做国产化，我们和浪潮也做了一些测试和认证，并且拿到了浪潮的认证，除了浪潮的以外，我们还在很多其他的国产化的客户项目中，可能更多偏向于政府和国企相关，也同时并行做这些国产化的项目，并且已经拿到了一定的成果。这个些是我们对国产化的方面的工作。 技术服务生态方面，TDSQL其实不仅可作为一个独立发布的产品，在TDSQL发展的历程中，也其实他已经被很多其他的很多平台厂商各种和合作伙伴接纳，包括腾讯内部主要是的TCE、Tstack、MDB架构等。TCE是腾讯云基于金融级别的一个平台，TDSQL也是和TCE进行高度的集成，包括从我们的在部署方案、告警、用户权限等等各种维度和TCE进行了深度的集成，可为金融政务机构提供全方位的PaaS基础技术服务，在完成高性能的分布式架构转型升级的同时保障金融级稳定高可用。Tstack和MDB也是我们内部的一些平台，除了我们内部的平台，还有很多客户自己的一些平台。除了客户自己的业务在使用TDSQL以外，有些TDSQL许多客户合作伙伴是做一些的行业的解决方案，在他们的解决方案中也集成了TDSQL，把我们TDSQL的能力输入到他们自己的平台。
2.2.4 安全保障：秒级监测
TDSQL在发展中对交付场景做了许多优化： 1.条件检测： 首先会自动对规划的TDSQL集群下的所有机器做前置检测，包括机器时间同步、时区一致、端口占用、系统默认sh、机器规格等做检；
2.环境优化：针对关系型数据库场景，对系统50处左右进行针对性调优，并解决一些基础的依赖； 3.机器秒级监控：大部分的监控平台都是基于分钟级的，对于金融级数据库这种敏感场景，分钟级的监控是不够的。 我们在交付的场景下也做了一些优化，首先我们会对整个TDSQL规划的集群下的所有机器做前置检测，包括常见的机器的时间同步、机器的时区、端口占用、系统默认sh、机器规格。我们会对环境进行优化，刚才有提到一些操作系统的内核参数，针对于关系型数据库场景，比如说TCB的一些优化，像一些内存参数的优化，其实我们做了一些调优，并解决了一些技术的依赖。还做了一个秒级的监控。其实客户自己的监控平台，包括我们本身给客户提供的监控中心，大部分的监控体系是基于一个分钟级的，但是数据库这样的场景比较特殊，其实很多的问题在分钟级的监控下，问题的现场就会丢掉，不能暴露问题的本身。所以我们针对这样的场景做了提供了秒级的监控，我们做了几个维度，有包括针对机器的IO、CPU、网络、内存等等多个维度。
2.3 多集群下的自动化交付
前文刚才讲的是我们在TDSQL在单集群下的交付场景和交付细节，之前在架构课上的时候我们也介绍了TDSQL多集群的交付方案。其实接下来介绍在多集群下的，我们来看一下交付具体是怎样进行的。
“同城两地三中心”部署体系
“
同城三中心”架构顾名思义：
在一个城市有A、B、C三个机房，TDSQL仍采用“一主两备”结构，很显然我们需要将三个数据节点分别部署在三个机房，其中主节点在一个机房，两个备节点分别部署在另外两个机房。
同城双中心的架构下我们是有两套集群，第一套集群是蛇口这个集群，我们是交付一套集群。
然后在观澜集群是交付另一个集群。
我们在两个集群之间做了一个异步复制，这个是同城双中心。
第二个是“同城三中心”，我们是架构的部署下，是在一个大集群内，在这个数据库实例下，我们数据库实例使用使用的是同IDC异步、跨IDC强同步的方式，然后在这边上海会有一个强同步的实例，实例之间会做一个DCN的复制实现金融级高可用容灾。
“两地三中心”架构顾名思义：
在一个城市有A、B两个机房，另一个城市有C机房，在第一个城市中TDSQL数据库实例采用同IDC异步、跨IDC强同步的方式，我们需要在第一个城市将四个数据节点部署在二个机房，其中主节点和一个备节点在一个机房，另外两个备节点在另一个机房。
并且在第一个城市和第二个城市的数据库实例间，采用的是异步复制，保障金融城市级高可用容灾。
“两地四中心”部署体系
“最后一种就是两地四中心”的架构，是一个自动化切换的强同步架构，我们也是两个实例，第一个实例是深圳的实例，我们是分成三个IDC。
举个例子，一个是福田，一个是蛇口，一个是观澜，一个实例跨三的IDC，我们做的一个强同步。
第二个实例是在上海，在这两个实例上也是用的DCN做的实例之间的同步，对任何数据中心及故障都能30秒内切换，并且数据零丢失，性能也稳定可靠，对业务和用户来说是实现更高的可用性和更低的成本。
1
TDSQL质量保障服务：全生产流程自动化巡检
刚才有讲到了我们TDSQL的一些交付的场景，交付的需求和一些做TDSQL国产化和兼容性一些特性的交付考虑。其实在最重要的地方就是最后，最重要的是我们如何保证TDSQL的交付质量，不仅是交付质量和服务的质量，这一块我是单独拿到最后一章给大家介绍。
首先我们TDSQL的交付质量，我们是通过一个叫自动化巡检的方案保证。TDSQL自动化巡检的方案我们是通过三个维度控制我们的保障交付质量。
1.监控指标分析
第一个维护维度基于是依赖TDSQL现有的监控中心，从我们现有的监控体系中去做一些进行相关指标性的分析，包括。当前我们这个指标性的分析也分为两个维度，第一个维度是当前时刻的指标分析，第二个维度是和历史时刻的指标分析。什么意思？其实这里就会涉及到一个问题，我们当我们要在验证一个集群，一个TDSQL的集群是否有问题的时候，我们往往除了要分析此时此刻的集群是否存在有一些异常，是否有一些和告警，是、是否存在有一些资源负载过重等等情况。其实往往，还需要分析历史性的问题，比如说在历史我过去在历史七天中各个指标的曲线是如何的。为什么要分析过去历史七天的指标曲线？举个简单的场景案例，我这边例如一个场景是在每天下午三点到五点的时候，是业务高峰期，在这个业务高峰期的期间，我可能有很多业务的慢查询，甚至有一些慢查询带来的性能的问题。系统我如何监控在历史某个时刻出现的问题？比如说我那么我们发起自动化巡检方案的时候，我是比如是上午8点钟发起，其实上午8点钟是我的，适逢业务低峰期，此时是发现不了问题的，所以我们需要对历史上的指标做进行分析。 方案中具体看一下我们有分析的哪些指标，我们从哪些维度进行分析。我们包括检测前台连通性如何，我们、确认告警有没有正确的发送到客户手中，我们看一下实例的复制方式。我们的TDSQL有几种实例的复制方式，有强同步，有异步，也有同IDC异步、跨IDC强同步的复制方式。其实我们在复制方式之间又很多的选项，比如说我们强同步有可推化的选项，其实当强同步发生了可推化以后，他其实是一个潜在的风险，我们要把这种潜在的风险弄出来。还有实例免切节点，当发生主备切换的时候，会产生一个免切节点，如果有这个免切节点的话，我们就知道之前历史上发生过主备切换，会阻止接下来的自动主备切换方式等，影响我们整个集群的高可用性。 慢查询是很多性能问题，甚至是一些线网问题比较常见的原因，备延迟，HDFS使用率，还有告警策略对比。其实监控主要分为两个方面： 第一个是监控指标的采集、上报、搜集，这是我们的监控中心在管负责。除了我们拿到这个监控的数据，我们要对这个。 第二是对监控数据进行分析，我们对我们，并对认为异常的分析进行告警，其实在这些。分析和告警下，就会有一个过程中会遵循一定的策略的问题，我们认为——怎样的监控数据才是异常的，才有必要告出来告警的？当然我前们TDSQL维护了一套私有云的告警模板。我们，也给客户提供了一些可配置的、定制化的选项，客户可以根据自己的实际情况进行告警策略的修改；同时提供基于实践经验积累的告警策略对比，以防用户做出不合理的修改，暴露告警策略的潜在风险。 在这个维度，TDSQL多源同步等模块可以对数据同步情况进行监控，他们当前同步的稳定性、同步的性能如何，等其他就是各个模块的告警的监控指标。但是为了以防客户误操作或者不合理的修改，我们在这边也会对告警策略进行对比，将一些明显不合理或者极为不合理的改动暴露出来，提示给客户，告诉客户这条告警策略什么时候被改过，我们建议这边告警策略是有风险的。
还有我们在TDSQL的同步方式上会有监控，DCN的同步和多源同步的监控，他们当前的同步的稳定性、同步的性能如何，其他就是各个模块的告警的监控指标。第一个维度就是我们说的从监控数据的角度来进行分析，第二个维度相当于是对第一个维度的补充，第二个维度就比较多，我们首先分析的是机器级的，我们不是采的监控数据，是直接真刀访问服务器后台，我们会对机器基的LO、CPU、内存、磁盘、稳定性这些进行检测。稳定性就表现在有一些服务器可能是一些老服务器，比如说已经运行五年了，我们要告知客户运行五年的机器可能有风险，还有一些机器可能会经常重写，我们告诉客户从各种信息里面看这台服务器本身的稳定性是有问题的。我们从进程级去考虑，我们关键要看的是进程本身的情况，一般进程是有守护进程和工作工程组成的，工作进程是否是正常的，守护进程是否是正常的，当前进程开通的端口是否可以正常的访问。除了进程本身的问题，还要看一下关键进程的配置文件的问题，其实很多的配置文件关系到我们整个TDSQL集群的可用性。
2. 集群环境
还有我们在TDSQL的同步方式上会有监控，DCN的同步和多源同步的监控，他们当前的同步的稳定性、同步的性能如何，其他就是各个模块的告警的监控指标。第一个维度就是我们说的从监控数据的角度来进行分析，第二个维度相当于是对第一个维度的补充。第二个维度就比较多，我们首先分析的是的分析是机器级的，我们不是通过采的监控数据，是直接真刀访问服务器后台，我们会对机器级基的LIO、CPU、内存、磁盘、稳定性这些等进行检测。稳定性就表现在有一些服务器可能是一些老服务器，比如说已经运行五年了，我们要告知客户运行五年的机器可能有风险，还有一些机器可能会经常重写，我们告诉客户从各种信息里面看这台服务器本身的稳定性是有问题的。我们从进程级去考虑，我们关键要看的是进程本身的情况，一般进程是有守护进程和工作工程组成的，工作进程是否是正常的，守护进程是否是正常的，当前进程开通的端口是否可以正常的访问。除了进程本身的问题，还要看一下关键进程的配置文件的问题，其实很多的配置文件关系到我们整个TDSQL集群的可用性。
我们会对一些关键的进程进行扫描，防止客户手动的误改或者人为的删除修改一些关键配置错改、误改。除了机器级和进程级，我们还会进行实例级进行一的些定制化的扫描，其实这个就体现在实例的体检模块。之前我们的课程也有分享过扁鹊的工具，实例的体检就是TDSQL智能诊断分析平台“扁鹊”工具的接口，可以为实例提供他会给我们从一个实例，从运营、开发、性能等各个指标做一些的系统性的分析。第四个维度是 集群级层面，我们会关注从低到高，最高就是集群性的维度，在集群性的维度下我们要关注的问题，这个集群各个机器之间是否是同步的，时间是否是同步的，TDSQL是要求各个机器要时间同步。还有、实例下源元数据集群是否是有备份的，他、的备份是否是正常的，以及我们这边会手工触发此时此刻的源数据集群的备份。我们会在四个维度对第一个监控项从四个方面做一个补充的扫描等。
3. 自动化演练
在我们以各个维度去扫描当前集群没有问题的情况下，我们还是要从结果出发TDSQL还会从结果出发，我们会对整个集群做一次P0级别（最高级别）的自动化的演练，演练的场景就是我们正常运营和管理的场景。比如说，包括购买实例、创建用户、用户授权、创建库表，在这个库表上做一些表结构的变更。在这个实例上我们会做一些、水平的扩容，做一些、垂直的扩容，把他扩到不同的机器上，还会做一些、重做备机，模拟一些重做备机的场景，还有、慢查询入库，是否慢查询，我们可以在制度的分析页面上可以入库，还有、备份和回档，我们会模拟把当年的实例做一次手动的备份，并且拿这个备份是否能回档到之前我们备份的点以及保证整个回档和备份的过程，他的数据是一致的等。最后我们系统会对购买的实例进行删除，他其实实现了闭环，对P0级别的场景做了进行闭环的自动化的演练。
总结来说，TDSQL自动化巡检方案 我们从这三个方面，从我们的指标级，从补充到整个集群环境的进行扫描，以及我们的通过自动化演练，这三个维度确保我们整个交付的集群是安全、稳定、可靠、高可用OK的，并且会生成一个我们的质量报告到客户以及我们TDSQL的产品研发团队去参考。
除了我们TDSQL的质量保证除了技术上的保障方案，我们还会做一些产品化的TDSQL同时沉淀了大量产品化工作，帮助用户快速、方便地使用分布式数据库。
比如说当我们的客户从0到1，他是完全的交付。从交付以后从1到多的话，就是运营和使用的过程了。在这些交付和运营的过程中，我们又会带来很多的问题，比如说怎么交付？刚才我们只是讲了一些交付的特点，交付的概念，怎么去操作呢？其实我们也会做一些产品化的文档的输出。第一个文档就是我们大部分的交付、运营在我们TDSQL的产品文档上，他还包括我们的巡检，刚才我们说的自动化巡检的方案，还有故障处理。当遇到一个告警和故障，我们怎么样去处理，怎么样解读这个故障还有一些前台的操作指导，我们告警的异常解读，我们的日常变更扩容等等，他是在我们的产品文档上。如果我们想做一些POC的测试，我们要对一些场景进行适配的话，可能要考虑到业务侧的开发问题，我们有输出TDSQL最佳实践的开发指南。还有对标准化测试这样的情况下我们输出我们POC的用例，提供了性能的用例、功能用例、高可用容灾用例。 我们也会对客户的信息进行定期的维护，首先我们会对客户定期发起一个集群的巡检，通过这个巡检我们可以保证客户当前以及历史一段时间内，客户的环境是没有问题的。刚才也说了巡检主要进行功能性和容灾性的演练。通过自动的我们的定期的巡检，会搜集到客户的环境和版本信息，我们会把这些信息更新到我们的客户管理系统中，更新的信息是用来之后做客户私有云的版本推送。在我们的管理系统内部会自动进行扫描客户当前的版本，如果我们扫描到有建议客户要升级的版本，我们则会自动推送到客户代表，然后由客户代表推送推动客户升级。
最后是跟我们客户最后，在客户日常运营、日常变更相关的中，可能大部分运营面临的大部分问题是怎么去扩容、升级、处理告警？怎么扩容？我们TDSQL会对各个节点的扩容有一个提供了自动化的扩容方案，可以一键的扩容。同样升级也是提供了前台化一键操作的功，功能，既可以进行点对点的升级，也可以进行整个集群的批量升级，这个也是我们有一个前台化的升级工具。TDSQL的高可用性一方面在于自身的弹性架构和容灾能力，以及数据强一致性。
可用性方面TDSQL提供了自动化告警处理方案告警其实TDSQL的可用性一方面在于他自身的架构和容灾能力，在于他的强浓度告一致的特性，还有我们的监控系统。在我们的监控系统中难免会产生告警的问题，告警问题处理及时与否，处理的方式其实是影响到我们TDSQL集群的可用性。其实在这个问题上，我们自身也是做了很多探索，我们既要平衡客户实际的告警处理、告警解读的工作量，也要帮助客户保证整个集群的质量。我们这边提出了一个自动化告警分析，将一部分的告警可以自动化的处理，减少客户自己线网运行的工作量，可实现自动化告警分析，并对部分告警自动处理，减少现网运营的工作量 。 刚才我们是以上我们以交付为核心介绍了我们TDSQL在历史过程中遇到的几个交付上的挑战，和针对这些交付挑战，我们提出的了我们自动化的交付方案，这些交付方案的特性是什么，我们如何完成我们的交付，我们在这个交付上可以使用的特性，他的兼容性场景有哪些。以及最后我们对整个TDSQL标准化交付的质量和客户的服务进行了提供了一系列的机制和能力的提升机制和能力方面的提升，关于更多我们TDSQL的细节，可以关注我们TDSQL数据库公众号，我们在这个公众号会有一些定期的推送文章跟大家分享。
PartⅤ Q＆A
Q：TDSQL支持数据库离线备份吗？ A：我们TDSQL支持多种备份方式。我们，可以基于物理式的（56：22）的备份，也可以基于逻辑备份。但是我们备份的介质是备份到HDFS或者挂载式的存储上。整个备份过程其实是在备机上进行备份，备份是，不会影响到我们正常的业务访问，也不会对业务访问的性能带来影响。 Q： TDSQL的告警信息如何接入短信、语音、邮件告警平台？
A：我们TDSQL的告警接入是比较灵活的，首先我们TDSQL的告警信息是一个文本的形式，他可以发送到任何的平台，我们当前已经适配过的客户已经适配过的告警接入方式有很多，比如说客户有HTTP接口的告警平台，也有一些其他接口的。其实我们只要根据我们的指引手册，把我们的告警信息以你根据客户想要的接口，比如说HTP，我们就发一个HPT的TDSQL可以对应地发一个包，包含了我们的告警信息，发到你的告警接收平台就可以了。怎么样告警的接受介质？其实短信、语音、邮件，这个还是由每个客户自身的告警平台的能力有影响，比如说自身客户已经有了一个微信的告警接收的平台，此时我们TDSQL是接入到客户微信的告警接收平台，对于不同的告警接收平台，TDSQL我们自身针对不同的语音、短信和邮件分别做了不同的告警信息发送。
特惠体验云数据库
↓↓更多惊喜优惠请点这儿~
https://cloud.tencent.com/act/pro/MySQLtry?fromSource=gwzcw.3180840.3180840.3180840&utm_medium=cpc&utm_id=gwzcw.3180840.3180840.3180840
网页题目：直播回顾|TDSQL的交付-创新互联
本文URL：http://mswzjz.cn/article/ccposg.html