随着越来越多的组织将数据库迁移到云原生环境，有效地管理和监控这些系统变得至关重要。根据Coroot的匿名使用统计，64%的项目使用PostgreSQL，使其成为用户中最受欢迎的关系数据库管理系统（RDBMS），而MySQL的使用比例为14%。这一趋势与PostgreSQL作为全球最广泛使用的开源数据库的地位相符。在Coroot，我们致力于提供无缝的体验，无论您的数据库托管在AWS RDS、裸金属服务器、专用EC2实例还是Kubernetes上。

　　Kubernetes不仅是运行容器化应用程序的平台，它还通过其Operator框架实现了对数据库的更好管理，允许自动化任务，如备份、高可用性和扩展。这种管理体验类似于使用AWS RDS等托管服务，但没有供应商锁定，而且通常成本更低。

　　CloudNativePG是由EDB创建的开源Operator，EDB是全球最古老、最大的PostgreSQL供应商。与其他Operator一样，CNPG帮助在Kubernetes上管理PostgreSQL数据库，涵盖从初始部署到持续维护的整个操作生命周期。值得一提的是，这是市场上最新的PostgreSQLOperator，但其开源吸引力正在迅速增长，基于我的观察，它在Reddit用户中备受欢迎。

　　在本文中，我将演示如何在我的实验室中安装CloudNativePG集群，使用Coroot进行监控，然后生成负载并引入故障，以确保高可用性和可观察性。

　　Coroot利用eBPF监控应用程序和数据库之间的PostgreSQL查询，无需额外的集成。虽然这种方法提供了数据库性能的高层次视图，但可能缺乏理解数据库内部问题的可见性。为了弥补这一差距，Coroot还从PostgreSQL系统视图（如pg_stat_statements和pg_stat_activity）收集统计信息，补充eBPF基础的指标和跟踪信息。

　　Kubernetes监控数据库的方法通常涉及在数据库实例Pod内运行指标导出器作为边车容器。然而，这种方法在某些用例中可能会遇到挑战。例如，CNPG不支持运行自定义边车容器，其CNPG-i功能需要特定的插件支持，并且仍处于实验阶段。

　　为了解决这些限制，Coroot提供了一个专用的coroot-cluster-agent，可以在不需要为每个数据库实例单独容器的情况下发现和收集数据库的指标。要配置此集成，只需使用已为Coroot创建的数据库角色的凭据。在Coroot UI中点击“Postgres”，然后点击“配置”按钮。

　　接下来，在集群规范中提供为Corot配置的凭据。Coroot的集群代理将从集群中的每个实例收集PostgreSQL指标。pg_stat_statements扩展在集群创建时已启用，因此无需手动步骤。由于Coroot了解Kubernetes应用程序的动态特性，它会自动对所有实例进行仪器化，即使在添加更多副本时也是如此。

　　就这样！在一分钟内，我的PostgreSQL集群就由Coroot完全监控。这不仅仅是将一些PostgreSQL指标放入Prometheus中；我们现在拥有所有内容：指标、日志、跟踪、配置文件、仪表板以及自动突出显示任何性能问题或数据库不可用性的预定义检查。

　　在Kubernetes集群等共享基础设施中，应用程序经常争夺资源。我们将模拟一个邻居干扰的场景，其中一个CPU密集型应用程序在与我们的数据库实例相同的节点上运行。以下作业将创建一个在node100上运行的Pod，使用stress-ng：

　　首先，Coroot标记了CPU问题通过理解系统模型，Coroot只专注于与特定应用程序相关的节点，在这种情况下是PostgreSQL。我们的数据库实例运行在三个节点上：node100、node101和node102。这意味着即使在具有许多节点的集群中，Coroot也只突出显示相关节点。

　　使用CPU延迟图表，我们可以观察到pg-cluster-2正在经历CPU时间短缺。为什么？因为node100过载。那为什么会这样？因为cpu-stress应用程序消耗了所有可用的CPU时间。

　　接下来，我们将探索一个特定于PostgreSQL的故障场景。我们将在包含1000万行的articles表上运行一个不理想的架构迁移：

　　对于那些不太熟悉数据库的人来说，此迁移将锁定整个表以验证所有行都不为NULL。由于表相对较大clash怎么打开全局模式，迁移可能需要一些时间才能完成。在此期间，来自我们应用程序的查询将被迫等待，直到锁被释放。

　　让我们一起解读这些图表：pg-cluster-2的PostgreSQL延迟显著增加。许多SELECT和INSERT查询被另一个查询锁定。哪个查询？ALTER TABLE查询。为什么这个查询执行这么久？因为它正在执行I/O操作以验证每行的body列不为NULL。

　　最后，让我们看看CloudNativePG如何处理主实例故障。为了模拟此故障，我将简单地删除主PostgreSQL实例的Pod。

　　Operator检测到故障并启动了切换，将pg-cluster-1提升为新的主实例。在Coroot中，我们可以清楚地观察到集群发生了什么，并看到恢复查询处理大约花费了3分钟。

　　CloudNativePG和Coroot是运行和监控Kubernetes上PostgreSQL的绝佳组合。CloudNativePG处理数据库管理中的重任，如备份和故障转移，而Coroot则保持一切可见且易于故障排除。它们共同简化了应对现实世界问题的过程，确保您的数据库在云原生环境中顺利运行。