摘要

90% 的团队第一次容器化人大金仓 / 达梦时，都会踩日志丢失的坑：删个 Pod 运行日志全没了、审计日志断档过不了等保、归档打满拖垮数据库、主备切换后守护进程日志失联排障无据。很多人以为挂了数据盘就万事大吉，殊不知运行日志、审计日志、归档日志、守护进程日志各有各的路径，漏挂一个就会重启丢失。

本文基于一线政务、金融项目落地经验，彻底拆解 K8s 环境下国产数据库的日志持久化方案，覆盖人大金仓 V9、达梦 DM9 双库完整配置，从单盘挂载到分目录分级留存，补充主备集群专属方案、自动化清理、零侵入采集、故障排查全链路，附全套可直接复制的 YAML 模板与轮转策略，彻底解决日志重启丢失、打满磁盘、合规不通过三大痛点。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。所有配置均生产实测，复制即用。

---

一、扎心痛点：容器化数据库日志为什么总丢

📌 核心结论：日志丢了，本质就是路径没挂载对。只挂数据盘不挂独立日志目录，等于白做持久化。

很多新手的误区：数据目录挂了 PVC，日志自然就跟着持久化了。实际情况是，国产数据库的日志分散在多个路径，有的默认在数据目录内，有的在安装目录下，还有的守护进程日志完全独立。漏挂任何一个，Pod 重启后对应日志直接清零。

最常见的翻车场景：

• 达梦运行日志默认在安装目录$DM_HOME/log，不在数据盘里，只挂数据盘 = 运行日志随容器销毁
• 金仓审计日志单独存 sysaudit 目录，没单独挂载又没做采集，等保测评直接卡壳
• 主备集群只持久化数据库日志，守护进程、监视器日志全丢，出故障无从排查
• 日志和数据混在一个盘里，归档日志打满磁盘，数据库直接挂死
• 审计日志输出到标准输出，多行乱序、重启断档，追溯完全失效

日志不是小事，尤其是审计日志、归档日志，是等保三级、密评的硬指标，丢了等于合规直接不通过；而运行日志、守护进程日志是排障的唯一依据，丢了故障定位成本翻十倍。

---

二、先理清楚：四类日志不能混，挂载错一个白忙活

国产数据库日志分四大类，特性、留存要求、持久化优先级完全不同，不能混在一个盘里。

2.1 日志分类全景表

日志类型	人大金仓 V9 默认路径	达梦 DM9 默认路径	持久化优先级	建议留存周期	IO 特性	核心作用
运行日志	数据目录下log/子目录	$DM_HOME/log/（安装目录内）	⭐⭐⭐⭐⭐	30-90 天	顺序写	排障、性能分析
重做日志（WAL/REDO）	数据目录下wal/子目录	数据目录下	⭐⭐⭐⭐⭐	随实例生命周期	高频随机写	数据崩溃恢复
归档日志	独立配置arch/目录	独立配置arch/目录	⭐⭐⭐⭐	180 天 +	大文件顺序写	数据恢复、主备同步
审计日志	数据目录下sysaudit/	数据目录下audit/	⭐⭐⭐⭐⭐	180 天 +（等保强制）	追加写	合规审计、操作追溯

💡 补充说明：重做日志随数据盘走即可，无需单独挂载；其余三类必须独立分盘，这是生产级标准。

2.2 存储选型匹配建议（成本与性能平衡）

不是所有日志都要用 SSD，按特性选存储，能省一半成本：

• 数据 + 重做日志：必须本地 SSD 或高性能块存储，IOPS 要求最高
• 运行日志：普通 SAS 盘即可，顺序写 IO 压力小，容量优先
• 归档日志：大容量高密盘 / 对象存储，冷数据为主，成本优先
• 审计日志：可靠存储即可，写入量小但留存久，安全性优先

2.3 为什么绝对不能用 hostPath

