背景前段时间我在实现 StarRocks 的一个关于资源限制的特性，由于该功能需要基于最新的 3.5 tag 进行开发，所以我需要需要从 3.5 的 tag 里拉出一个分支（3.5-feature）开发完成后再向上游的 main 分支提交 PR。

背景 前段时间有朋友问我关于 spring cloud 的应用在调用到 Go 的 API 之后出现 Trace 没有串联起来的问题。 完整的调用流程如下： 123456789101112131415┌──────┐ │Client│ └┬─────┘ ┌▽──────────────────┐│SpringCloud Gate

之前写过一篇 StarRocks 开发环境搭建踩坑指北之存算分离篇讲解如何在本地搭建一个可以 debug 的存算分离版本。 但最近在本地调试一个场景，需要 CN 节点是以集群的方式启动，我还是按照老方法通过 docker 启动 CN，然后 export 端口的方式让 FE 进行绑定。 比如用以下两个命令可以启动两个 CN 节点。 1docker run -p 9060:9060 -p 8040:8

最近在为 StarRocks 的物化视图增加多表达式支持的能力，于是便把物化视图（MV）的创建刷新流程完成的捋了一遍。 之前也写过一篇：StarRocks 物化视图刷新流程和原理，主要分析了刷新的流程，以及刷新的条件。 这次从头开始，从 MV 的创建开始来看看 StarRocks 是如何管理物化视图的。 创建物化视图1234567891011CREATEMATERIALIZED VIEW mv_t

原文链接：[ On | No ] syntactic support for error handling 关于 Go 语言最有争论的就是错误处理： 1234x, err := call()if err != nil { // handle err} if err != nil 类似于这样的代码非常多，淹没了其余真正有用的代码。这通常发生在进行大量API

背景Code Review 是大家日常开发过程中很常见的流程，当然也不排除一些团队为了快速上线，只要功能测试没问题就直接省去了 Code Review。 我个人觉得再忙的团队 Code Review 还是很有必要的（甚至可以事后再 Review），好处很多： 跳出个人开发的思维误区，更容易发现问题 增进团队交流，提高整体的技术氛围 团队水平检测器，不管是审核者还是被审核的，review 几次后

最近我们在使用 StarRocks 的时候碰到了一些小问题： 重启物化视图的时候会导致视图全量刷新，大量消耗资源。 - 修复 PR：https://github.com/StarRocks/starrocks/pull/57371 excluded_refresh_tables 参数与 MV 不在一个数据库的时候，无法生效。 修复 PR：https://github.com/StarRocks

前段时间申请成为了 OpenTelemetry 的 Member 通过了，算是完成了一个阶段性目标；从 24 年的 2 月份的第一个 issue 到现在刚好一年的时间。

前段时间升级了生产环境的 StarRocks，从 3.3.3 升级到了 3.3.9，期间还是踩了不少坑所以在这里记录下。 因为我们的集群使用的是存算分离的版本，也是使用官方提供的 operator 部署在 kubernetes 里的，所以没法按照官方的流程进入虚拟机手动启停对应的服务。 只能使用 operator 提供的方案手动修改对应组件的镜像版本，后续的升级操作交给 operator 去完

这些年我一直都是按照农历新年来写年终总结的，都说不出正月都是年，前些年一直都比较规律，今年确实是时间超了一些。 主要原因还是年末接了个活，需要在年初上线，导致这段时间都没太多时间写内容。 最近事情终于告一段落后才开始码字。