Doris FE 运维进阶：从“救火队员”到“系统专家”的SOP

我想，每个负责线上服务的技术同学，可能都经历过类似的场景：凌晨三点，刺耳的告警电话把人从梦中惊醒，打开电脑，看到群里业务方一连串的“系统是不是有问题？”。那一刻，压力瞬间拉满。

Doris FE 作为集群的“大脑”，它的稳定性至关重要。但作为一个复杂的分布式系统，我们必须承认，意外总会发生。当意外来临时，最考验一个团队的，不是不出问题，而是在问题发生后，我们能否从容、有序地去应对。

我见过太多手忙脚乱的“救火”现场，大家凭着感觉和零散的经验各自为战，不仅效率低下，还可能因为误操作引发二次故障。

今天这篇文章，不想跟你聊什么高深的理论，就是想跟你分享一套我们内部沉淀下来、行之有效的应急思路。希望能帮你和你的团队，在下一次面对“FE倒下”的场景时，能少一些焦虑，多几分从容。

第一步：咱们先“对对表”，FE到底有几种角色？

在动手排查之前，我们得先确保大家对FE的理解在同一个频道上。这一点非常重要，因为它直接关系到你对很多集群问题的判断。

你可能经常听到 Master、Follower、Observer 这些名词，它们具体是什么关系呢？

简单来说，FE其实只有两种基础角色：Follower 和 Observer。

• 你可以把所有 Follower 看成一个“决策小组”。这个小组的成员有投票权，大家会一起投票选出一位“主心骨”来负责处理所有的元数据写入请求，这位“主心骨”就是我们常说的 Master。所以，Master 本质上是一位承担了特殊职责的 Follower。如果现任Master挂了，这个决策小组会立刻发起投票，选出新的Master。

• 而 Observer 就像它的名字一样，是“观察员”。它会实时同步决策小组的决议（元数据），可以分担大量的查询请求，但它没有投票权，只是默默地观察和同步，因此也永远不会当选为Master。

一个关键机制：多数派说了算

任何一项决议（比如创建一个新表），都必须得到“决策小组”（所有Follower）里超过半数成员的同意和确认，才算生效。比如，一个有3个Follower的小组，至少需要2个节点确认写入成功，操作才算成功。这也是为什么我们总是建议 Follower 的数量保持为奇数，就是为了避免出现票数相等，谁也说服不了谁的尴尬局面。

两种常见的部署架构

• 简化部署：1 Follower + N Observer
  。这种方式运维起来最省心，因为只有一个决策者，不存在复杂的选举问题，很多企业用户都喜欢这种方式。
• 高可用部署：3 Follower + N Observer
  。这是典型的“高可用”配置，能确保元数据写入服务不会因为单点故障而中断。如果你的查询压力大，可以多加几个Observer来“减负”。

第二步：你的“应急工具箱”，都备齐了吗？

好了，搞懂了角色，现在我们来准备工具。当FE出现问题时，一个专业的工程师会像经验丰富的医生一样，按部就班地使用工具进行检查，而不是上来就“下猛药”。

这份清单，就是你的“应急工具箱”，建议你和你的团队都把它作为标准操作流程（SOP）。

✅ 1. 日志文件 (Logs) - 现场的第一手资料

这是排查问题的起点和基石。请收集问题发生前后1天左右、所有FE节点的日志。

• fe/log/fe.log
  : 你的主战场。绝大多数的错误和异常都在这里。
• fe/log/fe.audit.log
  : 行为记录仪。能帮你精准回溯出事前，到底有哪些“可疑”的SQL被执行了。
• fe/log/fe.gc.log
  : JVM的心电图。FE的长时间卡顿、内存问题，基本都能在这里找到线索。
• fe/log/fe.out
  : 控制台输出。有时候，致命的底层错误会比fe.log
  更早出现在这里。
• fe/doris-meta/bdb/je.info.0
  : 元数据引擎的“黑匣子”。这个日志知道很多关于选举、数据同步的“秘密”。记住：它的日志时间是UTC，需要+8小时换算成北京时间。

✅ 2. 状态与版本信息 (Status & Version) - 确认“身份”

• 版本信息：请务必提供精确到commit ID的版本号。可以通过start_fe.sh --version
  或select @@version_comment;
  获取。相信我，明确版本能帮你省下大把跑偏的时间。
• FE节点状态：提供SHOW FRONTENDS
  命令的完整输出，让你对整个“决策小组”的健康状况一目了然。

✅ 3. 进程与系统快照 (Process & System Snapshots) - 深度体检

• 主机监控信息：CPU、内存、磁盘IO、网络的监控图，能帮你判断FE是不是被“恶劣的生存环境”给拖垮了。
• 操作系统日志：执行dmesg -T > dmesg.txt
  ，看看是不是操作系统这位“老大哥”因为内存紧张，对FE动了手（OOM Killer）。
• Java进程快照（如果FE卡住或内存异常）：
• jstack -l <pid>
  ：给所有线程拍个“X光”，看看谁在“摸鱼”，谁被“卡住”了。
• jmap -histo:live <pid>
  ：看看内存里到底是谁最“胖”，占了最多的空间。

掌握这套清晰的排查思路和清单，不仅能让你在遇到问题时更加从容不迫，也能在寻求社区帮助时，提供最有效的信息，从而更快地解决问题。

在下一篇文章中，我们将进入更具体的实战环节，针对磁盘已满、时钟不同步、无法选主等经典故障场景，分享详细的恢复步骤。