很多团队图省事用 hostPath 挂载宿主机目录，看起来能持久化，实际生产三大硬伤：

1. Pod 漂移到其他节点后，日志散落在不同机器，统一检索、合规审计全失效
2. 宿主机目录权限、容量不可控，容易被其他进程占用
3. 节点故障时，该节点上的日志直接丢失，追溯断档

✅ 生产唯一正解：StatefulSet + volumeClaimTemplates 独立 PVC，Pod 与 PVC 一一绑定，漂移到哪数据跟到哪。

---

三、四种持久化方案对比与选型决策

方案	实现方式	可靠性	性能	合规性	运维成本	适用场景
独立 PVC 分目录挂载	每类日志对应独立 PVC	极高	好	完全满足	低	生产环境、等保合规、主备集群
单 PVC 子目录挂载	一个 PVC 下建不同子目录	高	一般	基本满足	低	中小项目、非核心系统
emptyDir + Sidecar 采集	本地缓存 + 实时同步日志平台	中	好	不满足	中	开发测试、有集中日志平台
标准输出 + DaemonSet 采集	日志打 stdout，节点采集	低	一般	不满足	高	轻量场景、非核心无合规要求

选型决策树

1. 有等保 / 合规要求 → 直接选「独立 PVC 分目录挂载」，一票否决其他方案
2. 生产核心系统 → 独立 PVC 分目录 + Sidecar 集中采集，双重保障
3. 开发测试环境 → emptyDir + 标准输出，够用就行
4. 非核心小系统 → 单 PVC 子目录，兼顾成本与基础可靠性

---

四、生产级落地：人大金仓 V9 分目录持久化全配置

核心思路：显式指定所有日志路径，每个路径对应独立 PVC，fsGroup 自动修正权限，内置轮转策略。

4.1 第一步：ConfigMap 显式指定全量日志路径

不要依赖默认路径，显式配置最稳妥，避免镜像差异踩坑。

# kingbase-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: kingbase-config
  namespace: kingbase
data:
  kingbase.conf: |
    # ========== 运行日志配置 ==========
    logging_collector = on
    log_directory = '/opt/kingbase/log'
    log_filename = 'kingbase-%Y-%m-%d_%H%M%S.log'
    log_rotation_age = 1d
    log_rotation_size = 512MB
    log_truncate_on_rotation = on
    log_min_duration_statement = 1000  # 慢SQL审计，单位ms
    log_connections = on
    log_disconnections = on
    
    # ========== 归档日志配置 ==========
    archive_mode = on
    archive_command = 'cp %p /opt/kingbase/arch/%f'
    archive_timeout = 60min
    
    # ========== 审计日志配置（等保强制） ==========
    sysaudit.log = on
    sysaudit.log_directory = '/opt/kingbase/audit'
    sysaudit.log_format = json
    sysaudit.log_rotation_size = 1GB
    sysaudit.log_rotation_age = 1d
    sysaudit.log_connections = on
    sysaudit.log_ddl = on
    sysaudit.log_dml = on
    sysaudit.log_delete = on
    
    # ========== 核心业务参数 ==========
    listen_addresses = '*'
    port = 54321
    shared_buffers = 4GB

4.2 第二步：StatefulSet 完整持久化配置

四个目录独立挂载：数据、运行日志、归档、审计，各司其职。

# kingbase-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kingbase
  namespace: kingbase
