Linux Cassandra数据目录布局、CommitLog、SSTable 与 Memtable 管理

一、Cassandra 数据目录整体布局

1.1 默认与推荐目录（cassandra.yaml 配置）

Cassandra 数据目录由 cassandra.yaml 指定，生产强烈建议分离磁盘：

data_file_directories:
-/data/cassandra/data# SSTable 主目录

commitlog_directory:/data/cassandra/commitlog# CommitLog

hints_directory:/data/cassandra/hints# Hinted Handoff

saved_caches_directory:/data/cassandra/saved_caches# Key/Row Cache 保存

cdc_raw_directory:/data/cassandra/cdc_raw# Change Data Capture（可选）

实际布局（以 /data/cassandra/data 为例）：

/data/cassandra/data
└── keyspace1
    ├── table1-uuid1
    │   ├── backups/            # snapshot 目录
    │   ├── snapshots/          # 同上，旧版兼容
    │   ├── la-1-big-Data.db    # SSTable 数据文件
    │   ├── la-1-big-Index.db
    │   ├── la-1-big-Filter.db  # Bloom Filter
    │   ├── la-1-big-Summary.db
    │   ├── la-1-big-TOC.txt    # 目录文件
    │   └── ...                 # 其他组件文件（CompressionInfo、Statistics 等）
    ├── table2-uuid2
    └── system_keyspace...

每个表目录名格式：<table_name>-<uuid>（uuid 为表ID，防止重名）

1.2 目录大小监控与规划

生产实践：

• Data目录：最大，占90%+空间
• CommitLog：固定段大小（默认32MB/段），活跃段少，旧段可归档
• Hints：节点宕机时增长快，恢复后清理
• Saved_Caches：重启时加载，占用小

监控命令：

du -sh /data/cassandra/*      # 总览
du -sh /data/cassandra/data/*/* | sort -hr | head -20  # トップ大表

nodetool 辅助：

nodetool tablestats keyspace.table | grep "Space used"
nodetool cfstats              # 所有表空间统计

生产阈值：Data目录使用率 >80% 告警，预留50%用于Compaction临时空间。

1.3 常见目录问题

• 空间爆炸：墓碑堆积 + Compaction落后 → SSTable 数爆炸
• 权限错误：cassandra 用户无写权限 → 启动失败
• 磁盘损坏：单文件损坏 → nodetool scrub 或删除坏SSTable

二、CommitLog 详解与管理

2.1 CommitLog 作用与原理

CommitLog 是 Cassandra 耐久性保证的核心：

• 写操作先顺序追加到 CommitLog（持久化）
• 再写入 Memtable
• 宕机恢复时，从 CommitLog replay 未 flush 数据

特点：

• 纯顺序写，几乎零随机IO
• 分段管理：CommitLogSegment，默认32MB（commitlog_segment_size_in_mb）
• 活跃段：当前写段
• 旧段：Memtable flush后可归档/删除

5.0变化：支持压缩CommitLog（commitlog_compression），减少磁盘占用。

2.2 CommitLog 目录结构

/data/cassandra/commitlog
├── CommitLog-7-1234567890.log   # 段文件，命名：版本-段ID-时间戳
├── CommitLog-7-1234567891.log
└── archive/                     # 可选归档目录

2.3 CommitLog 管理实战

• 参数调优（cassandra.yaml）：

commitlog_segment_size_in_mb:32# 大段减少管理开销，小段更快回收
commitlog_total_space_in_mb:8192# 总上限，超过阻塞写（生产推荐磁盘大小/4）
commitlog_sync:periodic
commitlog_sync_period_in_ms:10000

• 归档旧段：

生产脚本：flush所有Memtable后，移动旧段到archive

nodetool flush               # 全集群flush
mv /data/cassandra/commitlog/CommitLog-* /data/archive/commitlog/

• 恢复与Replay：

节点启动自动replay，日志：

INFO  [CommitLogReplayer] Replaying CommitLog segments...

• 故障处理：

CommitLog损坏 → commit_failure_policy: stop（推荐），手动删除坏段（高风险）

2.4 生产最佳实践

• CommitLog单独NVMe盘（高IOPS）
• 监控段数量：>1000 → flush慢或写爆
• CDC启用时，CommitLog不可删（cdc_raw_directory同步）

案例：某集群CommitLog盘满 → 写阻塞 → 调高总空间 + 分离盘，解决。

