Doris 社区周报每期会包含 FAQ 环节。我们会在社区论坛、Github ISSUE、Dev邮件组以及微信用户群中挑选一些主要问题并在 FAQ 环节中进行解答。
-
Dev 邮件组：dev@doris.apache.org
-
Github Issue：https://github.com/apache/incubator-doris/issues
-
社区论坛地址：https://github.com/apache/incubator-doris/discussions
1. 统计数据
共23位作者提交了40个 Commit 。感谢以下作者的贡献：
Mingyu Chen, zhoubintao, weizuo93, stdpain, Zhengguo Yang, Pxl, GeoffreyStark, EmmyMiao87, 王连松, zhangstar333, wangbo, shee, qiye, panlijie, luozenglin, ikaruga, ccoffline, caiconghui, Zeno Yang, Yunfeng,Wu, Xiang Wei, Stalary, Arthur.Zhang
最近2周，共修改新增代码行 11937 ，删除代码行 5502 。
2. 主要进展
2.1 新增功能
-
https://github.com/apache/incubator-doris/pull/6506
新增 json_array、json_object 和 json_quote 函数。
-
https://github.com/apache/incubator-doris/pull/6203
新增Resource Tag功能，支持按节点划分资源组进行资源隔离。
-
https://github.com/apache/incubator-doris/pull/6539
支持通过select outfile 功能并行导出查询结果。
-
https://github.com/apache/incubator-doris/pull/6102
支持create table as select 功能。
-
https://github.com/apache/incubator-doris/pull/6601
Spark Doris Connector 支持boolean类型。
2.2 Bug修复
-
https://github.com/apache/incubator-doris/pull/6448
修复历史delete任务没有被清理的问题。
-
https://github.com/apache/incubator-doris/pull/6559
修复colocate plan不能正确处理unstable状态的colocation 表的问题。
-
https://github.com/apache/incubator-doris/pull/6557
修复部分需要转发到Master FE的http接口无法正确鉴权的问题。
-
https://github.com/apache/incubator-doris/pull/6552
修复truncate table后，分桶数发生变化的问题。
-
https://github.com/apache/incubator-doris/pull/6560
修复部分情况下，colocation 表的副本处于DECOMMISSION状态无法恢复的问题。
-
https://github.com/apache/incubator-doris/pull/6564
修复部分情况下，pad 函数结果错误的问题。
-
https://github.com/apache/incubator-doris/pull/6586
1. 修复查询条件包含字符串函数时，可能导致scan node内存占用过高的问题。
2. 修复 regex 函数不支持 lazy mode 的问题。
2.3 功能改进
-
https://github.com/apache/incubator-doris/pull/6397
支持导入阶段并行发送数据，提升导入效率。
-
https://github.com/apache/incubator-doris/pull/6191
升级librdkafka以支持read_committed功能。
-
https://github.com/apache/incubator-doris/pull/6513
优化clone逻辑，优先选择版本数少的副本作为源副本。
-
https://github.com/apache/incubator-doris/pull/6475
create table like 语句支持复制源表的 rollup。
-
https://github.com/apache/incubator-doris/pull/5781
支持运行时动态调整BE的compaction线程数。
-
https://github.com/apache/incubator-doris/pull/6416
优化元数据的访问方式既避免空指针问题。
-
https://github.com/apache/incubator-doris/pull/6150
优化在初次组建集群时，因没有BE节点导致部分BI工具无法连接的问题。
-
https://github.com/apache/incubator-doris/pull/6501
FE增加配置以支持超过64字节长度的表名。
-
https://github.com/apache/incubator-doris/pull/6518
新增改写规则简化部分确定性的真值表达式。
-
https://github.com/apache/incubator-doris/pull/6522
新增FE元数据checkpoint相关监控指标。
-
https://github.com/apache/incubator-doris/pull/6579
like操作符支持整型列。
3. FAQ
Q：FE/BE 日志怎么看?
A：
很多情况下我们需要通过日志来排查问题。这里说明一下FE/BE日志的格式和查看方式。
FE：
FE日志主要有：
fe.log：主日志。包括除fe.out外的所有内容。
fe.warn.log：主日志的子集，仅记录 WARN 和 ERROR 级别的日志。
fe.out：标准/错误输出的日志（stdout和stderr）。
fe.audit.log：审计日志，记录这个FE接收的所有SQL请求。
一条典型的FE日志如下：
2021-09-16 23:13:22,502 INFO (tablet scheduler|43) [BeLoadRebalancer.selectAlternativeTabletsForCluster():85] cluster is balance: default_cluster with medium: HDD. skip
2021-09-16 23:13:22,502：日志时间。
INFO：日志级别，默认是INFO。
(tablet scheduler|43)：线程名称和线程id。通过线程id，就可以查看这个线程上下文信息，方面排查这个线程发生的事情。
BeLoadRebalancer.selectAlternativeTabletsForCluster():85：类名、方法名和代码行号。
cluster is balance xxx：日志内容。
通常情况下我们主要查看fe.log日志。特殊情况下，有些日志可能输出到了fe.out中。
BE：
BE日志主要有：
be.INFO：主日志。这其实是个软连，连接到最新的一个 be.INFO.xxxx上。
be.WARNING：主日志的子集，仅记录 WARN 和 FATAL 级别的日志。这其实是个软连，连接到最新的一个 be.WARN.xxxx上。
be.out：标准/错误输出的日志（stdout和stderr）。
一条典型的BE日志如下：
I0916 23:21:22.038795 28087 task_worker_pool.cpp:1594] finish report TASK. master host: 10.10.10.10, port: 9222
I0916 23:21:22.038795：日志等级和日期时间。大写字母I表示INFO，W表示WARN，F表示FATAL。
28087：线程id。通过线程id，就可以查看这个线程上下文信息，方面排查这个线程发生的事情。
task_worker_pool.cpp:1594：代码文件和行号。
finish report TASK xxx：日志内容。
通常情况下我们主要查看be.INFO日志。特殊情况下，如BE宕机，则需要查看be.out。
Q：FE/BE 节点挂了应该如何排查原因?
A：
BE进程是 C 进程，可能会因为一些程序Bug（内存越界，非法地址访问等）或 Out Of Memory（OOM）导致进程挂掉。此时我们可以通过以下几个步骤查看错误原因：
1. 查看be.out
BE进程实现了在程序因异常情况退出时，会打印当前的错误堆栈到be.out里（注意是be.out，不是be.INFO或be.WARNING）。通过错误堆栈，通常能够大致获悉程序出错的位置。
注意，如果be.out中出现错误堆栈，通常情况下是因为程序bug，普通用户可能无法自行解决，欢迎前往微信群、github discussion 或dev邮件组寻求帮助，并贴出对应的错误堆栈，以便快速排查问题。
2. dmesg
如果be.out没有堆栈信息，则大概率是因为OOM被系统强制kill掉了。此时可以通过dmesg -T 这个命令查看linux系统日志，如果最后出现 Memory cgroup out of memory: Kill process 7187 (palo_be) score 1007 or sacrifice child 类似的日志，则说明是OOM导致的。
内存问题可能有多方面原因，如大查询、导入、compaction等。Doris也在不断优化内存使用。欢迎前往微信群、github discussion 或dev邮件组寻求帮助。
3. 查看be.INFO中是否有F开头的日志。
F开头的的日志是 Fatal 日志。如 F0916 ，表示9月16号的Fatal日志。Fatal日志通常表示程序断言错误，断言错误会直接导致进程退出（说明程序出现了Bug）。欢迎前往微信群、github discussion 或dev邮件组寻求帮助。
Q：如何通过coredump定位
A：
coredump是linux系统的一个功能，他会将程序的内存镜像写入磁盘生成core文件。之后我们就可以通过分析这个core文件来定位程序内存的问题。非常适合BE进程的debug。
点击链接查看社区 HappenLee 同学的开发笔记。