spec:
  serviceName: "kingbase-headless"
  replicas: 1
  selector:
    matchLabels:
      app: kingbase
  template:
    metadata:
      labels:
        app: kingbase
        role: master
    spec:
      terminationGracePeriodSeconds: 120
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000        # 自动修正PVC目录权限，无需initContainer chown
        runAsNonRoot: true
        fsGroupChangePolicy: OnRootMismatch
      containers:
        - name: kingbase
          image: your-registry/kingbase-v9:latest
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 54321
              name: db
          volumeMounts:
            # 数据主目录（含重做日志）
            - name: kingbase-data
              mountPath: /opt/kingbase/data
            # 运行日志独立挂载
            - name: kingbase-log
              mountPath: /opt/kingbase/log
            # 归档日志独立挂载
            - name: kingbase-arch
              mountPath: /opt/kingbase/arch
            # 审计日志独立挂载
            - name: kingbase-audit
              mountPath: /opt/kingbase/audit
            # 配置文件挂载
            - name: kingbase-config
              mountPath: /opt/kingbase/data/kingbase.conf
              subPath: kingbase.conf
          resources:
            requests:
              cpu: "4"
              memory: "16Gi"
            limits:
              cpu: "4"
              memory: "16Gi"
          livenessProbe:
            exec:
              command: ["kb_isready", "-U", "system", "-p", "54321"]
            initialDelaySeconds: 60
            periodSeconds: 10
      volumes:
        - name: kingbase-config
          configMap:
            name: kingbase-config
  # 四个独立PVC模板，按Pod自动创建，重建不丢失
  volumeClaimTemplates:
    - metadata:
        name: kingbase-data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-ssd"
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: kingbase-log
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 30Gi
    - metadata:
        name: kingbase-arch
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: kingbase-audit
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 50Gi

4.3 容量规划参考

• 运行日志：30Gi 起步，按每天 500M 算可存 2 个月，生产建议 50Gi
• 归档日志：按业务日写入量 * 留存天数 * 1.5 倍冗余估算
• 审计日志：50Gi 起步，等保要求留存 180 天，按实际审计量扩容

---

五、生产级落地：达梦 DM9 分目录持久化全配置

达梦是日志丢失重灾区，核心原因是默认运行日志、守护进程日志全在安装目录下，完全不在数据目录里，只挂数据盘 100% 会丢日志。

5.1 第一步：ConfigMap 显式指定全量日志路径

统一把所有日志路径挪到可挂载的独立目录，彻底解决默认路径坑。

# dmdb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: dmdb-config
  namespace: dmdb
data:
  dm.ini.template: |
    [INSTANCE]
    INSTANCE_NAME = {INST_NAME}
    PORT_NUM = 5236
    
    [LOG]
    LOG_PATH = /dm/log                # 运行日志独立路径
    LOG_FILE_SIZE = 256               # 单日志文件大小，单位MB
    LOG_SPACE_LIMIT = 20480           # 日志总空间上限20G，超量自动覆盖最老文件
    LOG_QUEUE_SIZE = 1024
    
    [ARCHIVE]
    ARCH_INI = 1
    ARCH_DEST = /dm/arch              # 归档日志独立路径
    ARCH_FILE_SIZE = 256
    ARCH_SPACE_LIMIT = 81920          # 归档总空间上限80G，防止打满
    
    [AUDIT]
    AUD_PATH = /dm/audit              # 审计日志独立路径
    AUDIT_FILE_SIZE = 1024            # 单审计文件1G
    AUDIT_MAX_FILES = 180             # 最多保留180个文件
    AUDIT_FILE_ENCRYPT = 1            # 审计日志SM4加密存储（等保加分项）
    AUDIT_FILE_SIGN = 1               # 审计日志数字签名，防篡改

5.2 第二步：StatefulSet 完整持久化配置

重点：运行日志、归档、审计、守护进程日志全部独立挂载，杜绝安装目录默认路径坑。

# dmdb-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dmdb
  namespace: dmdb
