StarRocks元数据无法合并

news2024/12/29 1:20:57

一、先说结论

如果您的StarRocks版本在3.1.4及以下,并且使用了metadata_journal_skip_bad_journal_ids来跳过某个异常的journal,结果之后就出现了FE的元数据无法进行Checkpoint的现象,那么选择升级版本到3.1.4以上,就可以解决。

二、背景

已经平稳运行了几个月的StarRocks集群突然奔溃,在恢复过程中,发现其元数据从5月16号之后一直没有进行过合并,导致BDB文件非常多,其恢复时间达到了将近2小时。

现象:

  1. 查看FE的meta/image下面的image文件的生成时间,发现为2024.5.16。
  2. 查询FE的meta/bdb目录下的.jdb文件数量的数量到达了8000多个,大小到了81G。
  3. 每次FE恢复元数据重放需要将近2小时小时。

三、排查原因

通过现象已经明确了其没有做Checkpoint操作,导致image文件一直没有更新,那么首先想到两个可能:

一是由于某些原因一直没有触发元数据的CheckPoint操作。

二是进行了CheckPoint的操作,但是由于某些原因,Checkpoint操作一直无法成功。

于是准备在日志中找相关的佐证。于是开始查询查看源码,查看进行Checkpoint操作的类Checkpoint.java(路径:fe/fe-core/src/main/java/com/starrocks/leader/Checkpoint.java),从下面的源码中可以看出,在replayAndGenerateGlobalStateMgrImage方法中,可以看到进行Checkpoint操作时其打印了相关日志,于是在fe的相关日志中查询是否输出了这些日志信息,根据其是否出现,可以判定是否做了Checkpoint操作,并且Checkpoint操作是否成功。

private boolean replayAndGenerateGlobalStateMgrImage(long logVersion) {
    assert belongToGlobalStateMgr;
    long replayedJournalId = -1;
    // generate new image file
    LOG.info("begin to generate new image: image.{}", logVersion);
    globalStateMgr = GlobalStateMgr.getCurrentState();
    globalStateMgr.setJournal(journal);
    try {
        globalStateMgr.loadImage(imageDir);
        globalStateMgr.replayJournal(logVersion);
        globalStateMgr.clearExpiredJobs();
        globalStateMgr.saveImage();
        replayedJournalId = globalStateMgr.getReplayedJournalId();
        if (MetricRepo.hasInit) {
            MetricRepo.COUNTER_IMAGE_WRITE.increase(1L);
        }
        GlobalStateMgr.getServingState().setImageJournalId(logVersion);
        LOG.info("checkpoint finished save image.{}", replayedJournalId);
        return true;
    } catch (Exception e) {
        LOG.error("Exception when generate new image file", e);
        return false;
    } finally {
        // destroy checkpoint globalStateMgr, reclaim memory
        globalStateMgr = null;
        GlobalStateMgr.destroyCheckpoint();
    }
}

因为个人主观觉得Checkpoint失败的可能性比较大,因此开始在fe的warn日志中执行下列语句检索相关的异常,

cat fe.warn.log | grep 'Exception when generate new image file'

可以看到在fe日志中出现了大量的Checkpoint操作失败的相关日志信息。

由以上日志再配合源码,可以发现其触发了Checkpoint操作,但是Checkpoint过程中出现了异常,导致CheckPoint过程失败,也就造成了整个image一直没有更新。继而继续查询日志,找失败的原因,在该日志信息的后面可以看到其报错信息,其信息如下:

基于上面的操作,已经得到了出现Checkpoint失败的原因,也就是得到的journal id和期望值不一致。

记录一个Linux的查询文件命令

由于StarRocks在恢复期间,整个日志文件非常的大,而且刷新很快,通过tail more等看起来非常耗时,因此百度之后发现如下两个命令配合,可以非常的方便定位异常点:

cat -n 文件 | grep ‘异常信息’ 这个命令,可以查询出整个文件中出现异常的行,并且显示行号。

sed -n ‘开始行号,读取行数p’ 文件 这个命令,可以从文件的某一行开始向下读取多少行。

四、解决过程与原理分析

基于上面找到的Checkpoint失败的原因,首先在高于3.1.4版本的各个版本的发布信息中查询,没有发现相关问题修复的bugfix记录。

然后在StarRocks中文论坛中进行相关的检索,虽然有相关的问题,但是都不太一致,其中最相近的一个帖子为:

无法生成image文件,fe重启后元数据还原, 其中提到了通过dump操作进行恢复,但是查询StarRocks相关的文档之后,并没有发现其中有相关操作的描述。
在这里插入图片描述

然后遇事不决翻源码,查看最近和Checkpoint相关的代码不是是否出现了变更,跟踪相关部分的源码发现在GlobalStateMgr.java(fe/fe-core/src/main/java/com/starrocks/server/GlobalStateMgr.java)类中的replayJournalInner方法,最近进行了一次bugfix,查看这次bugfix的问题。

本次bugfix操作的说明如下:

If metadata_journal_skip_bad_journal_ids is configured, and replay of journal failed on EditLog.loadJournal, the cursor will ignore the next journal by mistake, because the bad log data has been read and cursor is already on the next journal. So the next data should only be ignored when failure happens in cursor.next().

可以看到这个异常和使用过 metadata_journal_skip_bad_journal_ids 这个配置有关,回想5月16那天是否对StarRocks进行过相关操作。

5月16号那天StarRocks异常崩溃,在重启恢复过程中,出现了某一个journal无法加载的错误(got interrupt exception or inconsistent exception when replay journal 447554621 wii exit.),导致一直无法恢复,当时通过查询StarRocks中文论坛,找到了一篇如下的帖子:3.1.5 存算分离集群FE 宕机后没法启动, 其中提到了配置 metadata_journal_skip_bad_journal_ids 跳过该journal,当时采用了这个操作,跳过了那个journal,结合目前来看,极大可能就是这个配置导致了FE无法进行Checkpoint.

在来分析本次bugfix到底干了啥,本次bugfix的源码变更地方如下:

可以发现,其就是在获取和或加载某个journal失败的时候,调用了cursor.skipNext(),查看这个具体代表的含义:在其实现类BDBJEJournal.java(fe/fe-core/src/main/java/com/starrocks/journal/bdbje/BDBJEJournal.java)中,其实现如下:

public void skipNext() {
    LOG.error("!!! DANGER: CURSOR SKIP {} !!!", nextKey);
    nextKey++;
}

再看具体报错should replay to 539780547 but actual replayed journal id is 539780546的地方源码,其在

GlobalStateMgr.java(fe/fe-core/src/main/java/com/starrocks/server/GlobalStateMgr.java)中的replayJournal方法中,其实现如下:

public void replayJournal(long toJournalId) throws JournalException {
    if (toJournalId <= replayedJournalId.get()) {
        LOG.info("skip replay journal because {} <= {}", toJournalId, 
                 replayedJournalId.get());
        return;
    }

    long startJournalId = replayedJournalId.get() + 1;
    long replayStartTime = System.currentTimeMillis();
    LOG.info("start to replay journal from {} to {}", startJournalId, toJournalId);

    JournalCursor cursor = null;
    try {
        cursor = journal.read(startJournalId, toJournalId);
        replayJournalInner(cursor, false);
    } catch (InterruptedException | JournalInconsistentException e) {
        LOG.warn("got interrupt exception or inconsistent exception when replay 
                 journal {}, will exit, ",replayedJournalId.get() + 1,e);
        // TODO exit gracefully
        Util.stdoutWithTime(e.getMessage());
        System.exit(-1);

    } finally {
        if (cursor != null) {
            cursor.close();
        }
    }

    // verify if all log is replayed
    if (toJournalId != replayedJournalId.get()) {
        throw new JournalException(String.format(
                "should replay to %d but actual replayed journal id is %d",
                toJournalId, replayedJournalId.get()));
    }

    streamLoadMgr.cancelUnDurableTaskAfterRestart();

    long replayInterval = System.currentTimeMillis() - replayStartTime;
    LOG.info("finish replay from {} to {} in {} msec", startJournalId, toJournalId, 
             replayInterval);
}

从报错新增可以看到,其判断条件是:toJournalId != replayedJournalId.get(), 那么解下来看这两个值是如何得到的。

在Checkpoint.java中可以看到toJournal来自于 journal.getFinalizedJournalId();通过其实现可以看到, 其取的是当前元数据中的最后的一个journalId。

public long getFinalizedJournalId() {
        List<Long> dbNames = bdbEnvironment.getDatabaseNamesWithPrefix(prefix);
        assert (dbNames != null);

        StringBuilder msg = new StringBuilder("database names: ");
        for (long name : dbNames) {
            msg.append(name).append(" ");
        }
        LOG.info(msg.toString());

        if (dbNames.size() < 2) {
            return 0;
        }

        return dbNames.get(dbNames.size() - 1) - 1;
    }

接下来再看整个日志的重放过程,replayedJournalId的初始值,就是image文件的后缀(在fe/fe-core/src/main/java/com/starrocks/persist/Storage.java的reload方法中可以看到),然后其在重放的过程中会不断+1,replayedJournalId更新的逻辑如下:

protected boolean replayJournalInner(JournalCursor cursor, boolean flowControl)
        throws JournalException, InterruptedException, JournalInconsistentException {
    long startReplayId = replayedJournalId.get();
    long startTime = System.currentTimeMillis();
    long lineCnt = 0;
    while (true) {
        JournalEntity entity = null;
        boolean readSucc = false;
        try {
            entity = cursor.next();

            // EOF or aggressive retry
            if (entity == null) {
                break;
            }

            readSucc = true;

            // apply
            EditLog.loadJournal(this, entity);
        } catch (Throwable e) {
            if (canSkipBadReplayedJournal(e)) {
                LOG.error("!!! DANGER: SKIP JOURNAL, id: {}, data: {} !!!",
                        replayedJournalId.incrementAndGet(), 
                          journalEntityToReadableString(entity), e);
                if (!readSucc) {
                    cursor.skipNext();
                }
                continue;
            }
            // handled in outer loop
            LOG.warn("catch exception when replaying journal, id: {}, data: {},",
             replayedJournalId.get() + 1, journalEntityToReadableString(entity), e);
            throw e;
        }

        replayedJournalId.incrementAndGet();
        LOG.debug("journal {} replayed.", replayedJournalId);

        if (feType != FrontendNodeType.LEADER) {
            journalObservable.notifyObservers(replayedJournalId.get());
        }
        if (MetricRepo.hasInit) {
            // Metric repo may not init after this replay thread start
            MetricRepo.COUNTER_EDIT_LOG_READ.increase(1L);
        }

        if (flowControl) {
            // cost too much time
            long cost = System.currentTimeMillis() - startTime;
            if (cost > REPLAYER_MAX_MS_PER_LOOP) {
                LOG.warn("replay journal cost too much time: {} replayedJournalId: {}",
                         cost, replayedJournalId);
                break;
            }
            // consume too much lines
            lineCnt += 1;
            if (lineCnt > REPLAYER_MAX_LOGS_PER_LOOP) {
                LOG.warn("replay too many journals: lineCnt {}, replayedJournalId: {}",
                         lineCnt, replayedJournalId);
                break;
            }
        }

    }
    if (replayedJournalId.get() - startReplayId > 0) {
        LOG.info("replayed journal from {} - {}", startReplayId, replayedJournalId);
        return true;
    }
    return false;
}

分析以上代码:其在while循环中不断读取journal,并且通过replayedJournalId.incrementAndGet()不断刷新其值。

可以发现在修改前后的不同点

  • 修改前:不管的读取还是加载节点异常,其值都加1,而且如果某个失败,并且在 metadata_journal_skip_bad_journal_ids 配置了可以跳过,那么循环会继续,但是游标都会+1.
  • 修改后:加了判断,只有在日志加载中失败,游标才会+1,如果是读取成功,但是加载失败并且又被跳过,则其游标不会+1.

由此,豁然开朗,因为某个journal在EditLog加载过程中失败了,并且这个journal又因为被配置在了metadata_journal_skip_bad_journal_ids中,因此这个错误被被跳过,但是按照修改之前的代码,游标还是+1,跳过了下一个journal,导致replayedJournal的值少自增了一次,导致其值比正常的小了1。

由此,我们就确定了这哥bugfix确实解决了这个问题,因此我们的解决方案就是升级版本。

五、结果

查看该bugfix合并进入3.1相关分支的时间,发现其为2023.11.9,目前出问题的版本为3.1.4,其发布时间为2023.11.2,确定这个bugfix没有被合并进入, 于是选择进行升级,将其升级到了3.2.13.

经过5个小时左右的升级恢复,成功生成了新的image文件,BDB文件也从原先的8000多个讲到了80多个。

六、参考

整个过程中,收集到的一些相关参考资料

  1. metadata_journal_skip_bad_journal_ids:https://forum.mirrorship.cn/t/topic/10178
  2. 无法生成image文件,fe重启后元数据还原: https://forum.mirrorship.cn/t/topic/7774
  3. bugfix:https://github.com/StarRocks/starrocks/pull/33839
  4. 元数据dump相关(来自Doris,StarRocks未查询到):https://cdnd.selectdb.com/zh-CN/docs/admin-manual/maint-monitor/metadata-operation?_highlight=bdb#%E6%9F%A5%E7%9C%8B-bdbje-%E4%B8%AD%E7%9A%84%E6%95%B0%E6%8D%AE
  5. 元数据管理源码分析:https://xie.infoq.cn/article/6f2f9f56916f0eb2fdb6b001a

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2267190.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

图像处理-Ch2-空间域的图像增强

Ch2 空间域的图像增强 文章目录 Ch2 空间域的图像增强Background灰度变换函数(Gray-level Transformation)对数变换(Logarithmic)幂律变换(Power-Law)分段线性变换函数(Piecewise-Linear)对比度拉伸(Contrast-Stretching)灰度级分层(Gray-level Slicing) 直方图处理(Histogram …

c# 2024/12/27 周五

6《详解类型、变量与对象》36 详解类型、变量与对象 _1_哔哩哔哩_bilibili

云手机+Facebook:让科技与娱乐完美结合

移动互联网时代&#xff0c;Facebook作为全球最大的社交媒体平台之一&#xff0c;早已成为企业、品牌和组织竞相角逐的营销阵地。而云手机的出现&#xff0c;则为Facebook营销注入了新的活力&#xff0c;其独特的优势让营销活动更加高效、精准且灵活。本文将深入探讨云手机在Fa…

【蓝桥杯——物联网设计与开发】拓展模块4 - 脉冲模块

目录 一、脉冲模块 &#xff08;1&#xff09;资源介绍 &#x1f505;原理图 &#x1f505;采集原理 &#xff08;2&#xff09;STM32CubeMX 软件配置 &#xff08;3&#xff09;代码编写 &#xff08;4&#xff09;实验现象 二、脉冲模块接口函数封装 三、踩坑日记 &a…

【再谈设计模式】享元模式~对象共享的优化妙手

一、引言 在软件开发过程中&#xff0c;我们常常面临着创建大量细粒度对象的情况&#xff0c;这可能会导致内存占用过高、性能下降等问题。享元模式&#xff08;Flyweight Pattern&#xff09;就像是一位空间管理大师&#xff0c;它能够在不影响功能的前提下&#xff0c;有效地…

Unity 读Excel,读取xlsx文件解决方案

Unity读取表格数据 效果&#xff1a; 思路&#xff1a; Unity可以解析Json&#xff0c;但是读取Excel需要插件的帮助&#xff0c;那就把这个功能分离开&#xff0c;读表插件就只管读表转Json&#xff0c;Unity就只管Json解析&#xff0c;中间需要一个存储空间&#xff0c;使用…

WebRTC服务质量(11)- Pacer机制(03) IntervalBudget

WebRTC服务质量&#xff08;01&#xff09;- Qos概述 WebRTC服务质量&#xff08;02&#xff09;- RTP协议 WebRTC服务质量&#xff08;03&#xff09;- RTCP协议 WebRTC服务质量&#xff08;04&#xff09;- 重传机制&#xff08;01) RTX NACK概述 WebRTC服务质量&#xff08;…

STM32完全学习——FATFS0.15移植SD卡

一、下载FATFS源码 大家都知道使用CubMAX可以很快的将&#xff0c;FATFS文件管理系统移植到单片机上&#xff0c;但是别的芯片没有这么好用的工具&#xff0c;就需要自己从官网下载源码进行移植。我们首先解决SD卡的驱动问题&#xff0c;然后再移植FATFS文件管理系统。 二、SD…

Ollama+OpenWebUI+llama3本地部署

引言 llama3在4月19日刚刚发布&#xff0c;官方的对比结果中在开源模型中堪称世界第一&#xff0c;整好周六日有时间&#xff0c;在魔搭社区上测试一下 2 安装Ollama 2.1 下载Ollama 登录Ollama官网下载Ollama安装包 GitHub&#xff1a;https://github.com/ollama/ollama?t…

新品:SA628F39大功率全双工音频传输模块

SA628F39是一款高集成度的8W大功率全双工无线数据语音一体通话模块&#xff0c;专为高效、稳定的远程通信设计。该模块内置高速微控制器、高性能射频芯片、功率放大器、ESD静电保护和硬件看门狗芯片&#xff0c;具备反接保护、过流过压保护和防死机保护等多重安全功能&#xff…

Unity EasyAR入门教程

文章目录 Easy不用下载盗版安装SDK注册应用ID最简单的识别注意点 Easy不用下载盗版 EasyAR可以免费试用&#xff0c;如果不在乎水印&#xff0c;直接去官网下载即可 EasyAR官网 安装SDK 先下载&#xff0c;官网找到下载页&#xff0c;如下选择 下载后不是普通的unityPackag…

ID卡网络读卡器Python小程序开发

UDP网络读卡器Python示例代码。 主页UI设计界面&#xff1a; UI代码&#xff1a; from PyQt5 import QtCore, QtGui, QtWidgetsclass Ui_Frame(object):def setupUi(self, Frame):Frame.setObjectName("Frame")Frame.resize(1082, 685)font QtGui.QFont()font.set…

yarn list --pattern vuex-module-decorators

dgqdgqdeMac-mini spid-admin % yarn list --pattern vuex-module-decorators yarn list v1.22.22 └─ vuex-module-decorators0.16.1 ✨ Done in 0.24s.好的&#xff0c;这段代码是一个典型的 Vuex 模块定义&#xff0c;使用了 vuex-module-decorators 库。这个库为 Vuex 提…

微机接口课设——基于Proteus和8086的打地鼠设计(8255、8253、8259)Proteus中Unknown 1-byte opcode / Unknown 2-byte opcode错误

原理图设计 汇编代码 ; I/O 端口地址定义 IOY0 EQU 0600H IOY1 EQU 0640H IOY2 EQU 0680HMY8255_A EQU IOY000H*2 ; 8255 A 口端口地址 MY8255_B EQU IOY001H*2 ; 8255 B 口端口地址 MY8255_C EQU IOY002H*2 ; 8255 C 口端口地址 MY8255_MODE EQU IOY003H*2 ; …

【HENU】河南大学计院2024 计算机网络 期末复习知识点

和光同尘_我的个人主页 一直游到海水变蓝。 计网复习 第一章互联网组成类别交换方式分组交换的要点&#xff1a;分组交换的优点&#xff1a; 网络性能指标体系结构网络协议五层协议 第二章&#xff1a;物理层物理层的主要任务&#xff08;四大特性&#xff09;通信的三种方式…

chatwoot 开源客服系统搭建

1. 准备开源客服系统&#xff08;我是用的Chatwoot &#xff09; 可以选择以下开源客服系统作为基础&#xff1a; Chatwoot: 功能强大&#xff0c;支持多渠道客户对接&#xff0c;&#xff08;支持app&#xff0c;web&#xff09;。Zammad: 现代的开源工单系统。FreeScout: 免…

python爬虫----爬取视频实战

python爬虫-爬取视频 本次爬取&#xff0c;还是运用的是requests方法 首先进入此网站中&#xff0c;选取你想要爬取的视频&#xff0c;进入视频页面&#xff0c;按F12&#xff0c;将网络中的名称栏向上拉找到第一个并点击&#xff0c;可以在标头中&#xff0c;找到后续我们想要…

【PPTist】表格功能

前言&#xff1a;这篇文章来探讨一下表格功能是怎么实现的吧&#xff01; 一、插入表格 我们可以看到&#xff0c;鼠标移动到菜单项上出现的提示语是“插入表格” 那么就全局搜索一下&#xff0c;就发现这个菜单在 src/views/Editor/CanvasTool/index.vue 文件中 <Popov…

Web安全攻防入门教程——hvv行动详解

Web安全攻防入门教程 Web安全攻防是指在Web应用程序的开发、部署和运行过程中&#xff0c;保护Web应用免受攻击和恶意行为的技术与策略。这个领域不仅涉及防御措施的实现&#xff0c;还包括通过渗透测试、漏洞挖掘和模拟攻击来识别潜在的安全问题。 本教程将带你入门Web安全攻防…

游戏开发线性空间下PS工作流程

前言 使用基于物理的渲染&#xff0c;为了保证光照计算的准确&#xff0c;需要使用线性空间&#xff1b; 使用线性空间会带来一个问题&#xff0c;ui 在游戏引擎中的渲染结果与 PS 中的不一致&#xff1a; PS&#xff08;颜色空间默认是sRGB伽马空间&#xff09;&#xff1a…