Apache Doris 故障自助排查指南（P0 篇）

Doris 运维的成本相较于其他相同定位的组件而言，其实已经下降了很多，但是在整体使用过程中，由于整体特性的研发行进速度过于快，所以整体稳定性上还是有一些瑕疵在内的。

所以本篇将先从 Doris 为什么能做到简易运维出发，进一步阐述如果遇到一些常见的故障时如何进行排查和解决，希望此篇能缩短你在应用 Doris 时的挠头时间。

极简运维特性简述
简易架构
Doris 的架构设计极为简洁，只有 FE 和 BE 两个进程，像元数据高可用、数据副本高可靠等特性，都依托与诸如 BDBJE 等内置化模块来完成，不依赖任何的三方组件即可完成集群的搭建。

两个独立进程，FE 负责对外提供交互、管理元数据信息、解析和下发执行任务等管控工作；BE 负责数据存储和计算工作，所以两个进程也是相对独立的，他们可以独立完成同类型角色的高可用部署。

负载均衡
Doris 的负载均衡有两类四种：

1. 读写负载均衡：查询负载均衡、写入负载均衡

2. 存储负载均衡：节点负载均衡、磁盘负载均衡

用以上各类负载均衡的能力以及更细粒度化的各项策略，Doris 无论是对外提供持续化的服务，还是对内进行集群资源的负载重分布以保证高可靠，都可自动化的进行，以此降低集群运维成本。

此篇在后续会以单一篇章详细介绍原理以及最佳实践。

自动修复
Doris 默认是 3 副本，是参照了 HDFS 组件的副本可靠性设计来保证自身的数据可靠性。

数据在保证 3 副本的情况下，若因为磁盘损坏、负载均衡迁移时缺少 Version、BE Publish 慢了或者卡着、compaction 等各种意外情况导致的某个副本损坏，Doris 会自动调度线程剔除坏副本，并从健康副本那 Copy 一份出来再 scp 到其他正常节点来完成自动化修复。

高可用/高可靠
以 FE 为例，在 BE 不参与到整个集群中之前，FE 也可以独立运行，且可以任意做高可用的拓展和缩减。

可以通过以下流程感受 Doris 部署高可用模式时的简易程度：

1. 准备新节点，下载解压缩二进制包

2. 配置 conf 中 networks 为当前节点 IP

3. 启动进程

4. 链接集群执行：alter system add follower/observer/backend “new_node_ip:9010/9050”;

以上四步即可完成对 FE 和 BE 高可用模式的拓展。

FE 节点元数据信息等会由 FE 内部 BDBJE 来自动初始化同步和持续增量同步，无需人工手动干预。

BE 节点，则会自动完成数据重分布，无需手工干预即可满足高可靠和高可用。

基本故障排查
以上简单描述了一下 Doris 具备的几项简易运维的特性能力。

若是由于一些异常导致非预期的集群状态，则需要使用或者运维同学具备一定的故障排查能力来定位问题和解决问题，我们先简单的根据故障级别给分分类：

P0：进程宕机或服务停止，对外提供服务不持续或者完全无法对外提供服务

P1：任务失败率高，或者查询/导入延迟很大，无法满足线上应用使用要求

P2：个别查询较慢，或者查询/导入异常失败，影响业务但是范围有限

P3：查询满足业务诉求，但希望查询速度可以更快，或者资源利用率更高

本篇就以 P0 级故障入手，来一起看看宕机如何进行排查和定位。

Frontend 宕机故障排查
1. 服务宕机
在正常运行过程中的 FE 如果突然出现宕机情况，大概率是 OOM 导致的异常情况。

无论排查哪种问题，Log 日志都应该是最高优和最首要的信息来源。

一般而言 fe.out 日志里会记录具体导致宕机的异常信息，fe.log 日志里会记录宕机前的有关进程运行信息。

在这两个日志中找寻相应日志，再辅以以下两个命令基本可以确定进程宕机的原因是否为 OOM。

// 命令一
dmesg -T
// 命令二
grep "Out of memory" /var/log/messages

1. OOM：查看 fe.conf 配置文件中 Xmx 的 JVM 大小，默认是 8GB 的大小，如果集群对外服务的量较大，建议配置到 16GB 或者 32GB，以保证 JVM 的稳定性。

2. 其他：根据日志来定位问题，此类问题较为少见，大多会与运行环境的突然变化有关系，诸如 IP、端口等通讯地址的改变，或者磁盘、内存等物理介质的变化等。

2. 服务无法启动
若进程无法启动，可观察日志来定位具体错误类型。而日常最常见的几种情况如下：

1. 当前节点的内网 IP 发生了变化，比如之前是 172.10.20.9，突然变化为 172.10.22.3，这类问题是违反了 Doris 使用的规则导致的，若想安全救回，可参考本公众号的 《一觉醒来 Apache Doris 机器 IP 变了？特供版拯救方案》。

2. FE 高可用模式下 Follower 或 Observer 与 Master 节点的时钟未同步，报错信息往往会带有 between…5000 等字样，翻译以后可知 FE 高可用的前置条件是必须时钟误差不得超过 5000 毫秒，时钟同步以后再启动即可。