spec:
  serviceName: "dmdb-headless"
  replicas: 1
  selector:
    matchLabels:
      app: dmdb
  template:
    metadata:
      labels:
        app: dmdb
        role: master
    spec:
      terminationGracePeriodSeconds: 180
      securityContext:
        runAsUser: 5236
        runAsGroup: 5236
        fsGroup: 5236        # 自动修正PVC权限，适配dmdba用户
        runAsNonRoot: true
        fsGroupChangePolicy: OnRootMismatch
      initContainers:
        - name: init-config
          image: your-registry/dm9:v9.1.2.100
          command: ["/bin/sh", "-c"]
          args:
            - |
              POD_ORDINAL=$(hostname | awk -F'-' '{print $NF}')
              INST_NAME="dmdb${POD_ORDINAL}"
              sed -e "s/{INST_NAME}/$INST_NAME/g" /dm/template/dm.ini.template > /dm/data/dm.ini
          volumeMounts:
            - name: dmdb-data
              mountPath: /dm/data
            - name: dmdb-config
              mountPath: /dm/template
      containers:
        - name: dmdb
          image: your-registry/dm9:v9.1.2.100
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5236
              name: db
          volumeMounts:
            # 数据主目录（含REDO日志）
            - name: dmdb-data
              mountPath: /dm/data
            # 运行日志独立挂载（核心：解决默认路径丢失问题）
            - name: dmdb-log
              mountPath: /dm/log
            # 归档日志独立挂载
            - name: dmdb-arch
              mountPath: /dm/arch
            # 审计日志独立挂载
            - name: dmdb-audit
              mountPath: /dm/audit
            # 守护进程日志独立挂载
            - name: dmdb-watcher-log
              mountPath: /dm/watcher_log
            # 共享内存
            - name: shm
              mountPath: /dev/shm
          resources:
            requests:
              cpu: "4"
              memory: "16Gi"
            limits:
              cpu: "4"
              memory: "16Gi"
          livenessProbe:
            exec:
              command: ["sh", "-c", "disql SYSDBA/$DM_PWD@localhost:5236 -c 'select 1;' || exit 1"]
            initialDelaySeconds: 90
            periodSeconds: 15
      volumes:
        - name: dmdb-config
          configMap:
            name: dmdb-config
        - name: shm
          emptyDir:
            medium: Memory
            sizeLimit: 3Gi
  # 五个独立PVC模板
  volumeClaimTemplates:
    - metadata:
        name: dmdb-data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-ssd"
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: dmdb-log
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 30Gi
    - metadata:
        name: dmdb-arch
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: dmdb-audit
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 50Gi
    - metadata:
        name: dmdb-watcher-log
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "local-sas"
        resources:
          requests:
            storage: 20Gi

⚠️ 关键提醒：达梦守护进程（dmwatcher）日志默认也在安装目录，主备集群排障全靠它，必须单独持久化，很多团队只存数据库日志，出了切换问题根本查不到原因。

---

六、进阶优化：轮转管控 + 自动清理 + 分级留存 + 集中采集

光持久化还不够，不管控早晚打满磁盘，还要做好全生命周期管理。

6.1 强制轮转策略：从根源杜绝磁盘打满

数据库	运行日志	归档日志	审计日志
人大金仓	内置 log_rotation_age/size 参数	配合归档清理脚本	内置 sysaudit 轮转参数
达梦	内置 LOG_SPACE_LIMIT 硬上限	内置 ARCH_SPACE_LIMIT 硬上限	内置 AUDIT_MAX_FILES 数量限制

💡 达梦的空间硬上限参数非常实用，达到阈值自动覆盖最老文件，彻底杜绝日志打满磁盘导致数据库宕机的风险，生产环境强烈建议开启。

6.2 自动化过期清理：CronJob + 原生工具双实现

内置轮转只能控制总大小，精细化过期清理需要配合定时任务。

达梦归档自动清理 CronJob（生产可用）

apiVersion: batch/v1
kind: CronJob
metadata:
  name: dmdb-arch-clean
  namespace: dmdb
