共计 3174 个字符，预计需要花费 8 分钟才能阅读完成。
| 导读 | 目前的国产数据库中，很多产品都是以 PG 社区版代码作为研发起点的，还有一些产品是基于 openGauss 开源项目的。这些数据库的基础特性都和社区版的 PG 数据库类似，不过也做了一定的拓展。不过从使用与运维上，它们的很多特性都与社区版 PG 十分类似。 |
过节前我和 PG 中国社区合作搞了一个关于如何使用 D -SMART 来运维 PG 数据库的线上直播，正好我的一个金融行业的客户听了我的介绍，打电话过来聊了聊。他们正在做数据库信创的选型，也试用了多个国产数据库，最后他们准备选择 TDSQL。当时我觉得有点意外，他们从 2020 年就开始在做国产数据库选型，不过好像最初使用 TDSQL 后的感受并不太好。后来经过沟通才了解到，他们刚开始使用 TDSQL 的分布式数据库，发现对研发要求太高，所以后来就全部选择 TDSQL 的集中式 MYSQL 实例，用下来发现挺好用的。整个数据库云的节点数也从最初的十几个扩展到了大几十个。
无独有偶，昨天和另外一个金融客户在微信上聊了聊数据库信创选型的事情，他们最终也选择了 TDSQL。和另外一个客户相似的是，他们也是选择了 TDSQL 的 MYSQL 集中式数据库实例。他们目前已经迁移了数十套数据库上去，大多数都是几十 GB 到几百 GB 的小库。他们觉得，小数据库，直接迁移到 TDSQL 的云平台上，使用起来十分便捷，TDSQL 的数据库云管平台和运维工具基本上已经能够满足他们日常运维的需要了。
通过交流我觉得，这两个客户选择 TDSQL，并不是因为 TDSQL 作为数据库有多优秀（TDSQL 实际上不是一个数据库，而是一个数据库云平台解决方案，关于 TDSQL 今后有空，我会写一篇详细介绍），而是其数据库云管平台对于纳管大量的小型数据库实例，做的十分到位，用户选择它，并不是从数据库技术来考虑的，而是从使用的便捷性与可靠性来考虑的。
从客户选择 TDSQL 的理由，我们再来看看 PG 数据库的运维。泛泛的谈 PG 数据库的运维是个十分庞大的话题，因为不同的客户有其特殊的应用场景，对 PG 数据库的运维管理方式也有较大的差异。更为复杂的是，和我所说的这两个选择 TDSQL 的客户不同的是，PG 数据库既有小型数据库，也有十分大型的数据库系统。有些客户在搞信创替代的时候，是把 Oracle 数据库 1 对 1 做替代的，很多数据库的热数据都超过数个 TB。面对规模差异极大，运维要求不同的应用场景，运维工具要想适应千差万别的应用场景，确实是需要精心设计的。
PG 数据库在国内的应用这两年发展的很快，再加上很多国产数据库也是以 PG 开源项目作为基础研发的，在应用、运维上十分相似，因此我们也可以把它们归类为 PG 类的数据库产品。
目前的国产数据库中，很多产品都是以 PG 社区版代码作为研发起点的，还有一些产品是基于 openGauss 开源项目的。这些数据库的基础特性都和社区版的 PG 数据库类似，不过也做了一定的拓展。不过从使用与运维上，它们的很多特性都与社区版 PG 十分类似。
还有一些数据库产品也和 PG 有着直接的关系，不过大部分基于 PG 的分布式解决方案 PGXL/PGXC 或者 CITUS。比如腾讯的 TBASE，南大通用的 GBASE 8C 分布式版本、亚信的 ANTDB，虚谷数据库等。这里就不做仔细的罗列了。这些数据库的某个实例也是一个 PG 数据库，对某个具体的实例也可以看做是 PG 数据库实例，只不过在运维分布式数据库的时候，需要更加关注整个集群与网络的问题，在运维上区别还是很大的。
概括的说，PG 数据库的运维需求分为五个方面，日常监控、故障预警、自动化巡检、性能优化和故障诊断。
有些企业已经在把一些核心系统在向 PG 类数据库迁移了，对于这些系统，日常就有监控的需求。因此一个数据库运维工具需要具备的最基础的能力就是监控能力，能够通过运维工具随时了解数据库实例的总体运行状态。D-SMART 是通过健康模型来展示数据库的运行状态的。除此之外，如果我们在一些重大日期要做值守（比如企业的年终决算，国庆节等专项值守等），那么我们就还需要一些能够支撑关键系统值守的工具。
在 D -SMART 中，围绕数据库运维我们提供了“监控中心”、“日检中心”、“告警中心”、“性能优化中心”、“报告中心”、“容量管理中心”、“安全中心”、“工具中心”这几个中心化的功能组合来满足不同用户，不同应用场景的用户的需求。
对于日常监控功能，D-SMART 提供了“今日看板”、“我的监控”、“关键 SQL 监控”这三个主要的运维监控工具。今日看板可以集中查看用户监控的数据库的综合信息，“我的监控”允许用户用传统的监控方法去定义自己想要监控的指标，用于重大护航监控。而“关键 SQL 监控”则是为企业核心业务系统提供的专项监控工具。当某个核心业务系统的关键 SQL 出现问题的时候（比如执行速度变慢，执行计划变化等），能够及时告警，确保核心业务的安全运行。
对于大量的小型的数据库实例，全面监控是不太现实的。如果一个十几人的团队要运维数百上千个数据库实例，那么最这些数据库进行全面监控既不必要，也不可能。因此这种运维场景应该把大量的监控工作变成自动化任务，由监控系统自动完成。
“数据库日检”是一个十分有效的自动化运维工具，每天半夜针对数据库的运行数据以及一些规则自动做分析，并形成言简意赅的日检总结报告，运维人员上班后直接阅读这些报告就可以了解自己运维的数百个数据库实例中存在的一些常见问题，从而可以确定当天或者近期是否需要对某些数据库实例做相应的变更。
当我们需要运维大量的小型数据库实例的时候，预警也变得十分困难了。传统的“基线告警”的效果就变得十分鸡肋了。除了数据库实例宕机以外，其他的预警很难做的精准。海量的告警信息会让预警变得毫无意义。因此基于故障模型的“运维经验告警”变得尤为重要。通过专家经验与以往的经验构建的复杂的规则不仅能够更为精准的预警，也能让告警产生后，运维人员可以更加快速的定位问题，消除隐患。
“数据库巡检”是广大 DBA 都觉得十分鸡肋的功能，最主要的问题在于这项工作必须做，但是做一次真正到位的巡检既需要大量的专业 DBA 参与，又需要做大量的重复劳动，总的看来，性价比并不高。另外一方面，全面高质量的巡检又能够帮助我们发现一些系统隐患，有助于实现防患于未然。针对这个矛盾，如果能够实现高质量的自动化巡检，那么问题就迎刃而解了。几个月前，我们帮助一个用户做了一次远程巡检，用户把 D -SMART 采集的监控数据发给我们实验室，我们的数据库专家利用远程数据产生的巡检报告，对近 30 套数据库系统进行了一次远程会诊，帮助用户发现了各类问题两百多个，而这些工作仅仅花了不到 2 个人天。通过自动化手段，如果能够把数据库巡检的效率提高了，那么巡检工作也就不会这么鸡肋了。
除了巡检之外，一些审计工作也十分关键，比如安全审计、容量审计、SQL 审计等。因为这些审计需要十分专业的技能，另外工作量也很大，因此在面对大量的数据库实例的时候，也和巡检一样变得十分鸡肋，要想做到位成本太高，做不到位等于不做。不过这些工作如果能够由自动化工具自动完成，那么也就能够发挥出十分重要的作用了。
实际上除了这些运维监控工作之外，大量的数据库实例的管理工作还有很多自动化操作是 DBA 十分需要的，这也是我开始说的那两个客户选择 TDSQL 的主要原因。管理海量的数据库实例，数据库云平台是必选项，只不过这些自动化管理功能本身就十分复杂，根据企业特点构建独立的数据库云平台本身就是一个大工程。当然，如果企业云平台的 RDS 服务就能够满足你的数据库应用需求了，那么直接使用云平台的 RDS 就够用了。当然面对现在的信创需求，需要企业的 RDS 需要不仅仅支持开源的 MYSQL/PG 数据库，也要支持国产数据库产品。
