Apache doris FE元数据运维

  Apache Doris 代码仓库地址：apache/incubator-doris 欢迎大家关注加星
 

---

名词解释

• FE：Frontend，即 Doris 的前端节点。主要负责接收和返回客户端请求、元数据以及集群管理、查询计划生成等工作。
• BE：Backend，即 Doris 的后端节点。主要负责数据存储与管理、查询计划执行等工作。
• bdbje：Oracle Berkeley DB Java Edition。在 Doris 中，我们使用 bdbje 完成元数据操作日志的持久化、FE 高可用等功能。

整体架构

如上图，Doris 的整体架构分为两层。多个 FE 组成第一层，提供 FE 的横向扩展和高可用。多个 BE 组成第二层，负责数据存储与管理。本文主要介绍 FE 这一层中，元数据的设计与实现方式。

1. FE 节点分为 follower 和 observer 两类。各个 FE 之间，通过 bdbje（BerkeleyDB Java Edition）进行 leader 选举，数据同步等工作。
2. follower 节点通过选举，其中一个 follower 成为 leader 节点，负责元数据的写入操作。当 leader 节点宕机后，其他 follower 节点会重新选举出一个 leader，保证服务的高可用。
3. observer 节点仅从 leader 节点进行元数据同步，不参与选举。可以横向扩展以提供元数据的读服务的扩展性。

FE 元数据运维

FE 分为 Leader，Follower 和 Observer 三种角色。 默认一个集群，只能有一个 Leader，可以有多个 Follower 和 Observer。其中 Leader 和 Follower 组成一个 Paxos 选择组，如果 Leader 宕机，则剩下的 Follower 会自动选出新的 Leader，保证写入高可用。Observer 同步 Leader 的数据，但是不参加选举。如果只部署一个 FE，则 FE 默认就是 Leader。

第一个启动的 FE 自动成为 Leader。在此基础上，可以添加若干 Follower 和 Observer。

FE 高可用

1. 如果想实现FE真正的高可用，至少需要部署三个Follower角色的FE，对于高可用要求非常严格的企业，建议使用这种方式，但是这种方式也增加的元数据运维的难度，后面会将这种情况下常用的元数据运维方式，
2. 一个Follower角色的FE，一个Observer（定时去同步FE的元数据），因为Observer和Follower之间的元数据同步不是实时的，如果FE宕机，那么可能会损失几分钟的数据，这时候需要将这一段时间数据从新导入，这种情况对于一般企业特比是离线处理的理论上没多大问题，这种方式的好处就是元数据运维足够简答

FE 元数据运维

三 Follower 角色的 FE 元数据运维

最常见的就是突然某个FE宕机了，使用启动命令启动不了，严重情况下还可能引起其他FE宕机，常见的异常信息如下：

 repImpl=com.sleepycat.je.rep.impl.RepImpl@68fa4d19 props={REFRESH_VLSN=17921230, PORT=9010, HOSTNAME=172.22.197.238, P_NODETYPE1=ELECTABLE, NODE_NAME=172.22.197.238_9010_1611290318143, P_NODETYPE0=SECONDARY, P_NODENAME1=172.22.197.240_9010_1608972313975, P_PORT1=9010, P_NODENAME0=172.22.197.238_9010_1611290318143, P_PORT0=9010, P_HOSTNAME1=172.22.197.240, GROUP_NAME=PALO_JOURNAL_GROUP, P_HOSTNAME0=172.22.197.238, ENV_DIR=/hdd_data01/doris-meta/bdb, P_NUMPROVIDERS=2}
  at com.sleepycat.je.rep.InsufficientLogException.wrapSelf(InsufficientLogException.java:315) ~[je-7.3.7.jar:7.3.7]
  at com.sleepycat.je.dbi.EnvironmentImpl.checkIfInvalid(EnvironmentImpl.java:1766) ~[je-7.3.7.jar:7.3.7]
 ​

以下操作之前首先要做好FE节点的元数据备份，以防止误操作，导致元数据损坏造成不可修复的问题，切记！切记！切记！

1. 0.14.x之前版本：

具体步骤：