spec:
  schedule: "0 3 * * *"  # 每天凌晨3点执行
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          securityContext:
            runAsUser: 5236
            runAsGroup: 5236
          containers:
            - name: clean
              image: your-registry/dm9:v9.1.2.100
              command: ["/bin/sh", "-c"]
              args:
                - |
                  # 清理7天前的归档日志，保留最近7天
                  find /dm/arch -name "*.arch" -type f -mtime +7 -delete
                  # 清理30天前的运行日志
                  find /dm/log -name "*.log" -type f -mtime +30 -delete
              volumeMounts:
                - name: dmdb-arch
                  mountPath: /dm/arch
                - name: dmdb-log
                  mountPath: /dm/log
          volumes:
            - name: dmdb-arch
              persistentVolumeClaim:
                claimName: dmdb-arch-dmdb-0
            - name: dmdb-log
              persistentVolumeClaim:
                claimName: dmdb-log-dmdb-0

6.3 分级留存体系：本地 + 平台 + 备份三层留存

日志类型	本地 PVC 留存	集中日志平台留存	备份归档留存
运行日志	30 天	90 天	不备份
归档日志	7 天	不存	180 天（随备份留存）
审计日志	180 天	1 年	永久归档（合规要求）
守护进程日志	30 天	90 天	不备份

6.4 零侵入集中采集：Filebeat Sidecar 完整配置

生产环境推荐 Sidecar 方式采集，不侵入数据库进程，不影响业务性能。

在 StatefulSet 的 containers 中追加 Filebeat 容器，共享日志卷：

- name: filebeat-sidecar
  image: elastic/filebeat:7.17.10
  imagePullPolicy: IfNotPresent
  args: ["-c", "/etc/filebeat/filebeat.yml"]
  volumeMounts:
    - name: dmdb-log
      mountPath: /var/log/dmdb/log
      readOnly: true
    - name: dmdb-audit
      mountPath: /var/log/dmdb/audit
      readOnly: true
    - name: filebeat-config
      mountPath: /etc/filebeat
  resources:
    requests:
      cpu: "0.1"
      memory: "128Mi"
    limits:
      cpu: "0.5"
      memory: "512Mi"
volumes:
  - name: filebeat-config
    configMap:
      name: dmdb-filebeat-config

优势：

1. 采集故障不影响数据库运行，完全隔离
2. 日志双份留存，本地 + 平台双重保障
3. 检索、告警、可视化全在日志平台完成，无需登录数据库节点

---

七、主备集群专属：高可用场景日志持久化避坑

主备集群的日志体系比单节点复杂，三个核心问题必须提前处理。

7.1 备库的日志要不要持久化？

必须要。两个原因：

1. 主备切换后，原备库变为主库，日志必须连续，不能切换后从零开始
2. 备库本身的运行日志、同步日志是排查主备同步故障的核心依据

✅ 正确做法：主备两个 Pod 都配置完全一致的日志持久化，各自 PVC 独立存储。

7.2 主备切换后日志连续性怎么保障？

StatefulSet 的固定身份机制天然解决这个问题：

• dmdb-0 永远对应 0 号节点的 PVC，dmdb-1 永远对应 1 号节点的 PVC
• 无论角色怎么切换，每个节点的日志是连续完整的
• 审计日志按节点留存，完全符合等保操作可追溯的要求

7.3 守护进程、监视器日志必须单独持久化

• 每个数据库节点的 dmwatcher 日志，必须持久化，切换过程全记录在这
• 独立部署的 dmmonitor 监视器日志，也要单独挂载 PVC，集群裁决日志是排障关键
• 很多团队只关注数据库日志，出了切换事故查不到原因，90% 都是漏了守护进程日志

7.4 归档日志的统一管理

主备都开启归档的场景，归档会生成两份，建议：

• 本地只保留 7 天归档，满足即时恢复需求
• 定期同步到集中备份存储，统一留存管理
• 避免主备归档混存，按节点分目录存放

---

八、常见故障排查手册（按图索骥直接修）

问题 1：数据库启动报错 Permission denied，无法写日志

现象：启动失败，日志提示无法创建日志文件、权限不足 排查步骤：

1. 进入 Pod 查看日志目录属主：ls -ld /dm/log
2. 查看数据库运行用户 UID：id dmdba 解决方案：

