PG数据库运维工具应该涵盖哪些能力？我的介绍，打电话聊天。他们在选择信创的数据库类型，也试用了国内的一些数据库，最后准备选择TDSQL。当时，我感到有些惊讶。他们从2020年开始就一直在选择国产数据库，但是好像一开始用TDSQL之后的感觉不是很好。经过沟通得知他们刚开始使用TDSQL的分布式数据库，发现研发要求太高，所以都选择了TDSQL的集中式MYSQL实例，觉得很好用。整个数据库云的节点数量也从最初的十几个扩展到几十个。巧合的是，昨天在微信上和另一位金融客户聊起了数据库信创的选型，他们最终选择了TDSQL。与另一位客户类似，他们也选择了TDSQL的MYSQL集中式数据库实例。他们已经迁移了几十个数据库，其中大部分是几十到几百GB的小型数据库。他们觉得直接将小型数据库迁移到TDSQL的云平台非常方便，TDSQL的数据库云管理平台和运维工具基本可以满足他们日常的运维需求。通过交流，我觉得这两个客户选择TDSQL并不是因为TDSQL作为数据库有多好（TDSQL其实不是数据库，而是数据库云平台解决方案，有空我会写一篇关于TDSQL的详细文章在future.Introduction），但其数据库云管理平台非常擅长管理大量的小型数据库实例。用户选择它不是因为数据库技术，而是因为使用的方便性和可靠性。.从客户选择TDSQL的原因来看，我们来看看PG数据库的运维。笼统地讲PG数据库的运维是一个很大的话题，因为不同的客户有自己特殊的应用场景，PG数据库的运维管理方式也大不相同。更复杂的是，与我提到的选择TDSQL的两个客户不同，PG数据库既有小型数据库，也有超大型数据库系统。一些客户在更换新创时，1:1更换了Oracle数据库，很多数据库的热数据超过了数TB。面对规模差异巨大、运维需求不同的应用场景，运维工具要想适应千差万别的应用场景，就需要精心设计运维工具。PG数据库在国内的应用近两年发展迅速。另外，国内很多数据库也是基于PG开源项目开发的。它们在应用和运维上非常相似，所以我们也可以将它们归为PG。数据库产品。目前国内的数据库中，很多产品都是基于PG社区版代码作为研发起点，也有部分产品是基于openGauss开源项目。这些数据库的基本特性类似于社区版的PG数据库，但也做了一些扩展。但是在使用和运维方面，它们的很多特性和社区版的PG非常相似。也有一些与PG直接相关的数据库产品，但大部分都是基于PG的分布式解决方案PGXL/PGXC或CITUS。比如腾讯的TBASE，NTUGeneral的GBASE8C分布式版本，亚信的ANTDB，旭谷数据库等等，这里就不做详细的列举了。这些数据库的一个实例也是一个PG数据库，具体的一个实例也可以看做是一个PG数据库实例。但是在运维分布式数据库的时候，更需要关注整个集群和网络的问题。差距还是很大的。概括来说，PG数据库的运维需求分为五个方面，日常监控、故障预警、自动巡检、性能优化、故障诊断。一些企业已经在将一些核心系统迁移到PG数据库。对于这些系统，有日常监控要求。因此，一个数据库运维工具需要具备的最基本的能力就是监控能力，可以通过运维工具随时了解数据库实例的整体运行状态。D-SMART通过健康模型展示数据库的运行状态。另外，如果我们需要在一些重要的日子值班（比如公司年终决算、国庆特别值班等），那么我们就需要一些能够支持关键系统值班的工具.在D-SMART，我们提供了围绕数据库运维的“监控中心”、“日检中心”、“告警中心”、“性能优化中心”、“报表中心”、“容量管理中心”和“安全中心”，“工具中心”这些集中的功能组合可以满足不同用户和不同应用场景用户的需求。针对日常监控功能，D-SMART提供了三大运维监控工具：“今日看板”、“我的监控”、“关键SQL监控”。今天的看板可以集中查看用户监控的数据库的综合信息。“我的监控”允许用户使用传统的监控方式定义自己想要监控的指标，用于各大护航监控。“关键SQL监控”是为企业核心业务系统提供的专用监控工具。当核心业务系统的关键SQL出现问题时（如执行速度慢、执行计划变更等），能够及时报警，保障核心业务的安全运行。对于大量的小型数据库实例，全面监控是不切实际的。如果一个十人以上的团队需要运维成百上千个数据库实例，那么没有必要也不可能对这些数据库进行全面的监控。因此，在这种运维场景下，大量的监控工作应该变成自动化的任务，由监控系统自动完成。《数据库日常巡检》是一款非常有效的自动化运维工具。每天半夜自动分析数据库的运行数据和一些规则，形成简明的每日巡检总结报告。运维人员下班后可以直接阅读这些报告，了解我们运维的数百个数据库实例中的一些常见问题，从而判断当天或近期是否需要对某些数据库实例进行相应的更改未来。当我们需要运维大量小型数据库实例时，预警就变得非常困难。传统的“基线警告”效果变得很鸡肋。除了数据库实例宕机，其他预警很难准确。海量的预警信息会让预警变得毫无意义。因此，基于故障模型的“运维体验告警”就显得尤为重要。通过专家经验和以往经验构建的复杂规则，不仅可以提供更准确的预警，还可以让运维人员在告警产生后，更快速地定位问题，排除隐患。“数据库检查”是大多数DBA认为非常没用的功能。主要问题是这个工作是必须做的，但是要做到真正的检查到位，需要大量专业DBA的参与，需要大量的重复性工作。总体来说性价比不高。另一方面，全面、高质量的检查可以帮助我们发现系统中的一些隐患，有助于防患于未然。针对这一矛盾，如果能够实现高质量的自动化检测，那么问题就迎刃而解了。几个月前，我们帮助一个用户做了一个远程检查。用户将D-SMART采集的监测数据发送给我们实验室。我们的数据库专家利用远程数据生成的巡检报告，对近30套数据库系统进行了巡检。远程会诊，帮助用户发现各类问题200多个，用时不到2人日。通过自动化的手段，如果能够提高数据库检查的效率，那么检查工作就不会那么鸡肋了。除了检查，一些审计工作也很关键，比如安全审计、容量审计、SQL审计等。因为这些审计需要非常专业的技能，而且工作量也很大，所以当面对大量的数据库实例时，就和巡检一样变得很鸡肋。这样做的成本太高了。做。但是，如果这些任务可以通过自动化工具自动完成，那么它们就可以发挥非常重要的作用。其实，除了这些运维监控任务，大量数据库实例的管理和很多自动化操作也是DBA们非常需要的。这也是我开头提到的两个客户选择TDSQL的主要原因。要管理大量的数据库实例，数据库云平台是必须的，但是这些自动化管理功能非常复杂。根据企业自身特点建设独立的数据库云平台是一项大工程。当然，如果企业云平台的RDS服务能够满足你的数据库应用需求，那么直接使用云平台的RDS就可以了。当然，面对信创目前的需求，企业的RDS不仅要支持开源的MYSQL/PG数据库，还要支持国产的数据库产品。