三、Memtable 详解与管理

3.1 Memtable 作用与结构

Memtable 是写路径的内存缓冲：

• 写操作：CommitLog后 → Memtable
• 达到阈值 → flush到SSTable
• 每个表独立Memtable

4.x：SkipList结构（有序，内存碎片高）

5.0重大升级：Trie-based Memtable（前缀树）

• 内存利用率更高（减少碎片）
• offheap模式更高效
• 支持动态调整

3.2 Memtable 配置与监控

关键参数（cassandra.yaml，第4篇回顾）：

memtable_allocation_type:offheap_objects# 5.0推荐
memtable_offheap_space_in_mb:16384
memtable_flush_writers:8

监控：

nodetool tablestats keyspace.table | grep -A5 "Memtable"
# 输出：Cell count, Data size, Off-heap size, Flush progress 等

nodetool tpstats | grep MemtableFlusher # Pending flush任务

3.3 Memtable 管理操作

• 强制flush：

nodetool flush keyspace table   # 指定表
nodetool flush                  # 全集群

场景：重启前drain、Memtable堆积

• 阈值触发：

自动：memtable_heap/offheap_space、flush_period等

• 故障恢复：

Memtable丢失（宕机未flush） → CommitLog replay重建

生产问题：offheap泄漏（旧版bug） → 升级5.0+ 或监控Direct Memory

四、SSTable 详解与管理

4.1 SSTable 原理与格式

SSTable（Sorted String Table）是磁盘持久化结构：

• Immutable：一旦flush，不可修改
• 多SSTable合并 → Compaction
• 每个SSTable一系列文件

典型文件（la-1-big- 前缀，la为Level 0）：

• -Data.db：实际行数据
• -Index.db：Partition Index（键到位置）
• -Summary.db：Index采样
• -Filter.db：Bloom Filter
• -TOC.txt：组件列表
• -CompressionInfo.db：压缩信息
• -Statistics.db：元数据（min/max timestamp、墓碑数）
• -Digest.sha1：校验

5.0新格式：mc/mv（Trie压缩），更小更快

4.2 SSTable 生命周期

1. Memtable flush → 新SSTable（Level 0）
2. Compaction合并 → 高Level或新世代
3. 删除条件：墓碑GC grace过期 + Compaction清理

4.3 SSTable 管理命令

• 查看SSTable：

ls /data/cassandra/data/keyspace/table-*/  # 手动
nodetool listsnapshots                 # Snapshot相关
nodetool tablestats | grep "SSTables"

• 升级SSTable格式（版本升级后）：

nodetool upgradesstables keyspace table

• 校验与修复：

nodetool scrub keyspace table       # 校验坏SSTable
nodetool verify                     # 类似

坏SSTable：手动删除文件（高风险，最后手段）

• 手动加载：

sstableloader（批量导入）

4.4 生产SSTable 问题排查

• SSTable数爆炸 → Compaction落后 → 提高concurrent_compactors
• 读放大高 → SSTables per read >10 → 强制compact
• 墓碑警告 → Statistics.db中tombstones高 → 调整gc_grace_seconds或repair

案例：某表SSTable达数千 → 读延迟秒级 → 切换LCS + 手动compact，恢复ms级。

五、Hints 与 Saved Caches 管理

5.1 Hints

• 节点宕机时，Coordinator存Hint
• 恢复后递交
• 目录：hints_directory
• 文件类似CommitLog

管理：max_hint_window_in_ms（默认3h），超时丢弃

监控：nodetool netstats | grep Hints

清理：nodetool disablehinteddandoff + truncate hints表

5.2 Saved Caches

• Key Cache / Counter Cache 保存到磁盘
• 重启加载

管理：saved_caches_directory，空间小，通常忽略

六、生产存储管理最佳实践

1. 磁盘分离：CommitLog NVMe、Data 大容量SSD
2. 定期巡检：脚本监控du + nodetool tablestats
3. 自动化清理：Snapshot定期删除旧版
4. 备份集成：Snapshot + Incremental
5. 容量告警：Data >70%、CommitLog >80%

完整巡检脚本示例：

#!/bin/bash
echo"目录占用"
du -sh /data/cassandra/*
echo"大表Top10"
nodetool cfstats | grep -A10 "Table: " | grep "Space used"
echo"Memtable状态"
nodetool tablestats prod.bigtable | grep Memtable