1. 停止所有load任务（这个很重要，避免在做元数据恢复的时候出现问题）
2. 删除元数据目录，然后重新创建
3. 从master节点拷贝元数据（或者去查看所有FE节点找到image版本号最大的那个，版本号最大的就是最新的元数据）到问题节点fe（将 fe.conf 中的 metadata_failure_recovery=true 配置项删除，或者设置为 false，这个非常重要），注意要修改image/VERSION 里的name,拷贝过来的是master的名称，改成该节点的名称
4. 执行 ALTER SYSTEM DROP FOLLOWER 删除改节点
5. 在问题节点使用--helper启动服务
6. 在mysql下执行 ALTER SYSTEM ADD FOLLOWER 将FE节点从新加入进去
7. 启动正常

2. 0.14.x之后的版本

具体步骤：

1. 停止所有load任务（这个很重要，避免在做元数据恢复的时候出现问题）
2. 删除元数据目录，然后重新创建
3. 执行 ALTER SYSTEM DROP FOLLOWER 删除改节点
4. 在问题节点使用--helper启动服务
5. 在mysql下执行 ALTER SYSTEM ADD FOLLOWER 将FE节点从新加入进去
6. 启动正常
7. 如果启动失败，可以参考上面0.14.x之前版本的启动方法

3. 如果Master宕机，导致整个集群宕机启动不了

针对这种情况，首先要查看所有FE节点的元数据，找到http://image.xxx，这里序号最大的一个FE节点，作为主节点

 # ll /hdd_data01/doris-meta/
 total 16
 drwxr-xr-x 2 root root 12288 Aug  3 14:33 bdb
 drwxr-xr-x 2 root root  4096 Aug  3 14:09 image
 # ll /hdd_data01/doris-meta/image/
 total 16192
 -rw-r--r-- 1 root root 16569647 Aug  3 14:09 image.107356508
 -rw-r--r-- 1 root root       83 Apr 16 12:58 ROLE
 -rw-r--r-- 1 root root       94 Apr 16 12:58 VERSION

然后按照下面的步骤执行：

1. 在 fe.conf 中添加配置：metadata_failure_recovery=true
2. 执行 sh bin/start_fe.sh daemon 启动这个 FE
3. 如果正常，这个 FE 会以 MASTER 的角色启动，类似于前面 启动单节点 FE 一节中的描述。在 fe.log 应该会看到 transfer from XXXX to MASTER 等字样,也可以通过Web页面来查看
4. 启动完成后，先连接到这个 FE，执行一些查询导入，检查是否能够正常访问。如果访问正常，则可以朝下进行，否则按照上面的步骤从来一次，或者选择一个其他FE节点执行上面的步骤，如果都不成功那么问题就严重了。
5. 如果成功，通过 show frontends; 命令，应该可以看到之前所添加的所有 FE，并且当前 FE 是 master。
6. 将 fe.conf 中的 metadata_failure_recovery=true 配置项删除，或者设置为 false，然后重启这个 FE（重要）
7. 重启正常以后，其他FE节点的加入，参考上面的0.14.x之前版本及0.14.x之后版本的操作步骤

FE磁盘损坏情况下的元数据运维

在某些极端情况下，磁盘上 image 文件可能会损坏，但是内存中的元数据是完好的，此时我们可以先从内存中 dump 出元数据，再替换掉磁盘上的 image 文件，来恢复元数据，整个不停查询服务的操作步骤

1. 集群停止所有 Load,Create,Alter 操作
2. 执行以下命令，从 Master FE 内存中 dump 出元数据：(下面称为 image_mem)

 curl -u $root_user:$password http://$master_hostname:8030/dump

1. 用 image_mem 文件替换掉 OBSERVER FE 节点上meta_dir/image目录下的 image 文件，重启 OBSERVER FE 节点， 验证 image_mem 文件的完整性和正确性（可以在 FE Web 页面查看 DB 和 Table 的元数据是否正常，查看fe.log 是否有异常，是否在正常 replayed journal）
2. 依次用 image_mem 文件替换掉 FOLLOWER FE 节点上meta_dir/image目录下的 image 文件，重启 FOLLOWER FE 节点， 确认元数据和查询服务都正常
3. 用 image_mem 文件替换掉 Master FE 节点上meta_dir/image目录下的 image 文件，重启 Master FE 节点， 确认 FE Master 切换正常， Master FE 节点可以通过 checkpoint 正常生成新的 image 文件
4. 集群恢复所有 Load,Create,Alter 操作

注意：如果 Image 文件很大，整个操作过程耗时可能会很长，所以在此期间，要确保 Master FE 不会通过 checkpoint 生成新的 image 文件。 当观察到 Master FE 节点上 meta_dir/image目录下的 image.ckpt 文件快和 image.xxx 文件一样大时，可以直接删除掉image.ckpt 文件。