3.4 监控、备份与日常运维：值班清单

3.4 监控、备份与日常运维

本节摘要：图库上生产后，运维关心的无非四件事：跑得快不快、内存够不够、数据丢不丢、出事多久能恢复。本节给出一份可执行的值班清单：读什么指标、备份用什么命令、恢复怎么演练、容量怎么预估，并把"慢查询"的排查路径与第 2 章的执行计划知识接起来。

前三节讲的是"把数据写对写稳"，本节讲图库住进生产环境后的日常照看。运维 Neo4j 的心智负担其实不大——它没有复杂的外置依赖，难点在于出事前不练手，出事时一定手忙脚乱。

一、日常要看哪些指标

五个指标覆盖九成日常健康判断：

配置层面有两个参数值得一开始就调对：页缓存（缓存存储文件，应能装下整个图数据，装不下则按热点估）与堆内存（只服务查询执行与事务状态，别把堆当页缓存用——两者职责不同，混着调是新手最常见的错配）。

二、慢查询的排查路径

值班遇到"变慢了"，按固定路径走，别上来就重启：

第一步：query.log 找到具体的慢语句
第二步：EXPLAIN（不执行）看计划形状——有没有 NodeByLabelScan
第三步：PROFILE 真跑一次，看 db hits 落在哪一层
第四步：锚点没走索引 → 建索引或改写谓词（第 2.4 节四连）
第五步：走了索引仍慢 → 检查变长路径上界、笛卡尔积、内存参数
​

// 一个典型的"突然变慢"案例：变长路径少了上界
PROFILE MATCH (a:Person {name: 'Alice'})-[:KNOWS*]-(b:Person)
RETURN count(b)
// 计划里 Expand(All) 行数百万级 → 补上 *1..3 后 db hits 断崖式下降
​

三、备份：命令很简单，纪律在演练

社区版用 dump（需停机或库不可写），企业版有在线一致性备份 backup。命令本身一行：

# 停机备份：先停库，再导出
neo4j-admin database dump neo4j --to-path=E:/backup/2026-08-29

# 恢复（覆盖目标库）
neo4j-admin database load neo4j --from-stdin --overwrite-destination < E:/backup/2026-08-29/neo4j.dump
​

恢复演练检查单：
1. 在测试机上 load 备份包
2. MATCH (n) RETURN count(n) 与生产基线对账
3. 抽查 10 条核心业务查询结果一致性
4. 记录演练耗时 → 这就是真实的 RTO（恢复时长）
​

⚠️ 没演练过的备份等于没有备份。 dump 文件躺在盘上不代表能恢复——版本不匹配、目标目录有残留库、权限不对，都会让恢复在现场失败。把演练做成季度动作，RTO 用实测数字回答。

四、容量规划的两个粗算法

磁盘：图数据存储大小 ≈ 节点数 × 节点记录开销 + 关系数 × 关系记录开销 + 属性块。粗略按"每百万节点 + 每百万关系各占几十 MB、属性另计"起步，再留 40% 余量给事务日志与索引。

内存：页缓存目标 = 全库存储文件总量；装不满就按"热数据 + 索引"估。堆给 8～16 GB 通常够用，再大不如把内存让给页缓存。两个参数的关系一句话：堆服务计算，页缓存服务数据。

示例：5 亿关系、1 亿节点、属性文件 20 GB 的图
页缓存建议 ≈ 40 GB（装下全部存储文件）
堆内存     ≈ 12 GB
机器物理内存 ≈ 64 GB（页缓存 + 堆 + 操作系统余量）
​

五、故障分级与响应

把可能的故障按响应动作预分类，值班才有章法：

P0 进程崩溃   → 自动重启脚本拉起 → 从事务日志自动恢复 → 验证数据
P0 磁盘满     → 立即清理事务日志 → 扩容 → 排查写入洪峰来源
P1 查询变慢   → 慢查询日志 → PROFILE 路径（上文第二步起）
P1 误删数据   → 停写入 → 用最近的 dump 恢复到临时库 → 抽取误删子图回灌
P2 空间爬升   → 检查索引膨胀与日志保留策略 → 定期清理孤儿节点
​

误删的应对值得单独记：图数据"删错一个中间节点"会让一大片查询突然查不通，而 dump 恢复到临时库再抽取回灌，比全库回滚的代价小得多。

六、一次完整的值班记录示例

把本节清单拼成一天的值班日志，供对照：

09:00 巡检：页缓存命中率 99.2%，GC 正常，磁盘余量 62% —— 绿灯
11:30 告警：昨日订单查询耗时 800ms（基线 40ms）
  → query.log 定位到新上线的运营报表
  → EXPLAIN 发现 NodeByLabelScan（缺索引）
  → 建 order_created_at 索引，耗时回落 35ms —— 关单
15:00 例行：检查 dump 备份任务成功，异地上传校验通过
17:20 洪峰：ETL 全量刷新导致写延迟抖动
  → 确认为计划内任务，监控大盘标注，未扩容
​

注意 11:30 那单的处理路径：从告警到定位到修复，全靠"日志 → EXPLAIN → 索引"这套肌肉记忆——3.4 的所有清单，最终都是为了把这种处置变成不走脑子的流程。

七、备份策略的三个档位

不同业务的备份预期不同，按档位定策略比拍脑袋强：

档位一：开发/试验环境
  每周 dump 一次，滚动保留 2 份 —— 丢了重导即可

档位二：普通生产
  每日 dump + 异地拷贝，季度恢复演练
  RPO ≈ 24 小时，RTO 以演练实测为准

档位三：核心生产
  企业版在线 backup + 事务日志归档
  RPO 压到分钟级，恢复演练每月做
​

RPO（最多丢多少数据）与 RTO（多久能恢复）这两个词在故障复盘会上迟早出现——备份方案设计时就把它们写清楚，而不是事故后再补。

本节要点回顾

• 五指标值班表：缓存命中、堆与 GC、吞吐、磁盘、慢查询；
• 页缓存装数据、堆跑计算，职责分开调参；
• 慢查询固定五步排查路径，先 EXPLAIN 再 PROFILE；
• 备份命令一行，价值全在季度恢复演练与实测 RTO；
• 容量按"记录数 × 开销 + 属性 + 40% 余量"粗估，内存优先喂页缓存。

数据安全了，最后还剩一件事：谁能碰它。下一节收束本章——用户、角色与权限。