今天来聊聊 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 副本
"replicas final succ"，其他副本"write data succ but miss previous"。这可能是因为"publish one succ"，失败的副本可能是 BE publish 慢了，或者当时在 publish 的时候挂了。这种情况，如果不解决，后续新的导入可能会因为失败副本太多而失败。 -
BE 存活但导入失败 ：如果出现
"xx replicas write data failed"，BE 是存活的，副本也没被标记为 bad，那就可能是导入本身出问题了，得从日志里面具体找导入的问题。在主 FE 上用报错的事务 id 和beginTransaction查看，能找到 coordinator BE 的 IP，再去这个 BE 上用事务 id 查看日志，如果导入失败，会有报错信息。 -
所有副本都缺 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 慢了的话，可以参考下面的解决办法
-
2.1.2和2.1.3版本有已知的问题，修复pr连接，可以升级到2.1的最新版本解决。
-
写edit log耗时长导致的Publish 慢，可以在日志里面搜一下
grep checkAndLogWriteLockDuration fe.log
一般情况下是fe磁盘忙，可能是高频导入导致写很多edit log， 或者跟be混布be写压力大等等所致。如果是高频导入，直接降导入频率就可以了。如果fe是跟其他进程混布，其他进程写磁盘压力大的，则把混布分开（不推荐FE和BE混部）。
-
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 -
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社区来兜底！