删除主题为什么是高危操作
kafka-topics.sh 的 --delete 会把主题的配置、分区数据和消费组位移记录一起清理，且不可恢复——除非数据在其他系统另有副本或备份。删除动作本身不复杂，难的是判断「这个主题真的没人用了」：共享集群里同名主题可能被别的团队引用，停写观察远比事后追责便宜。
基本信息
| 命令 | kafka-topics.sh --bootstrap-server <地址> --delete --topic <名字> |
|---|---|
| 前提 | 集群开启 delete.topic.enable，否则只做标记删除 |
| 影响面 | 分区数据、位移记录一并清理，不可逆 |
| 建议流程 | 停写 → 观察无消费 → 备份或改名 → 删除 |
典型使用场景
- 下线废弃业务主题：确认无生产写入与消费依赖后再删
- 测试集群清理：删除大量临时主题回收磁盘
- 主题改名迁移后的收尾：旧主题停写一段时间后再删除
- 误建主题的清理：刚创建、无数据的主题可快速删除
- 容量紧张时的紧急回收：优先删确定无用的历史主题，而不是删当前热点数据
删除前核对三步
删除前核对三步
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders # 看分区、副本与当前规模
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --all-groups --describe \
| grep orders # 列出仍在消费该主题的组
kafka-run-class.sh kafka.tools.GetOffsetShell \
--bootstrap-server localhost:9092 --topic orders # 确认最新位移是否还在增长
# 以上均确认无依赖后执行删除
kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic orders删除行为读法
| 现象 | 含义 | 处理 |
|---|---|---|
| 命令返回成功但主题仍在 | 旧版本为标记删除，等待异步清理 | 确认 delete.topic.enable 并等待清理完成 |
| describe 报 Topic not exists | 已删除 | 不可恢复，只能重建 |
| 删除后重建同名主题 | 位移记录也已清空 | 消费端按 auto.offset.reset 重新定位 |
| 删除卡住不消失 | 存在副本下线或 controller 异常 | 先排查 controller 与 broker 状态 |
删除是终态操作：生产环境建议先停止写入并改名下线观察一段时间，确认无业务影响再执行删除；有重放需求的主题必须先落备份。
主题删除不会自动清理消费组本身，但相关位移会被清除；如果下游依赖历史位移做增量重放，删除前要先把位移或数据导出。