腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，3月26日郝志刚的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。
关注“腾讯云数据库”公众号，回复“0326郝志刚”，即可下载直播分享PPT。
瞬间从亿条SQL中找到问题所在：TDSQL自动化运营体系_腾讯视频
“赤兔”平台是TDSQL提供的产品服务之一，它从管理员视角提供TDSQL的全部运维功能和上百项数据库状态监控指标的展示，让数据库管理员日常90%以上的操作均可通过界面化完成，同时更方便定位排查问题。
扁鹊系统是TDSQL面向云市场推出的一款针对数据库性能/故障等问题的自动化分析并为用户提供优化/解决方案的产品，它提供包括数据采集、实时检测、自动处理、性能检测与健康评估、SQL性能分析、业务诊断等多种智能工具的集合。
在数据库日常应用中，常常会面对如存储容量和性能需求急速增长带来的性能等异常问题。对于引起数据库异常的问题SQL，这时扁鹊可以通过一键诊断分析，帮助用户快速进行智能检测和分析，快速将问题定位，同时给出优化建议。在扁鹊的帮助下，DBA可以从日常繁杂的数据库运维工作中解脱出来。在支持腾讯会议需求量暴涨，数据库遇到性能问题过程中，扁鹊智能运维曾帮助DBA快速在亿条SQL中定位到了问题SQL，并提供优化意见，将数据库的性能问题及时扼杀在萌芽当中。系统显示，经过优化，99%的SQL都消除了性能瓶颈。
“扁鹊”在迭代演进过程中沉淀了腾讯数据库实践中积累的海量运维规则知识库，可帮助DBA迅速排查日常常见异常，而结合腾讯云海量数据+机器学习能力，扁鹊可对未知问题进行主动分析检测，并告知客户，尽可能将大部分异常在发生之前就发出预警，将风险降到最低，提升DB持续可靠地服务各种不同业务场景的特性能力。
“赤兔”和“扁鹊”这一套组合拳既满足高星级业务的精细化运维，又能轻松应对大量的普通数据库运维需求，更好地帮助用户降低运维成本。
大家好，我是腾讯云TDSQL高级DBA郝志刚。今天分享的主题是TDSQL自动化运营体系。听过我们前面系列课程的同学应该对TDSQL的架构原理等有比较详细的了解。而回到现实的工作中处理各种问题，还是要埋头解决各种运营问题。所以今天我们介绍一下TDSQL的自动化运营体系，看TDSQL自动化运营体系能为广大DBA或者运维人员带来什么。事实上TDSQL自动化运营体系可以帮助DBA的工作更放松一点、轻松一点，而不是想象中比较苦、比较累的工作，希望对大家有帮助。
我演讲分为四个章节：
第一个章节是TDSQL自动化运营体系，包括架构、支持的功能特性等。第二、第三章会基于DBA的两大事务体系——日常处理的事务，以及故障分析类事务，结合一些典型案例来介绍TDSQL自动化运营体系是如何帮助大家高效、便捷、自动化地解决这些事务问题的。第四章做简单的总结。
第一章节主要括三部分内容，一方面是对DBA日常工作进行梳理。第二介绍TDSQL自动化运营平台“赤兔”。第三介绍数据库后台如何实现自动化运营，介绍背后原理性的东西，帮助大家理解TDSQL是如何怎么实现自动化运营的。
大家看到这个图会非常烦躁，这是日常DBA要处理各种问题：比如一个业务要上线，需要创造一个实例；比如机器要扩容，需要紧急申请权限；不小心弄错数据，需要赶紧回档；或者是表结构需要变更………这张图里就是DBA日常要面临的复杂量大的问题处理。从中我们也可以总结出两个特点：第一个每个DBA对于处理这些都会有一套自己的逻辑。比如我做一个DDL，可能这个DDL可以这么操作，另外一个DDL要用另外一个工具，这些操作的方法不够标准而且不够稳定；也许今天用的这个方法明天用就不灵了——它的稳定性难以保证。
第二，我们做这个事情需要很多后台操作来配合，后台操作对于DBA来说非常频繁。一方面可能习惯于这种操作，但是这个方式带来的风险会比较大，我们敲下一条命令的时候有没有感觉很心慌，它的后果是什么？以往没有统一的平台来保证做这个事情是非常安全的。
所以TDSQL致力于解决这两个难点：
第一个是流程要标准化；
另一方面是效率提升。
我们不需要后台操作，而是前台点一点就可以解决DBA的大部分事务。
DBA日常工作大致可以分为两类：一类是日常类事务，另一类是故障类事务。日常类就是平时业务的各种需求，DBA通过一些脚本、自动化工具可以做的事情；故障类就是比如我们遇到一个难题，“数据库连不上”，“数据库特别慢”，需要看一下为什么。
我们简单看一下日常类。除了刚才提到的创建实例、DDL在线变更，还有实例下线，这个虽然不常用，但是数据库运营较长一段时间中也是可能遇到的。此外还包括业务停运了将数据库清掉然后存放其他数据，还有参数调整和调优——我觉得这个超时时间可能设得不太合理，业务侧要这么设置更改，等等。而扩容更是在所难免——业务数据量特别大，或者请求量特别多，实例撑不住了就要扩容。还有读写分离，还有重做备机、备份手工切换、在线SQL……
故障类指的是问题诊断类型：业务说DB连不上，帮忙看一下为什么；还有监控预警——如果DB有异常我们要自动发现这个问题，不然非常被动。系统分析——可能数据库运行慢了，但是还不影响使用性，看一下能不能有优化的空间；自动容灾切换就是保证用户的高可用；数据回档防止数据误删；日常巡检是针对性地发现一些潜在问题。
以上大概介绍了一些事务，但是这些并不是说完全代表TDSQL自动化运营平台支持的功能，这只是简单列举了几个比较重要的案例。言归正传，这些事情TDSQL是怎么自动化完成的？TDSQL把这些功能呈现在数据库运营平台“赤兔”上，所有用户包括DBA，在赤兔上就可以完成以上所有的操作，而且全是自动化的；赤兔又会和TDSQL打通，赤兔会把流程以任务的形式发给TDSQL，TDSQL集群会自动帮用户完成这个事情，并且反馈给赤兔，然后用户就可以看到这个操作的结果。
所以赤兔平台整个流程就是把每一项日常类事务、故障分析类事务封装成一个个自动化流程，然后打通用户的需求和TDSQL后台操作的流程，帮助大家能够利用平台高效安全地解决日常工作中遇到的问题。
接下来介绍TDSQL后台如何完成自动化流程处理，包括介绍其中的自动化处理流程以及核心的模块。
这个图如果大家听过前面一系列的分享应该是有所了解，但是今天这个图和之前的架构图稍微有一点不一样，我们依次看一下：
用户的请求在赤兔平台以任务的形式发给后台的OSS（OSS是TDSQL对外的接口），OSS又会做一个分发，把一部分的任务写在MetaCluster里面。MetaCluster写成任务之后左边有scheduler和onlineddl两个模块会监控监听各自的任务节点，有新的任务就进行处理。
OSS把问题分析类型的任务会直接发到扁鹊——TDSQL自动化运营体系中的智能分析平台。扁鹊负责问题智能分析，它利用监控采集的数据——比如DBA的状态、主备切换等TDSQL监控数据，以及扁鹊还会实际访问数据节点，采集它认为需要支撑分析实例的数据。扁鹊在TDQSL框架里是一个新的模块。另外还有一个模块是onlineddl，它专门独立处理DDL请求。除了这两种请求类型，其他的任务基本由scheduler模块完成。
右下角有一条线是Agent——每个节点都由Agent进程模块来监控甚至完成辅助性动作，scheduler无法直接接触所以Agent也会辅助完成刚才提到的流程。它也是通过MetaCluster获取自己需要的信息进行处理，处理完之后响应反馈给scheduler甚至其他模块。
所以这个图有三个核心模块来处理日常的流程：一个是扁鹊，这个是问题分析模块。onlineddl处理DDL请求，以及TDSQL各个模块后面的角色以及任务的处理。TDSQL自动化运营流程和框架就介绍到这里。
接下来讲第二章，TDSQL日常事物处理自动化。
刚才讲过我们把DBA任务分成两类，一类是日常类，一类是故障类。先讲日常类的处理自动化，这个章节会选取两个日常非常常见的场景分析，分享TDSQL是如何解决这些问题的。
第一是重做DB节点功能，第二个是在线DDL功能，第三是TDSQL在自动化流程里如何做安全保障。
第一节重做DB节点。大家可能会想为什么重做DB节点？这个场景比较常见，虽然它不是每天都发生，但是它隔一段时间就会发生，而且这个事情也是比较重要的。比如机器故障了机器修复可能需要一点时间，机器修复之后需要重新加入集群，数据可能就丢失；或者数据非常旧，已经追不上了，我们需要对这个数据节点进行重做；另外，如果卡顿无法恢复了我们就需要对数据节点进行重做，恢复节点的功能。
这个怎么做呢？我们可以看到这样一张图：
首先系统会发起重做流程——这个流程在赤兔上进行完成，赤兔会把任务发给TDSQL集群。TDSQL集群针对这个任务有四个步骤：
1. 为什么要重做DB节点呢？因为机器上可能残留一些数据，我们需要清掉，删除限速。2. 拉取镜像。无论是逻辑上还是物理上，都需要拉过来到节点上，作为数据的基准。3. 然后是加载镜像。4. 最后是恢复同步。
可能大家在日常的运维或者是处理事情的时候都是这个流程，它基本比较符合大家的习惯。不同的是可能以往较多的是手工处理，而赤兔在这里一键就可以发下去。
整个流程做了非常好的优化：
赤兔提供了主节点保护，因为假如是1主2备架构，为了防止出错，系统限制了不能直接在主节点实施重做。此外还形成了实时节点信息，例如这个节点是不是故障状态？延迟多少？……通过这个优化我们可以实时判断是不是正确的节点。
再看重装DB步骤。第一步会删除限速，而且这个数据往往是非常大的，几百G甚至上T，所以我们要控制速度，如果快速删除会导致IO较高，而且一台机器上是多租户的架构，可能会影响其他实例的正常运行，所以要限速删除。另一方面，删除之后要把数据进程重新安装，安装的时候会自动拉取DB参数。因为DB在运行过程中可能很多参数已经被改动，安装之后的参数要保持和原来的参数一致，所以安装过程要自动拉取。而且，有时候参数列表会很长有十几个，手动操作是一个容易失误且工作量极大的事情。
另外，拉取镜像步骤，这是耗时最长而且是比较重要的一步，这里面做了三个优化：第一是选择最优的数据源，比如像一主几备的情况下，每个备机都有延迟状况，我们可能会选择延迟最小的，这个数据是最新的，如果是一备的情况则优先选择备机。而这个过程可能会对业务的读写有影响，所以要选择最优的数据。第二拉取进程——比如同时做了很多流程不能同时拉取，一个是网卡流量会跑满，另外是由于有大量数据写入，就是IO负载比较重。所以要互斥，这样影响是最小的。第三是做压缩加速——这个地方主要是在于数据源，系统会把数据拉取的镜像进行优化压缩，压缩之后传到做的节点上；这样做的好处一方面是减轻网络的压力，压缩比大约是三分之一到四分之一。同时，我们可以加速，毕竟传输比较小，比如压缩四分之一传100兆就是传过去400兆的数据，对提升效率非常有帮助。
最后步骤是建立同步，这里主要是确认同步点以及恢复同步，这里TDSQL会帮助你自动去做。
所以大家看到，整个流程对用户来说只需要在赤兔上点击“发起重做”就可以自动完成整个流程，不需要过度介入。
我们来看一个重做DB的例子。
上面的图是一个实录：可以看到DB节点有三个，重做节点就在右下角，点“重做备机”按钮进入流程，这个页面可以实时显示两个备节点状态，我们可以看到第一个备节点延迟非常大，这个就是我们需要重做的异常节点，防止大家误操作选错节点。提交完之后过一段时间会告诉你“重做成功”。整个流程就结束了。
我们再看在线DDL功能。
操作DDL非常常见的应用，尤其是在业务变化非常频繁、表结构频繁变化的场景中。为什么要提在线DDL？如果是面对一个普通的小表，那么可以直接做DDL，但是如果面对的是一个数据量比较大的表，比如几十G甚至几百G，要做一个表结构变更怎么办？这个时候很有可能影响业务请求，所以我们提出要做在线DDL。
在赤兔上，在线DDL也非常简单：我们在赤兔上提交请求，然后传输到TDSQL模块实施，一共两步—熟悉数据库的应该比较了解，这两个步骤一个负责拷贝数据，随后表数据同步完之后再进行切表——新老表进行切换。
TDSQL在这个流程里做了哪些事情？赤兔可以自定义DDL的开始时间。那为什么要做这个事情？DDL虽然是在线，但是也会涉及到拷贝数据，特别是在业务负载比较高的时候会对业务有影响，我们希望在业务不繁忙的时候——业务一天里的周期一般是固定的，即在业务低谷的时候做这个事情，因此平台支持可以自定义时间，比如白天发起任务，晚上一点钟业务低估时再正式运行任务。
拷贝数据。刚才提了拷贝数据可能会对业务有时耗影响，所以TDSQL会检测这两个指标：备机延迟检测与活跃链接检测——超过了会暂停，直到恢复正常时再继续。这两个指标在前台也可以自定义，不过系统有推荐的默认值，一般不需要更改。
另外是切表流程。这个流程涉及到新老表的切换——把新表切成老表的名字。
切表流程涉及两个功能应用：切表加锁检测和保护，以及切表模式自由选择。第一个，日常中我们很常见的场景是，切表前有一个大的事务在访问这张表，查询了半个小时还没有跑出来。这个时候要做切表操作就获取不到元数据锁，同时又阻塞了后面的业务请求，后面的业务请求会等前面的切表流程才能继续。所以TDSQL根据这个场景做了一个切表加锁保护——就是说，我们在知道要切表之前，要先看一下请求里有没有这表的大查询，有的话就暂时不切，先让它完成，我们不会把它直接杀掉。开始切的话时间非常短，对用户最多影响一秒钟。如果正要发生切表时，正好有个请求抢在前面让切表无法执行，那系统就自动超时，不影响后面的业务SQL。回到数据同步状态隔一段时间又会发起切表，而且间隔时间会越来越长，直到可以完成整个DDL操作。
另一个自由选择功能意味着，切表模式可以选择手动和自动切表：自动完成也有加锁保护；手动切表就是拷贝数据完成之后不立即切表，而是DBA可以手工在前台发起切表操作。
我们看一个在线DDL的例子：
左图就是在线DDL页面，通过页面可以看到表结构，大家点击“编辑”按钮就可以修改字段和索引。右图的页面里面我们可以看到，刚才提到的参数设置都可以自定义，也可以选择默认值，点击“确认”后整个过程自动完成。如果选择手动切表，可以选择合适的时间完成切表操作。
我们看一下安全保护机制，流程自动化了，我们更要保证这里面每一个流程都是安全合理的。
安全性保障不仅限于这些，PPT里选取了部分常见的场景。
权限申请非常常见：如果有用户已申请了密码A，而且程序已经使用这个账户在运行中，如果再申请这个用户而使用不同密码，系统会自动检查，所以不让老的密码被覆盖掉。
第二类是onlineddl自动保护。
第三个是实例下线，这个我们做了一个隔离定时删除功能。我们可以先进行隔离，隔离之后访问数据库的请求都会被拒掉，但是隔离状态是可以及时恢复的，所以我们相当于放在一个回收站里，数据还没有清掉，但业务访问不了。过一段时间定时清理，比如7天之后（这个时间长度是可以自定义的）没有业务反馈，则可以清掉，安全下线。
重做DB节点，在这个环节TDSQL提供了主节点保护的功能机制。扩容，会涉及到TDSQL扩容：把数据切换到另一个数据节点，新数据节点在做数据的过程中是没有影响的，因为业务的请求还是访问老的实例节点，但是在最后一步路由切换，是在扩容流程里唯一会对业务有影响的，因此TDSQL对这个流程做了保护——可以自主选择切换模式，就是可以手动切换或者自动切换。手动切换业务可以实时观察，有问题可以及时反馈；路由切换可能要经过几个步骤，中间流程如果有失败会自动回滚，不对业务有什么影响，所以也是对扩容的保护。
备份：不需要干预，TDSQL会自动备份，备份过程中也有互斥检测。最后也会有加锁机制，虽然比较短，但是有业务请求比较长的也会加锁失败，这里加锁时间如果超过一定时间会自动停止备份，备份会择机再次发起，不对业务有影响。也就是说，备份不影响备机的正常运行。
总结来说，TDSQL对自动化运营提供了很多安全性保障措施，保证每一个流程在关键节点，特别是在流程里可能会对业务的请求、访问有影响的环节，都做了很多的保障。这个也是TDSQL运营这么长时间各种经验的总结，和不断优化的结果，所以大家可以放心使用。
下面我们进入第三章节：TDSQL故障分析自动化。
刚才我们分析到，DBA日常遇到的第二类问题主要是发现问题的时候如何定位分析。
DBA在面对故障的时候往往非常烦躁，各种问题非常多。大家在定位问题的时候归根结底有几个难点：第一个是DBA的经验能力对问题定位影响非常大，很多优秀的DBA都是通过不断的故障积累经验才能成为优秀的DBA。第二个，我们定位的时候往往要通过各种认证登录后台，查看各种指标综合分析，这样效率非常低。其实很多的问题都是重复发生、重复发现，但是我们要重复定位和解决。
所以我们希望通过“扁鹊”平台把DBA故障分析经验沉淀下来，沉淀到赤兔智能运营平台，让它来自动分析、发现这些问题，为数据库用户和DBA带来高效便捷的体验。如果有新的思路、新的问题出现包括新的原因，我们都会持续沉淀到这个平台来做循环，这个平台会逐渐变得非常强大。
扁鹊主要有四个主要功能：可用性分析、可靠性分析、性能分析和其他分析，其他分析也是在不断强化。可用分析主要围绕主备切换场景展开；可靠性分析主要以较大范围场景的体检报告来分析数据库目前的问题，可以对DB状态进行了如指掌的分析。
性能分析针对的场景就是数据库运行变慢了。我们可以大概总结为这几类，比如热点表、大事务、锁等待、长事务等，下面一层可以分析SQL事务时耗，包括对SQL的检查优化等，来看SQL有没有问题。
下面这一层就依赖数据层，上面的模块是数据的采集方式，最下面是数据的存储方式，比如审计日志对TDSQL的数据都有采集，而DB的状态包括DB的快照、事务信息、隐藏状态等；同步信息包括表结构信息等，例如表结构不合理要先摘出来看看哪不合理。
还有是负责监控DB的模块，包括赤兔前台能看到的各种指标都在里面，还可以看到慢查询、主备切换的流程等，包括切换成功与否、切换点，切换时间点等关键指标。
右下角就是操作系统状态，包括IO内存、CPU等的状态。
这张图从上往下看，首先是可以分析可用性由哪些原因造成，然后有个逻辑分析层。最后是新增数据接入层。通过这个图大家可以直观了解到扁鹊工作方式以及内部逻辑。
接下来针对扁鹊的三大功能举例看一下它怎么做故障分析。
TDSQL分布式数据库通常是一主两备的架构，TDSQL的Agent会周期性地对DB做探活。探活是指模拟用户的请求，建立TCP连接后然后执行查询和写入，比如监控表的查询，模拟用户的请求看是否正常。TDSQL的可用性在于探活异常，如果认为DB发生异常，就会自动发起切换流程。
这是一个自动化流程，但是切完之后我们要看一下为什么引发了这次切换。这个可归结为为什么切换时间点发生了探活失败。
可用性问题归结为主DB Agent探活失败，大致可以分为三类：磁盘故障、DB重启和资源耗尽。我们分别看这三类故障的原因：
接下来看大事务引起的可用性分析问题。
我们分析主DB的请求，刚才提到了有Agent负责探活心跳周期性，同时也会有业务的请求——假设这个地方一个大表删除了1000W行……这些问题TDSQL结合成一个组提交。提交后可想而知会产生很大的binlog，据我们了解的可能会产生5G、10G甚至几十G。因为一个事务必须在一个binlog里，所以非常大的binlog。产生大的binlog又会产生哪些因素呢？整个流程下来会发现耗时非常长。而探活的时候会有时间频率限制，超过时间就会认为失败，探活失败提交了一分钟必然会发生主备切换，因为可能很多心跳已经上报仲裁主DB已经故障。
我们通过分析可以看这种故障类型有几个特征：心跳写入超时、产生大binlog文件、Innodb影响行数突增，以及事务处理prepared状态。
通过提取出的这四个特征——四个特征都是符合的，我们可以认为是由大事务引起的，从而导致切换。TDSQL自动运营平台针对主备切换的故障流程做分析，可以一键分析生成一个分析报告。
接下来讲一下DB性能分析。
非常直观就是执行慢。我们可以根据经验大概分成四类，网络问题、TDSQL本身问题、资源性问题和锁。网络问题比较容易理解，网卡流量、网络波动性；SQL问题包括索引分析、SQL分析；系统资源比如CPU、IO、Swap活跃度和锁等待的问题。需要分析的内容也是依托于采集数据来完成操作。
接下来看锁等待引起的DB性能问题设计思路。
右边这个看似有两个对话，这是典型的锁冲突对话：首先是begin开启事务。在第一秒的时候会话1开始更新，在第二秒的时候会话2也要更新。又过了一段时间对话1完成了——锁可能停留在两个时间点，这个时间点极有可能出现的情况是DB处于锁的状态。这里简单举了两个会话，几千个同时在等待某人执行SQL的时候给锁住了，现场DB分析的话，可能会经历这样一个流程：
第二个时间点，会话已经提交了，会话2时间比较久，在提交的一瞬间SQL就执行成功了。会话2整个已经超时，时间点二业务场景下1个小时之前会话超时了，赶紧看一下当时是什么情况。时间点1非常简单，熟悉DB的比较了解这种方法，底下有表就是事务表、锁等待表，通过关系我们可以查出来会话1没有提交，把会话2给堵塞了，所以这种场景最容易分析。平常做把三个表的关系记录一下去查询，看看到底是哪个会话有问题然后把会话1杀掉，在业务看一下是不是有问题。
而如果在赤兔平台，这些可以一键完成，在赤兔上点“实时分析”可以看到现场案例是什么，我们有建议把会话杀掉然后可以恢复正常，当然这个之后要找业务看一下事务为什么这么长时间而不释放。
第二个场景，会话1已经提交了，事后分析没有故障现场怎么办？我们可以看一下这边的故障特征，这类的故障特征是会话2更新的表超时了，或者结余时间比较久。它的时间超时在T1，或者很久在T1执行完了都有可能。
我们的目标是找出来会话X，到底是哪个会话把会话2堵塞了，首先会话X在时间点是持有T表的行锁，只有它具备这个条件才有可能把会话2堵塞住。我们可以通过SQL日志分析怎么把会话找出来。刚才提到了SQL有所有信息，其中就是客户端IP，由于SQL日志有很多请求是交错在一起的，比如开启一条事务执行一条SQL，又开始另外一条执行SQL，是很多事务连接的请求交错在一起的，我们很难分析出来一个事务的关系。所以我们第一步要做的是先要根据客户端的ip port聚合还原事物，按照维度做聚合然后可以知道ip port所有的执行数据。我们会对SQL进行依法解析然后提交时间。
另外，我们还想提取事务中间可能有各种查询更新操作，这些SQL到底是持有哪个表的锁，它没有锁的话肯定对会话2没有影响。紧接着我们得出这样的结论：首先是事务的执行时间，什么时候开始、什么时候结束。事务的持锁列表有没有可能造成会话2的锁堵塞，还有SQL的间隔时间，这个也是帮助业务去看两个事务之间间隔这么长时间，中间到底发生了什么把会话2锁了，是否合理。
还有SQL的耗时，这里面也包括每个SQL的耗时，有个SQL执行时间非常长，确实把会话2锁了，我们要找出来看看为什么执行时间这么长。
通过这些信息表T1时间点可以得出来是由会话X对会话2造成的锁定，然后再看会话X为什么要执行得不合理，至少看一下业务是否正常。我们再看一个案例，在时间点包括锁来看是哪个会话引起了锁的等待，然后我们会看间隔时间包括信息，用来定位的会话引起了锁等待。
DB可用性分析，是指对数据库的状态可以提前了解，包括：系统状态、表空间分布、索引、死锁诊断、锁等待诊断、慢查询分析、DB状态检查等等。我们可以看到这样的案例：数据库评分非常低，做了分析之后看到它是哪些问题——CPU空间过度？任务非常多？下面的状态信息都可以帮助大家来看DB到底有没有问题，是否可以提前发现问题并解决。
平时对重要DB觉得运营状态不太了解就可以做一次诊断。当然这个系统也可以做自动诊断，也支持每天针对重要DB每天出一个预报。这个是DB的可靠性分析介绍。
今天主要分享了几部分内容：
总结而言，TDSQL自动化运营体系可以帮助大家把日常中非常烦琐、需要手动操作的事情进行标准化、自动化、智能化，一键完成，减轻大家的负担。因为我们做了标准化沉淀，很多需求不需要DBA自己做，基于TDSQL运营平台，业务也可以直接解决。日常的一些操作可以通过赤兔的权限管理放开给业务。
今天的内容大概就介绍到这里，谢谢大家。
Q：是否有多活机制？
A：我们有多活机制，并且有强同步复制机制，保证数据一致。。
Q：online ddl是否保持两个数据一致？
A：online ddl是基于工具进行改造。简单而言就是会实时把更新类操作写进新表，然后分批把原本的数据覆盖到新表里。数据覆盖完之后两个表的数据一致，触发器可以把业务请求的数据实时同步，直到切表流程结束。
Q：对于大事务如果刚开始执行没有注意到等过了十分钟才发现事务没有执行完，这个时候可以做哪些处理？
A：如果终止会话事务也会持续比较长的时间，如果一直等事务持续也是一个比较长的时间。这个时候我建议把它杀掉，如果不放心，刚才提到的有大事务极有可能触发主备切换。我们会强制做切换来保证高可用。
Q：死锁检测是通过定位吗？
A：这里不是死锁，是锁等待，是两个事务都无法执行，我们刚才的例子是可以提交，只是长时间未提交的事务。会话2一直在等，在某个时间点超时了，这个时间点2之前肯定是有会话把表锁住了，我们的目标是要找出来在会话2之前某个时间点的某个会话是否持有表的锁。我们根据表信息和时间点通过引擎日志，这个日志里记录了所有用户SQL执行信息，可以通过这个表的信息来分析锁超时的前后，主要是前有没有会话持有。当然这是一个筛选的过程，在那个时间点会有多个会话，这个会话就是做一个筛选，然后看会话是否合理。因为没有DB故障现场只能通过发生的事务信息来看。
直播回顾 | 随意迁移，无损迁移，其实很简单
