CloudNativePG 排障实战指南：从基础诊断到应急备份、日志分析与已知问题处理

CloudNativePG 排障实战指南从基础诊断到应急备份、日志分析与已知问题处理【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pgCloudNativePG 是基于 Kubernetes 的 PostgreSQL Operator其官方 troubleshooting 文档 系统性地总结了在 Kubernetes 环境中诊断 CloudNativePG 集群故障的完整方法。本文以该文档为核心骨架结合仓库内 API 类型定义、Cluster 状态处理逻辑、实例管理器启动参数 与 系统工具层 等源码实现为你提供一套可直接上手的排障清单从收集环境信息、利用kubectl cnpg插件快速定位问题到执行紧急逻辑备份、按 JSON 日志过滤 PostgreSQL 错误、等待集群条件再到处理磁盘写满、副本失步、NetworkPolicy 阻断等高频故障场景。排障前的准备环境信息与必备工具明确底层 Kubernetes 环境开始任何排障动作之前先确认以下关于底层 Kubernetes 系统的信息它们往往是定位问题的关键上下文正在使用的 Kubernetes 发行版与版本PostgreSQL 实例所在节点的规格CPU、内存、磁盘尽可能详细的 存储 信息包括 StorageClass、以及上线前做过的基准测试数据集群中正在运行的相关 Kubernetes 应用如 Prometheus、Grafana、Istio、Cert-manager 等连续备份Continuous Backup的现状确认其是否已配置并正常工作——如果没有备份在进行任何可能造成破坏的操作前务必先按下文 紧急逻辑备份 执行一次备份。推荐的工具集除必需的kubectl外文档推荐在排障环境中准备以下工具工具用途cnpg插件kubectl的 CloudNativePG 插件提供status、report、logs等子命令是排障首选jq轻量灵活的 JSON 命令行处理器用于解析 CloudNativePG 的 JSON 结构化日志grep在日志中匹配指定模式Windows 用户可用findstr代替或通过wsl安装 *nix 发行版后使用上述工具第一步获取集群与 Operator 的整体视图使用kubectl cnpg插件插件是快速获取集群或 Operator 安装全貌的主要工具status 子命令提供集群的概览信息report 子命令提供集群与 Operator 部署的完整 manifest可通过--logs选项附带日志生成的报告包含完整集群 manifest。在无法联网air-gapped的环境中插件可以通过离线包安装完整说明参见 kubectl 插件文档。拿到集群 manifest 后应立即核对备份是否已配置并处于工作状态根据结论决定是否需要先做一次 紧急备份。在没有定期备份的情况下操作生产数据库是极其危险的。获取 Operator 运行信息默认情况下CloudNativePG Operator 以Deployment形式安装在cnpg-system命名空间中详见 部署细节。# 列出 Operator 相关的 Pod kubectl get pods -n cnpg-system正常情况下应有一个以cnpg-controller-manager-开头的 Pod 运行 Operator若为高可用部署则有多个。这些 Pod 由名为cnpg-controller-manager的 Deployment 管理。收集指定 PodPOD的详细信息与日志kubectl describe pod -n cnpg-system POD kubectl logs -n cnpg-system POD多副本 Operator 部署下可一次获取 Deployment 内所有容器的日志并加-f实时跟踪kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containerstrue将日志以 JSON 格式落盘保存注意每个日志条目本身是 JSON用jq -r .可去除引号包装kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containerstrue | \ jq -r . cnpg_logs.json通过插件获取 Operator 版本信息kubectl-cnpg status CLUSTER输出示例含版本号、复制状态、实例状态等Cluster in healthy state Name: cluster-example Namespace: default System ID: 7044925089871458324 PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:18.6-system-trixie Primary instance: cluster-example-1 Instances: 3 Ready instances: 3 Current Write LSN: 0/5000000 (Timeline: 1 - WAL File: 000000010000000000000004) Continuous Backup status Not configured Streaming Replication status Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority ---- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- ------------- cluster-example-2 0/5000000 0/5000000 0/5000000 0/5000000 00:00:00 00:00:00 00:00:00 streaming async 0 cluster-example-3 0/5000000 0/5000000 0/5000000 0/5000000 00:00:00.10033 00:00:00.10033 00:00:00.10033 streaming async 0 Instances status Name Database Size Current LSN Replication role Status QoS Manager Version ---- ------------- ----------- ---------------- ------ --- --------------- cluster-example-1 33 MB 0/5000000 Primary OK BestEffort 1.12.0 cluster-example-2 33 MB 0/5000000 Standby (async) OK BestEffort 1.12.0 cluster-example-3 33 MB 0/5000060 Standby (async) OK BestEffort 1.12.0紧急逻辑备份Emergency Backup在紧急情况下你可能需要对主库的app数据库执行一次逻辑备份。重要以下指令仅应在紧急情况下执行且临时备份文件需符合组织的安全与数据保护策略。dump 文件会保存在执行kubectl命令的客户端机器上请确保相应保护措施到位、磁盘空间充足。对cluster-example集群的app数据库执行逻辑备份从cluster-example-1Pod 发起kubectl exec cluster-example-1 -c postgres \ -- pg_dump -Fc -d app app.dump上述命令以自定义格式-Fc执行pg_dump这是 PostgreSQL 中最灵活的逻辑备份方式见 pg_dump 官方文档。只需替换为你环境中实际的集群与数据库名称即可复用。恢复的前提是目标集群已初始化完成且app数据库为空。连接到新集群new-cluster-example的主实例new-cluster-example-1Pod执行恢复kubectl exec -i new-cluster-example-1 -c postgres \ -- pg_restore --no-owner --roleapp -d app --verbose app.dump重要该示例假设没有其他需要 dump/restore 的全局对象数据库与角色。若存在多个角色请用pg_dumpall -g单独备份并手工恢复到新集群若存在多个数据库需要逐个数据库重复上述操作并确保分配正确的属主。如果不熟悉 PostgreSQL建议在专业支持团队的指导下执行这些关键操作。上述步骤未来可能会整合进cnpg插件。日志分析从 JSON 结构化日志中快速定位问题CloudNativePG 创建和管理的所有资源都遵循 Kubernetes 惯例向标准输出写日志格式为 JSON详见 日志文档。排障时可直接从命令行读取日志主要有三种方式用kubectl logs获取特定资源日志配合jq提升可读性使用kubectl cnpg logs命令 获取 CloudNativePG 专属日志借助 stern 等开源工具通过cnpg.io/clusterName标签聚合多资源日志、过滤条目、自定义输出格式。下面给出针对各种资源的日志检索示例。实例Pod日志按集群标签列出实例列表附带角色标签rolekubectl get pod -l cnpg.io/clusterCLUSTER -L role -n NAMESPACE输出示例NAME READY STATUS RESTARTS AGE ROLE CLUSTER-1 1/1 Running 0 10d4h5m primary CLUSTER-2 1/1 Running 0 10d4h4m replica CLUSTER-3 1/1 Running 0 10d4h4m replica检查 Pod 的完整 YAML判断启动参数、挂载、状态等kubectl get pod -n NAMESPACE -o yaml CLUSTER-N获取指定实例的全部日志kubectl logs -n NAMESPACE CLUSTER-N只过滤 PostgreSQL 进程自身的日志消息kubectl logs -n NAMESPACE CLUSTER-N | \ jq select(.loggerpostgres) | .record.message附加时间戳输出为 CSV 两列kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r select(.loggerpostgres) | [.ts, .record.message] | csv若时间戳为 Unix Epoch 格式可转换为易读格式kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r select(.loggerpostgres) | [(.ts|strflocaltime(%Y-%m-%dT%H:%M:%S %Z)), .record.message] | csv针对崩溃与错误的过滤技巧查看已崩溃容器的上一次日志kubectl logs -n NAMESPACE --previous CLUSTER-N提取指定 Pod 中的 FATAL 错误按 PostgreSQL 的error_severity字段过滤kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r .record | select(.error_severity FATAL)输出示例这是典型的streaming_replica角色不存在的复制失败场景{ log_time: 2021-11-08 14:07:44.520 UTC, user_name: streaming_replica, process_id: 68, connection_from: 10.244.0.10:60616, session_id: 61892f30.44, session_line_num: 1, command_tag: startup, session_start_time: 2021-11-08 14:07:44 UTC, virtual_transaction_id: 3/75, transaction_id: 0, error_severity: FATAL, sql_state_code: 28000, message: role \streaming_replica\ does not exist, backend_type: walsender }过滤日志中的数据库错误消息err字段非空kubectl logs -n NAMESPACE CLUSTER-N | jq -r .err | select(. ! null)输出示例控制器 UNIX socket 路径连接失败dial unix /controller/run/.s.PGSQL.5432: connect: no such file or directory按msg字段匹配 err 关键字kubectl logs -n NAMESPACE CLUSTER-N | jq -r .msg | grep err输出示例2021-11-08 14:07:39.610 UTC [15] LOG: ending log output to stderr获取 PostgreSQL 进程的全部原始日志行loggerpostgres且排除内层record消息kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r . | select(.logger postgres) | select(.msg ! record) | .msg输出示例日志重定向到收集器进程的典型启动序列2021-11-08 14:07:52.591 UTC [16] LOG: redirecting log output to logging collector process 2021-11-08 14:07:52.591 UTC [16] HINT: Future log output will appear in directory /controller/log. 2021-11-08 14:07:52.591 UTC [16] LOG: ending log output to stderr 2021-11-08 14:07:52.591 UTC [16] HINT: Future log output will go to log destination csvlog.将多个日志字段用|连接成一行输出kubectl logs -n NAMESPACE CLUSTER-N | \ jq -r [.level, .ts, .logger, .msg] | join( | )输出示例WAL 归档未配置的提示与 PostgreSQL 记录行info | 1636380469.5728037 | wal-archive | Backup not configured, skip WAL archiving info | 1636383566.0664876 | postgres | record集群信息状态、条件与镜像版本查看 Cluster 资源查看集群概览kubectl get cluster -n NAMESPACE CLUSTER输出示例NAME AGE INSTANCES READY STATUS PRIMARY CLUSTER 10d4h3m 3 3 Cluster in healthy state CLUSTER-1健康状态下集群应有 3 个实例、全部readyCLUSTER-1为 primary。若处于非健康状态可通过完整 manifest 深入排查kubectl get cluster -o yaml -n NAMESPACE CLUSTER使用插件查看状态--verbose可输出更多信息kubectl cnpg status -n NAMESPACE CLUSTER获取 PostgreSQL 容器镜像版本kubectl describe cluster CLUSTER_NAME -n NAMESPACE | grep Image Name输出示例Image Name: ghcr.io/cloudnative-pg/postgresql:18.6-system-trixie也可以直接用kubectl-cnpg status -n NAMESPACE CLUSTER_NAME获得同样信息。备份与存储信息列出某集群的所有 Backup 资源按cnpg.io/cluster标签过滤kubectl get backup -l cnpg.io/clusterCLUSTER核对集群使用的 StorageClass先从 Pod 的 PVC 上取 StorageClass 名因为多数集群使用默认 StorageClass 创建STORAGECLASS$(kubectl get pvc POD -o jsonpath{.spec.storageClassName}) kubectl get storageclasses $STORAGECLASS -o yaml节点信息查看工作节点及其状态kubectl get nodes -o wide查看某集群 Pod 分布所在节点对排查 亲和/反亲和与容忍 配置非常有价值kubectl get pod -l cnpg.io/clusterCLUSTER \ -L role -n NAMESPACE -o wide基于 Conditions 的自动化等待与健康判断与 Kubernetes 原生对象一样Cluster在status.conditions中暴露结构化条件允许脚本“等待”特定事件发生而不是依赖整体健康状态。当前文档列出的可用条件如下其定义可在 api/v1/cluster_types.go 中确认条件Type含义True 的含义LastBackupSucceeded最近一次备份的状态最近一次备份已正确完成ContinuousArchivingWAL 归档的状态最近一次 WAL 归档已正确完成Ready集群是否就绪实例数满足用户要求且主实例就绪等待特定条件# 等待最近一次备份成功 kubectl wait --forconditionLastBackupSucceeded cluster/CLUSTER-NAME -n NAMESPACE # 等待 WAL 归档正常 kubectl wait --forconditionContinuousArchiving cluster/CLUSTER-NAME -n NAMESPACE # 等待集群就绪 kubectl wait --forconditionReady cluster/CLUSTER-NAME -n NAMESPACEReady条件尤其适合在创建集群的脚本中用于阻塞等待集群可用。失败条件的示例以下是一个cluster.status中同时包含失败条件的片段例如 barman-cloud WAL 归档返回退出码 2 时status: conditions: - message: unexpected failure invoking barman-cloud-wal-archive: exit status 2 reason: ContinuousArchivingFailing status: False type: ContinuousArchiving - message: exit status 2 reason: LastBackupFailed status: False type: LastBackupSucceeded - message: Cluster Is Not Ready reason: ClusterIsNotReady status: False type: Ready从源码看这些 reason 常量均有对应定义api/v1/cluster_types.goContinuousArchivingFailing、LastBackupFailed、ClusterIsNotReady等而Ready、LastBackupSucceeded条件也会由备份控制器在 api/v1/cluster_conditions.go 中根据备份成功/失败结果动态构建。可以推断条件中的type/reason是脚本与告警系统做分支判断的稳定契约。网络排障NetworkPolicy 与连通性CloudNativePG 要求具备基本的网络连通性详见 networking 文档。在既有环境中安装时可能已存在网络策略或定制化网络配置影响 Operator 与集群 Pod 之间、以及 Pod 之间的连通性。查看现有网络策略kubectl get networkpolicies输出示例NAME POD-SELECTOR AGE allow-prometheus cnpg.io/clustercluster-example 47m default-deny-ingress none 57m提示一个典型的连通性受损信号是 Operator 日志中出现类似Cannot extract Pod status…Get \http://pod IP:8000/pg/status\: dial tcp pod IP:8000: i/o timeout的消息。此时应列出网络策略并检查是否有策略限制了连通性例如上例中的default-deny-ingresspodSelector: {}且policyTypes: [Ingress]会默认拒绝所有入站流量。可参考 networking 页面 提供的 NetworkPolicy 模板定制一个显式允许 Operator 跨命名空间访问集群 Pod 的策略。性能剖析启用实例级 pprofCloudNativePG 集成了 pprof支持在两层收集与分析性能剖析数据Operator 层为 Operator 部署添加--pprof-servertrue启动选项启用参见 Operator 配置Postgres 集群层在Cluster资源上添加alpha.cnpg.io/enableInstancePprof注解启用。当注解alpha.cnpg.io/enableInstancePprof设为true时每个实例 Pod 都会由实例管理器instance manager暴露一个 Go pprof HTTP 服务服务监听 Pod 内0.0.0.0:6060Pod spec 中会自动增加名为pprof的容器端口6060/TCP。这一点与实例管理器源码实现一致run子命令提供--pprof-server标志启用时其绑定地址为0.0.0.0:6060见 internal/cmd/manager/instance/run/cmd.go 与 getPprofServerAddress。随时可通过移除注解或将其设为false来禁用 pprofOperator 会自动滚动更新以移除 pprof 端口与标志。重要pprof 服务仅提供6060端口的明文 HTTP 服务。启用示例apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example annotations: alpha.cnpg.io/enableInstancePprof: true spec: instances: 3 # ...修改该注解会更新实例 Pod spec增加端口6060与对应标志并触发滚动更新。警告下面的示例仅用于本地测试。这不是在生产中暴露该功能的正确方式。请将 pprof 视为敏感的调试接口切勿公开暴露若必须远程访问请用网络策略和访问控制进行保护。通过端口转发访问 pprof 端点kubectl port-forward -n namespace pod/instance-pod 6060 curl -sS http://localhost:6060/debug/pprof/ go tool pprof http://localhost:6060/debug/pprof/profile?seconds30也可以用浏览器访问http://localhost:6060/debug/pprof/。pprof 排障步骤确认集群上设置了alpha.cnpg.io/enableInstancePprof: true注解检查实例管理器命令行包含--pprof-server标志、且暴露了6060/TCP端口可通过kubectl -n namespace describe pod instance-pod查看Command与Ports部分若未使用端口转发请确认 NetworkPolicy 放行了6060/TCP端口。PostgreSQL core dump 的定位与收集PostgreSQL 偶尔会崩溃并在PGDATA目录下生成 core dump——这通常是 PostgreSQL 自身的 bug很可能已被修复这也是为何应始终运行最新的 PostgreSQL 小版本。CloudNativePG 通过cnpg.io/coredumpFilter注解控制 core dump 包含的内容标准注解清单见 Labels and annotations。默认值为0x31用于从 dump 中排除共享内存段——这是大多数情况下最安全的做法。该默认值与实现一致GetCoredumpFilter在未设置注解时返回 pkg/system/system.go 中定义的DefaultCoredumpFilter 0x31并由实例管理器在启动时通过SetCoredumpFilter写入/proc/self/coredump_filter见 internal/management/controller/instance_controller.go。关于控制 core dump filter 的位掩码含义可参考 Linux 内核文档中 Core dump filtering settings 一节。重要该设置仅在 Pod 启动时生效修改注解不会自动触发实例滚动更新。即使你本人不参与分析 core dump也可能被要求提供 dump 文件供 PostgreSQL 专家排查。先在正确的实例 Pod 上确认PGDATA目录中是否有 core dump正常情况应返回空kubectl exec -ti POD -c postgres \ -- find /var/lib/postgresql/data/pgdata -name core.*假设找到如下文件/var/lib/postgresql/data/pgdata/core.14177确认磁盘空间充足后用kubectl cp把 core dump 取到本地机器kubectl cp POD:/var/lib/postgresql/data/pgdata/core.14177 core.14177拿到文件后记得清理服务端空间删除 core dump 文件。已知问题与典型故障场景磁盘已满Storage is full存储写满后PostgreSQL Pod 将无法写入新数据若是存放 WAL 段的磁盘写满PostgreSQL 会直接关闭。日志中出现磁盘写满消息时应扩大受影响的 PVC编辑 PVC 修改spec.resources.requests.storage字段同时更新 Cluster 资源为新容量使同样的变更应用到所有 Pod详见 Volume expansion 一节。若 WAL 空间耗尽Pod 会不断崩溃重启crash-looping集群状态报告Not enough disk space。同样通过扩大 PVC 和 Cluster 资源容量解决可参考 Disk Full Failure 一节。Pod 卡在Pending状态先检查 Pod 的Events段kubectl describe pod -n NAMESPACE POD可能的原因包括没有任何节点匹配nodeSelectorTolerations 未正确配置以匹配节点 taints集群中根本没有可用节点——也可能与cluster-autoscaler触及某些限制或出现临时故障有关。此时检查命名空间事件也很有用kubectl get events -n NAMESPACE # 按时间顺序列出事件 kubectl get events -n NAMESPACE --sort-by.metadata.creationTimestamp未配置备份时副本失步Replicas out of sync副本可能因维护如节点被 drain而短暂下线。若集群未配置备份副本重新上线时可能需要一个主库上已不存在的 WAL 文件该文件已按 WAL 管理策略被回收参见postgresql配置段从而失步。类似地pg_rewind可能因找不到已回收的 WAL 文件而报pg_rewind: error: could not open file。此时 Pod 无法再变为 ready需要删除 PVC 让 Operator 重建副本。如果使用动态供给的 Persistent Volume且确认可以删除 PV可执行PODNAMEPOD VOLNAME$(kubectl get pv -o json | \ jq -r .items[]|select(.spec.claimRef.name\$PODNAME\)|.metadata.name) kubectl delete pod/$PODNAME pvc/$PODNAME pvc/$PODNAME-wal pv/$VOLNAME注意在删除 PVC/PV 前务必确认数据可恢复或可重建并遵从组织的数据保护规范。集群卡在Creating new replica集群状态卡在 Creating a new replica而 Pod 日志未见明显问题——这通常与下述 NetworkPolicy 导致的连通性问题有关。网络问题会以如下方式体现在状态列中Instance Status Extraction Error: HTTP communication issueNetworkPolicy 干扰网络Networking is impaired如前文所述本地网络策略可能阻止部分必需连通性。Operator 日志中出现以下消息是连通性受损的典型信号Cannot extract Pod status, […snipped…] Get \http://pod IP:8000/pg/status\: dial tcp pod IP:8000: i/o timeout列出网络策略并查找任何限制性策略kubectl get networkpoliciesNAME POD-SELECTOR AGE allow-prometheus cnpg.io/clustercluster-example 47m default-deny-ingress none 57m例如上表中的default-deny-ingress就是可疑对象进一步查看其内容kubectl get networkpolicies default-deny-ingress -o yamlspec: podSelector: {} policyTypes: - Ingress在 networking 页面 可以找到一个可定制的网络策略文件创建显式允许 Operator 跨命名空间连接集群 Pod 的NetworkPolicy。初始化数据目录时报错Bootstrap init container Bus error若 Cluster 的 bootstrap init 容器崩溃报Bus error (core dumped) child process exited with exit code 135很可能是需要修正 Cluster 的 hugepages 设置。原因是 cgroup v1 对 hugepages 支持不完整v2 中已修复相关背景见 PostgreSQL BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes。先在 Kubernetes 节点上运行grep HugePages /proc/meminfo确认是否存在 hugepages、其大小与剩余数量。若存在需要在 Cluster 中为每个 PostgreSQL Pod 配置可用的 hugepages 内存量。例如postgresql: parameters: shared_buffers: 128MB resources: requests: memory: 512Mi limits: hugepages-2Mi: 512Mi请记住集群中每个 Pod 都必须有足够的空闲 hugepages 内存才能被调度上例中每个 Pod 至少需要 512MiB 空闲。Bootstrap init 容器卡在 Running 状态若实例 Pod 的 bootstrap init 容器卡在Running并提示 error while waiting for the API server to be reachable通常是网络问题阻断了与 Kubernetes API Server 的通信。bootstrap init 容器与 Operator 的大多数组件一样需要访问 Kubernetes API请检查网络。另一种可能原因是配置了边车注入sidecar injection。Istio 等边车可能在启动阶段临时使网络不可用。若启用了 sidecar 注入请关闭注入后重试。故障切换后副本重连延迟超过两分钟主实例故障后Operator 会将最领先的 standby 提升为主其余 standby 尝试通过-rw服务重连复制。但重连过程中kube-proxy可能尚未更新其路由信息导致 standby 发出的首个SYN包无法到达目标。若网络配置为静默丢包而非拒绝standby 收不到响应会按指数退避重试。Linux 内核参数tcp_syn_retries默认值为 6意味着系统约尝试 127 秒后才放弃显著延迟重连过程详见 tcp_syn_retries 文档。可通过在 Operator 配置 中设置STANDBY_TCP_USER_TIMEOUT来规避该参数使 standby 在指定超时内未收到SYN确认时主动关闭 TCP 连接从而更快地重试连接。总结一份可执行的排障清单综合官方文档与源码实现CloudNativePG 的排障可归纳为以下固定动作序列准备确认 Kubernetes 发行版/版本、节点规格、存储与 StorageClass、相关应用、连续备份状态全景用kubectl cnpg status/kubectl cnpg report必要时带--logs获取集群与 Operator 完整信息备份核查确认 Backup 资源kubectl get backup -l cnpg.io/clusterCLUSTER与 WAL 归档条件ContinuousArchiving正常否则先做 紧急逻辑备份日志通过kubectl logs配合jq按logger、error_severity、err、msg等字段过滤定位错误条件等待用kubectl wait --forcondition...Ready/LastBackupSucceeded/ContinuousArchiving做自动化判断深入按需检查 StorageClass、节点分布、NetworkPolicy、cnpg.io/coredumpFilter注解、实例级 pprofalpha.cnpg.io/enableInstancePprof等专项处置针对磁盘写满、Pending、副本失步、卡在 Creating new replica、hugepages/Bus error、重连延迟等已知问题按上文对应的操作步骤处理。掌握这套方法后你就能在 CloudNativePG 的 Kubernetes 部署中系统、快速地完成从“发现问题”到“收集证据”再到“恢复服务”的完整排障闭环。【免费下载链接】cloudnative-pgThe most popular Kubernetes Operator for PostgreSQL.项目地址: https://gitcode.com/GitHub_Trending/cl/cloudnative-pg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考