3. 报错信息中若出现 Problem Closing transaction 27/20/15 等信息，可以检查一下挂载 Doris-FE-Meta 的目录剩余空间是否还有 5GB，若不足 5GB 则无法正常启动。

4. 若有其他异常导致无法启动的，可以及时向社区同学或者我寻求帮助。

3. 服务启动后无法连接
若进程启动后使用 JDBC 或者其他应用访问无响应，则常见可能有以下几种情况：

1. 观察启动后 fe.log 日志是否持续打印 wait catalog to be ready. FE type: UNKNOWN，若有此类日志字样，则大概率是选举过程中出现了故障导致无法正确选举出 Master 状态的 Follower。正确的操作方式如下：

1. 如果 FE 版本 < 2.0.2, 需要在 fe.conf 中添加配置：metadata_failure_recovery=true ，然后启动 FE，观察 FE 启动无问题后，注释或删除添加的配置项，重新后台启动 FE。 2. 如果 FE 版本 >= 2.0.2，执行 sh bin/start_fe.sh –metadata_failure_recovery 启动这个 FE。

1. 备份元数据，直接拷贝一份 doris-meta 目录即可

2. 联系社区同学查看问题根本原因

3. 若满足不了 2 的条件，则根据版本情况如下操作：

2. 端口防火墙或者安全策略组未开放，需要检查 FE 相关的端口是否开放，如 HTTP-Port 8030，JDBC-Port 9030 等。

3. 其他异常无法连接的情况，根据日志信息寻求社区同学的帮助。

Backend 宕机故障排查
1. 服务宕机
BE 进程宕机大致上有两种可能性，一种是 OOM，一种是引发 Core 导致的进程终止。

1. OOM：排查方法与 FE 给出的方法一样，这里不做赘述。给 BE 节点的内存建议 64G 及以上，同时保证独立部署，以免资源抢占导致的 OOM。

2. 引发 Core：首先可以到 be.out 日志中查看在宕机时打印的堆栈日志。

1. 若是查询异常引发的，则在日志中会有诸如 Query-Id:a32519741df141ac-8a81637065f8db46 之类的信息，拿到该查询 ID，到 FE 节点的 fe.audit.log 日志中进行查询。审计日志会留存所有执行过的语句，查询到异常语句后即可整理成 issue 或者文档发送给社区同学来确定问题，给出临时绕过方案或者紧急修复。整理的信息应当有：Query 语句、语句内相关的表结构、be.out 内的错误堆栈信息

2. 若 be.out 中有堆栈信息打印出来，但是 Query-Id 的内容为 0-0，则说明非查询导致的 BE 进程中断，这时需要及时整理出 be.out 内的堆栈信息，联系社区同学进行定位，同时最好无隐瞒的告知在宕机前是否有其他的行为动作。

3. 若确定某一异常行为的确会完整复现宕机异常，则可以打开 Linux-Core-Dump 来完整收集运行的统计信息， *.core 文件用 tar.gz 等压缩格式进行压缩后，将堆栈信息和 Core 文件一并发送给社区同学来定位问题所在。这里需要注意的是，Core 文件生成大小会比较大，最好保证生成目录可用空间足够大。

引发 Core 往往代表程序本身运行出现了非预期的异常情况，所以基本无法在用户侧完成紧急处理，故此在上面几条可能性上，基本每条都建议收集相应信息后与社区同学进行联系。虽然这看起来有点无奈，实则这是解决此类问题最高效的办法。

2. 服务无法启动
进程无法启动，往往跟环境有较大关系。常见的无法启动异常如下：

1. 启动日志中，有诸如 if your CPU does not support AVX2 日志字样，那表示当前 CPU 架构是不支持 AVX2 指令集的，可以通过 cat /proc/cpuinfo 来确定 CPU 的架构和型号，若是 ARM 架构的 CPU，则需要下载官网提供的 ARM 安装包，若是 X86 架构的 CPU，则需要下载 no_avx2 安装包。

2. 启动日志中，有诸如 res=file descriptors limit is too small 日志字样，表示当前启动的 ulimit 文件句柄数大小过小，默认需要 65536 及以上，若 CPU 性能可以，建议调大该值。

3. 启动日志中，有诸如 sysctl -w vm.max_map_count=2000000 日志字样，则表示该值过小，复制该命令运行一遍即可。

4. 启动日志中，有诸如 offswap 日志字样，则表示该节点未关闭交换空间，关闭交换空间后再启动即会正常运行。

若有启动时打印错误堆栈信息，则及时联系社区同学来确定具体问题。

3. 服务启动后无法加入集群
此类问题最常见是心跳丢失和通讯失败，和硬件环境以及防火墙、安全策略组有较大关系，若出现诸如心跳发送失败，或者 Networks RPC 通讯失败，先行检查一遍所有 BE 相关的端口是否开启，尤其是防火墙和安全策略组都要进行检查。

小结
若发生 P0 级宕机事件，而且还是在生产环境，最佳的处理方案是按照上述动作完成信息收集和基本大类问题定位，然后快速联系社区同学来完成问题精准定位和解决办法。

这时候一定不要选择死扛，不然线上业务的影响面将会越来越大，适时的寻找帮助才是最佳的处理方案。