• securityContext 配置 fsGroup，与运行用户 GID 一致，自动修正 PVC 权限
• 若已创建旧 PVC，手动执行 chown 修正目录权限

问题 2：配置了独立路径，日志还是写到默认位置

现象：挂载的目录是空的，日志还在安装目录生成 排查步骤：

1. 查看数据库实际加载的配置：show config_file;
2. 确认配置文件路径是否正确挂载，参数是否生效 解决方案：

• 金仓：确认 kingbase.conf 在数据目录下，且参数拼写正确
• 达梦：确认 dm.ini 中 LOG_PATH 参数生效，没有被其他配置覆盖
• 禁止用软链接重定向，容易因初始化顺序失效

问题 3：审计日志不生成

现象：审计目录为空，操作数据库没有审计记录 排查步骤：

1. 确认审计总开关是否开启
2. 确认审计目录权限是否正确
3. 查看数据库告警日志是否有审计相关报错 解决方案：

• 金仓：确认 sysaudit 插件已加载，shared_preload_libraries包含 sysaudit
• 达梦：确认 SYSAUDITOR 账号开启了审计策略，审计路径配置正确

问题 4：日志轮转不生效，文件持续增大

现象：单个日志文件超过配置大小，没有自动切割 排查步骤：

1. 确认轮转参数单位是否正确
2. 确认日志进程是否正常运行 解决方案：

• 金仓：确认 logging_collector = on，这是轮转的前提
• 达梦：确认 LOG_FILE_SIZE 单位是 MB，数值不要过小

问题 5：Pod 重建后日志还是丢了

现象：删除 Pod 重建后，日志目录是空的 排查步骤：

1. 查看 PVC 是否还存在：kubectl get pvc
2. 确认 volumeMounts 的 name 与 volumeClaimTemplates 的 name 一致
3. 确认挂载路径与配置文件中的路径一致 解决方案：

• 修正挂载路径，确保与数据库配置完全匹配
• 检查 StorageClass 回收策略，避免 PVC 被误删

---

九、避坑指南：12 个日志持久化的经典翻车现场

⚠️ 坑 1：只挂数据盘，运行日志在安装目录

• 重灾区：达梦数据库，默认日志在 $DM_HOME/log，不在数据目录
• 现象：Pod 重启后运行日志全丢，排障无据可查
• 整改：显式修改 LOG_PATH 到独立挂载目录

⚠️ 坑 2：权限不匹配，日志写不进去

• 现象：数据库启动报错，提示无法创建日志文件
• 原因：PVC 默认属主是 root，数据库运行用户无写入权限
• 整改：securityContext 配置 fsGroup，自动修正目录权限

⚠️ 坑 3：不配轮转，日志打爆 PVC

• 现象：运行一段时间后数据库卡死，PVC 使用率 100%
• 原因：日志无限增长，没做轮转和空间限制
• 整改：配置文件大小、总空间上限，定期清理过期日志

⚠️ 坑 4：审计日志输出到标准输出

• 现象：为了采集方便把审计日志打 stdout，结果多行乱序、重启断档
• 后果：等保测评不通过，审计追溯失效
• 整改：审计日志必须落地持久化，采集只能做副本，不能当主力

⚠️ 坑 5：用软链接把日志指到数据盘

• 现象：容器启动时软链接失效，日志还是写到容器层
• 原因：初始化顺序问题，软链接被目录覆盖
• 整改：直接改配置文件指定路径，不要用软链接绕

⚠️ 坑 6：归档日志和数据同盘

• 现象：大业务量下归档暴涨，打满数据盘，数据库宕机
• 整改：归档日志独立 PVC，单独扩容，单独管控

⚠️ 坑 7：日志目录用 emptyDir

• 现象：Pod 重启日志就没，还以为持久化了
• 原因：emptyDir 是临时存储，Pod 删除就销毁，只能做缓存
• 整改：生产必须用 PVC，emptyDir 只能用于临时缓存

