FE 倒下了，但我挺住了——Doris FE 挂机应急指南

作者：Administrator 发布时间： 2024-12-22 阅读量：20 评论数：0
大数据
#大数据

在分布式系统中，意外情况的发生几乎是不可避免的。Doris FE（Frontend）作为系统的核心组件之一，承担了元数据管理和调度等关键任务，一旦发生异常，可能会对整个系统的稳定性造成影响。面对 FE "倒下"的场景，作为运维人员或技术支持，你需要的不仅是冷静，更需要一套高效、可操作的应急方案。本指南旨在从不同场景入手，帮助你快速定位问题、恢复服务，并建立高可用的应对策略，让 FE 的每一次"倒下"都成为提升系统稳定性的契机。

一、FE 的 Master、Follower、Observer 都是什么？

首先明确一点，FE 只有两种角色：Follower 和 Observer。而 Master 只是一组 Follower 节点中选择出来的一个 FE。Master 可以看成是一种特殊的 Follower。所以当我们被问及一个集群有多少 FE，都是什么角色时，正确的回答当时应该是所有 FE 节点的个数，以及 Follower 角色的个数和 Observer 角色的个数。

所有 Follower 角色的 FE 节点会组成一个可选择组，类似 Paxos 一致性协议里的组概念。组内会选举出一个 Follower 作为 Master。当 Master 挂了，会自动选择新的 Follower 作为 Master。而 Observer 不会参与选举，因此 Observer 也不会成为 Master。

一条元数据日志需要在多数 Follower 节点写入成功，才算成功。比如 3 个 FE，2 个写入成功才可以。这也是为什么 Follower 角色的个数需要是奇数的原因。

Observer 角色和这个单词的含义一样，仅仅作为观察者来同步已经成功写入的元数据日志，并且提供元数据读服务。他不会参与多数写的逻辑。

通常情况下，可以部署 1 Follower + 2 Observer 或者 3 Follower + N Observer。前者运维简单，几乎不会出现 Follower 之间的一致性协议导致这种复杂错误情况（企业大多使用这种方式）。后者可以保证元数据写的高可用，如果是高并发查询场景，可以适当增加 Observer。

二、日志收集

出问题前后1天左右的日志（如果是多节点，每个节点都提供）：

  • fe/log目录下的 fe.log、fe.audit.log、fe.gc.log、fe.out

  • fe/doris-meta/bdb/je.info.0 (bdbje日志, 日志打印是utc时间 +8h是北京时间)

  • 版本信息（精确到commit 号）

    • select @@version_comment;

    • 执行start_fe.sh --version会在控制台或fe.out打印commit信息

  • show frontends 的全部输出

三、故障场景与解决方案

Q1. 磁盘空间不足

  • 现象1：bdbje禁止写入 "com.sleepycat.je.DiskLimitException”

  • 现象2：{doris-meta}/bdb/je.info.0 中出现 Node waiting for disk space to become available. Disk limit violation:Disk usage is not within je.maxDisk or je.freeDisk limits and write operations are prohibited:

  • 原因：fe最低要求5g的磁盘空间

  • 恢复方案：删除其他文件占用的空间即可。

Q2. 时钟不同步

  • 现象：fe.log日志出现"Clock delta: xxxx ms. between Feeder: xxxx and this Replica exceeds max permissible delta: xxxx ms."

  • 原因：bdbje 要求各个节点之间的时钟误差不能超过一定阈值。如果超过，节点会异常退出。我们默认设置的阈值为 5000 ms，由 FE 的参数 max_bdbje_clock_delta_ms 控制，可以酌情修改。

  • 恢复方案：

    • 建议使用 ntp 等时钟同步方式保证 Doris 集群各主机的时钟同步。

    • 手动date命令修改时间

Q3. 不能达成多数派

  • 现象1：current group size: 3(查看doris-meta/bdb/je.info.0)

  • 现象2：fe.log: Commit policy: SIMPLE_MAJORITY, required x replica. But none were active with this master.

  • 原因：doris是多数派机制，需要大于集群一半以上的节点参与选举才会选举成功

  • 恢复方案：同时启动2个或3个节点即可正常启动集群

Q4. Meta过期

  1. meta out of date偶尔打印一次是正常的，可调fe.conf参数

    meta_delay_toleration_second
默认值：300（5 分钟）

如果元数据延迟间隔超过 meta_delay_toleration_second，非主 FE 将停止提供服务

  2. 启动时打印少数几次meta out of date，然后不再打印，是正常现象，如果持续打印是有问题的。恢复方案：确保 FE 全部拉起，并且有主

Q5. FE OOM

1、JVM oom查看fe.out

2、操作系统oom killer

dmesg -T | grep java

3、在内存使用高的时候分别执行搜集内存占用信息

jmap -histo pid > jmap1.txt (不触发old gc)

jmap -histo:live pid > jmap2.txt (触发old gc)

