StarRocks 的元数据管理如何才能达到深入理解？

我们先从一个让人头大的日志说起。你有没有在排查线上问题的时候，看到一堆莫名其妙的日志，然后怀疑人生？

换句话说... 比如 最近我在排查 StarRocks 线上一个告警日志时就遇到了一个特别“亲切”的场景：每隔一段时间，日志里就会蹦出一条“base-table 被删除了”的提示。但其实表根本没被删，也没人动过这让人怎么想都觉得是程序的锅。于是我决定深入源码，看看这到底是啥情况。

害... 我们先来回顾一下问题的来龙去脉。这个问题的起因，其实是一个隐藏的 bug，导致了日志打印出“基表被删除”的信息，但其实表还在。这其实不是用户操作导致的，而是一个在加载过程中，视图的基表还没加载到内存，就被查询了导致了误报。

元数据管理的“坑”

StarRocks 的元数据管理，其实是一个非常复杂的系统。它不像你想象的那样简单，比如“数据库被删了”这种日志，可能只是个假象。我们来看一下它到底怎么工作的，一言难尽。。

StarRocks 的元数据管理机制，主要依赖于 editLog 和 image 两个核心机制。每一次操作都会生成 editLog，然后定期生成 image 文件，用于快速恢复元数据。

这些 editLog 会记录在 fe/meta 目录中， 而 image 文件则会定期生成， 说白了就是... 用于快速恢复数据库状态。这个机制听起来很美好，但实际操作中，问题就来了。

比如 我们遇到的这个“base-table 被删除”的日志，其实是主要原因是在加载物化视图时基表还没加载到内存，导致查询不到基表，于是就报错了。这其实不是数据真的被删了而是加载顺序的问题，这是可以说的吗？。

深入源码：问题出在哪？

我们来看一下这个流程图：

在 StarRocks 的加载流程中， loadImage 会读取 image 文件，然后反序列化后加载到内存中。 我给跪了。 这个过程主要是恢复数据库和表。