如何排查 Apache Doris 中 “Failed to commit txn“ 导入失败问题？

今天来聊聊 Doris 数据导入那些事儿。你是不是在数据导入的时候遇到各种状况，让人头疼不已？别担心，这篇文章给你答案！

在 Doris 的版本里，< 2.0.3 的时候，数据迁移存在一些已知的问题，比如可能会丢数据，还可能触发坏副本。不过，2.0.3 版本之后，大部分丢数据的问题被修复了。但还是有些小状况，像 BE 导入数据失败、BE publish 阶段慢、BE 突然挂掉等问题。

低于2.0.3版本的用户还是优先推荐升级到当前版本的最新小版本

一、副本失败的线索在哪？

当数据导入报错，先看日志中的关键信息：

• 成功的关键数字："xx replicas final succ"，这个数字得大于等于多数派（副本数为 n，多数派就是 [n/2] + 1），导入才算成功哦。

• 写失败的原因："xx replicas write data failed"，这里面学问可大了。可能是 BE 挂了（backendAlive = false 或者 backend = null），也可能是副本被标记为 bad（isBad = true，原因可能是磁盘离线等），还有可能是 BE 写入或者 publish 阶段掉链子了。比如说 mow 表按 version 连续 publish，如果缺前面的 version，就会暂停 publish。

• 版本缺失的情况："xx replicas write data succ but miss previous"，本事务写成功了，但副本前面少了 version，这种情况副本的 last failed version > 0。

要是副本失败了，怎么找原因呢？对每个副本，先找到它首次出问题的事务。如果是 "Failed to commit" 对应的事务，那就简单了；要是 "write data succ but miss previous" 的情况，就得通过一些步骤找到首次失败的事务，比如根据提示中的 version 信息，在其他副本的日志里搜索，找到对应的事务 id。拿到事务 id 后，再去查副本在这个事务上失败的原因，可能是 publish 失败，也可能是其他情况。

二、常见问题及处理方法

1. 多副本问题：有时候多副本情况，1 副本 "replicas final succ"，其他副本 "write data succ but miss previous"。这可能是因为 "publish one succ"，失败的副本可能是 BE publish 慢了，或者当时在 publish 的时候挂了。这种情况，如果不解决，后续新的导入可能会因为失败副本太多而失败。

2. BE 存活但导入失败：如果出现 "xx replicas write data failed"，BE 是存活的，副本也没被标记为 bad，那就可能是导入本身出问题了，得从日志里面具体找导入的问题。在主 FE 上用报错的事务 id 和 beginTransaction 查看，能找到 coordinator BE 的 IP，再去这个 BE 上用事务 id 查看日志，如果导入失败，会有报错信息。

3. 所有副本都缺 rowset：这种情况在不同版本有不同表现。2.1 版本 BE 丢失 rowset 过 3 分钟后，FE 会把 BE 的 last failed version 改成 > 0，但 2.0 版本不一定。判断方法是通过一些命令查看 partition 的 visible version 和 BE 端各个副本的 version，如果所有副本的 compact status 都缺少 partition 的 visible version，那就是 BE 丢数据了。可能是用户回滚操作、backup/restore 操作有问题，或者 BE 配置问题导致的。

副本缺失的问题，可以参考这个文章：Doris查询报错-230？别慌，教你几招秒解！

三、BE publish 慢或堆积问题

如果 FE publish task 任务下发超过 5 分钟，事务还没成功，可能会触发 "publish one succ"，第一个完成的副本会结束事务，其他副本就被标记为失败了。判断 publish 堆积的方法，可以搜索 BE 日志，看看 queue size，如果大于 50，就说明任务堆积了。2.0.5 版本之后日志有变化，也可以通过其他方式判断，比如搜 "publish version successfully on tablet" 或者 "finish to publish version on" 的日志，看 cost 时间来判断 publish 是不是慢了。要是 publish 慢了的话，可以参考下面的解决办法

1. 2.1.2和2.1.3版本有已知的问题，修复pr连接，可以升级到2.1的最新版本解决。
2. 写edit log耗时长导致的Publish 慢，可以在日志里面搜一下

 grep checkAndLogWriteLockDuration fe.log

一般情况下是fe磁盘忙，可能是高频导入导致写很多edit log， 或者跟be混布be写压力大等等所致。如果是高频导入，直接降导入频率就可以了。如果fe是跟其他进程混布，其他进程写磁盘压力大的，则把混布分开（不推荐FE和BE混部）。

3. decommision或者添加索引时发现有事务卡住， 可以通过fe web页面或日志找到卡住事物id，手动abort事务

//abort参考命令
curl -X PUT --location-trusted -u user:passwd  -H "txn_id:18037" -H "txn_operation:abort"  http://fe_host:http_port/api/{db}/{table}/_stream_load_2pc

4. 1.2.7版本commit到visible需要较长时间，各个be的日志搜索：grep PUBLISH be.INFO |grep queue |tail -n 20，如果queue_size比较大，说明Publish卡住，可以通过打一个be的pstack进一步石锤，重启be可解决。修复pr链接，该pr已fix。另外1.2的版本推荐升级！

四、BE 挂掉的麻烦事

如果短时间内来回挂两台以上的 BE，或者先挂一台再重启又挂另一台，就容易出问题。比如 BE A 挂掉重启后，副本缺失 version，如果马上挂掉 BE B，可能会因为可用副本不足导致导入失败。这时候得等 A 上的副本补上 version，或者新增副本成功后，才能恢复正常写入。

这主要是因为在挂掉A之时，A 上的副本是缺失version。 在把A 重启之后，A 上的缺失的副本需要把version都先补上，这些副本才能参与导入成功多数派计数。而如果此时又把另一台B 挂掉，那么B上的副本需要迁移到其他机器上。所以，此时，既需要把A 缺失的version 给补上，另外又需要找另一台BE C clone B上的副本。 如果B上的tablet 很多，或者数据量很大（show backends 查看TabletNum 和 DataCapacity），那么这个修补repair可能就很久。从而在此期间三副本中因两个副本不可用（A上副本缺version， B上的副本则因为B挂了），从而导入都失败。

五、总结

数据导入问题定位起来并不容易，但只要按照这些方法去排查，就能找到问题所在，可以自己先尝试解决
一波。如果搞不定了，可以联系社区的同学帮忙解决，毕竟有Doris社区来兜底！