Q6. FE 启动失败，fe.log 中一直滚动 "wait catalog to be ready. FE type UNKNOWN"

原因1：本次 FE 启动时获取到的本机 IP 和上次启动不一致，通常是因为没有正确设置 priority_network 而导致 FE 启动时匹配到了错误的 IP 地址。恢复方案：需修改 priority_network 后重启 FE。

原因2：集群内多数 Follower FE 节点未启动。比如有 3 个 Follower，只启动了一个。恢复方案：此时需要将另外至少一个 FE 也启动，FE 可选举组方能选举出 Master 已提供服务。

如果以上情况都不能解决，可以按照 Doris 官网文档中的元数据运维文档进行恢复，也可以参考以下步骤进行恢复。

注意⚠️

Observer节点不参与选举，所以1 Folower + 1 Observer节点在 follower 节点挂掉的时候请参考元数据运维文档进行恢复。

恢复方案1(集群中有正常工作的fe)：

  1. 停止异常 FE 的进程

    sh bin/stop_fe.sh

  2. 备份异常fe的元数据，并新建一个空白的元数据目录

    # 默认的fe元数据目录为fe/doris-meta，如果指定了其他存储路径可通过fe/conf/fe.conf的meta_dir配置查看具体的路径
mv doris-meta doris-meta_bak # 重命名文件
mkdir doris-meta # 新建空白的元数据目录

  3. 以 --helper 的方式启动异常 FE

    # helper_fe_ip 为当前 FE 集群中任一存活的节点，填master节点的ip和端口即可
sh bin/start_fe.sh --helper <helper_fe_ip>:<fe_edit_log_port> --daemon

恢复方案2(集群中所有fe都启动不了)：

  1. 停止所有的 FE 进程，如果配置了自动拉起服务要记得关闭

    sh bin/stop_fe.sh

  2. 备份元数据目录(默认路径是 fe/doris-meta）

    cp -r doris-meta doris-meta_bak # 备份文件

  3. 在所有 FE 中找一个 doris-meta/image 目录下以image为前缀、后缀数字最大的节点当作要恢复的节点。

    -rw-rw-r-- 1 huanghaijun huanghaijun 61M Dec 16 10:20 image.4107960
-rw-rw-r-- 1 huanghaijun huanghaijun 62M Dec 17 13:01 image.4157960

    在上面这个节点中image.4157960的后缀数字是最大的，需要与其他的 FE 对应的image文件进行比较，找后缀数字最大的节点当作要恢复的节点。

  4. 以元数据恢复模式启动要恢复的节点(慎用！可能会导致脑裂)

    doris版本大于等于2.0.2

    sh bin/start_fe.sh --metadata_failure_recovery --daemon

    doris版本小于2.0.2，需要在 fe.conf 中添加如下配置再启动

    metadata_failure_recovery=true

  5. 如果正常，这个 FE 会以 MASTER 的角色启动，在 fe.log 应该会看到 transfer from XXXX to MASTER 等字样。

  6. 启动完成后，先连接到这个 FE，执行一些查询导入，检查是否能够正常访问。如果不正常，有可能是操作有误，建议仔细阅读以上步骤，用之前备份的元数据再试一次。如果还是不行，问题可能就比较严重了，建议联系官方人员处理。

  7. 如果成功，通过 show frontends; 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master，然后把其他 FE 节点下线。

    ALTER SYSTEM DROP FOLLOWER "follower_host:edit_log_port"

  8. 重启这个 FE（重要），先停止这个fe

    sh bin/stop_fe.sh

    doris版本大于等于2.0.2

    sh bin/start_fe.sh  --daemon

    doris版本小于2.0.2，需要在 fe.conf 中去掉如下配置再启动

    # metadata_failure_recovery=true

  9. 启动完成后，先连接到这个 FE，执行一些查询导入，检查是否能够正常访问。然后把其他下线的 FE 节点再加入到集群。

    ALTER SYSTEM ADD FOLLOWER "follower_host:edit_log_port"

  10. 那么此时已经恢复一个节点了，对于其他还未恢复的节点，可以参考恢复方案1来恢复。

四、高可用与预防措施

  • 配置高可用集群 一般建议配置 3 follower 集群，如果机器不够也可以配置 1 follower + 1 observer 集群，防止出现坏盘等意外出现数据丢失的问题，如果配置了高可用可以通过其他节点恢复。

  • 定期备份 可通过backup进行定期的数据备份，或者通过ccr来进行主备集群的数据同步。

  • 监控与报警系统优化 通过doris manager来接管集群，可配置自动拉起服务和告警服务。

如果以上方案都无法解决您的问题，收集好相关日志信息，联系官方人员来解决，或者在论坛提一个帖子。

参考链接：https://mp.weixin.qq.com/s/OkI7TknhnQ4HqfzBV2pAxQ

上一篇：nvm国内安装工具nvm-cn
下一篇：CentOS7升级到CentOS8

评论