搭建网站 优帮云,搜索引擎优化简称seo,有没有做市场评估的网站,青岛模板做网站今天来聊聊 Doris 数据导入那些事儿。你是不是在数据导入的时候遇到各种状况#xff0c;让人头疼不已#xff1f;别担心#xff0c;这篇文章给你答案#xff01;
在 Doris 的版本里#xff0c; 2.0.3 的时候#xff0c;数据迁移存在一些已知的问题#xff0c;比如可…
今天来聊聊 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也可能是副本被标记为 badisBad 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 failedBE 是存活的副本也没被标记为 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_2pc1.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社区来兜底