⚠️ 坑 8：备份只备份数据，不备份审计日志

• 现象：故障恢复后审计日志断档，合规检查不通过
• 整改：备份策略必须包含审计日志，和数据同等重要

⚠️ 坑 9：主备集群漏存守护进程日志

• 现象：主备切换异常，查不到切换过程日志，无法定位根因
• 整改：守护进程、监视器日志全部独立持久化

⚠️ 坑 10：用 hostPath 图省事

• 现象：节点漂移后日志散落在各处，统一审计、检索全失效
• 整改：生产必须用 StatefulSet + PVC，保证日志随 Pod 漂移

⚠️ 坑 11：全用 SSD 存储，成本浪费

• 现象：所有日志都上 SSD，存储成本翻倍
• 整改：按日志特性选存储，运行、归档、审计用普通 SAS 盘足够

⚠️ 坑 12：迷信集中采集，不做本地持久化

• 现象：采集链路故障时，日志完全丢失，追溯断档
• 整改：本地持久化是底线，集中采集是增值，不能本末倒置

---

十、验证手册：四步确认日志真的持久化 + 合规达标

配置完别直接上线，按这四步验证，确保真的生效了。

第一步：确认 PVC 全部绑定成功

# 查看所有PVC状态，必须全部Bound
kubectl get pvc -n kingbase
kubectl get pvc -n dmdb

✅ 正常结果：数据、日志、归档、审计、守护进程日志所有 PVC 全部显示 Bound 状态。

第二步：删除 Pod 重建，验证日志连续

# 1. 先记录当前日志最新时间
kubectl exec -it dmdb-0 -n dmdb -- tail -1 /dm/log/dm_dmdb0_*.log

# 2. 删除Pod，触发重建
kubectl delete pod dmdb-0 -n dmdb

# 3. 等待启动后，再次查看日志
kubectl exec -it dmdb-0 -n dmdb -- tail -20 /dm/log/dm_dmdb0_*.log

✅ 正常结果：旧日志完整保留，新日志追加在后面，时间连续，没有清零。

第三步：验证分类写入正常

# 验证运行日志有新内容
kubectl exec -it kingbase-0 -n kingbase -- ls -lh /opt/kingbase/log/

# 验证归档日志生成
kubectl exec -it kingbase-0 -n kingbase -- ls -lh /opt/kingbase/arch/

# 验证审计日志生成
kubectl exec -it kingbase-0 -n kingbase -- ls -lh /opt/kingbase/audit/

✅ 正常结果：三类目录都有对应文件生成，大小持续增长。

第四步：合规性验证（等保专项）

1. 审计日志是否覆盖登录、DDL、高危 DML 操作
2. 审计日志留存周期是否≥180 天
3. 审计日志是否具备防篡改能力（加密 / 签名）
4. 日志是否具备集中备份，单节点故障不丢失 ✅ 全部满足即可通过等保三级审计项检查。

---

总结

容器化数据库日志持久化，本质就三件事：路径搞对、独立挂载、全生命周期管控。不要依赖默认路径，显式配置最稳妥；不要图省事混在一个盘里，分目录挂载收益远大于额外成本；不要忘了轮转清理和分级留存，不然早晚打爆磁盘。

日志是排障的依据、合规的底线，看似小事，实则是生产稳定性和合规性的重要基石，值得做扎实。尤其是主备集群场景，守护进程日志、监视器日志同样重要，漏一个都可能在故障时掉链子。

政务选金仓，金融选达梦；MySQL 迁移选金仓，Oracle 迁移选达梦。

📚 专栏推荐：专注 SpringBoot3 + 人大金仓 + 达梦信创实战，持续输出生产级部署、性能调优、安全合规、避坑指南干货，关注不迷路。

觉得文章有用的话，欢迎点赞、收藏、关注三连，后续更新更多信创数据库云原生落地的硬核内容。