StarRocks元数据无法归并

一、先说结论

如果您的StarRocks版本在3.1.4及以下，而且使用了metadata_journal_skip_bad_journal_ids来跳过某个非常的journal，结果之后就出现了FE的元数据无法举行Checkpoint的征象，那么选择升级版本到3.1.4以上，就可以办理。
二、配景

已经安稳运行了几个月的StarRocks集群忽然奔溃，在规复过程中，发现其元数据从5月16号之后不停没有举行过归并，导致BDB文件非常多，其规复时间到达了将近2小时。
征象：

  

• 查察FE的meta/image下面的image文件的天生时间，发现为2024.5.16。  
  
• 查询FE的meta/bdb目次下的.jdb文件数量的数量到达了8000多个，巨细到了81G。  
  
• 每次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操纵是否乐成。

1. private boolean replayAndGenerateGlobalStateMgrImage(long logVersion) {
2.    
3.    
4.     assert belongToGlobalStateMgr;
5.     long replayedJournalId = -1;
6.     // generate new image file
7.     LOG.info("begin to generate new image: image.{}", logVersion);
8.     globalStateMgr = GlobalStateMgr.getCurrentState();
9.     globalStateMgr.setJournal(journal);
10.     try {
11.    
12.    
13.         globalStateMgr.loadImage(imageDir);
14.         globalStateMgr.replayJournal(logVersion);
15.         globalStateMgr.clearExpiredJobs();
16.         globalStateMgr.saveImage();
17.         replayedJournalId = globalStateMgr.getReplayedJournalId();
18.         if (MetricRepo.hasInit) {
19.    
20.    
21.             MetricRepo.COUNTER_IMAGE_WRITE.increase(1L);
22.         }
23.         GlobalStateMgr.getServingState().setImageJournalId(logVersion);
24.         LOG.info("checkpoint finished save image.{}", replayedJournalId);
25.         return true;
26.     } catch (Exception e) {
27.    
28.    
29.         LOG.error("Exception when generate new image file", e);
30.         return false;
31.     } finally {
32.    
33.    
34.         // destroy checkpoint globalStateMgr, reclaim memory
35.         globalStateMgr = null;
36.         GlobalStateMgr.destroyCheckpoint();
37.     }
38. }

复制代码

由于个人主观以为Checkpoint失败的大概性比力大，因此开始在fe的warn日记中实验下列语句检索干系的非常，

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

复制代码

可以看到在fe日记中出现了大量的Checkpoint操纵失败的干系日记信息。

由以上日记再共同源码，可以发现其触发了Checkpoint操纵，但是Checkpoint过程中出现了非常，导致CheckPoint过程失败，也就造成了整个image不停没有更新。继而继续查询日记，找失败的缘故原由，在该日记信息的背面可以看到其报错信息，其信息如下：

基于上面的操纵，已经得