很多人一听到“数据库源码解析”第一反应是“这是大佬才能干的事”。但我想说如果你真的把 openGauss 源码拉下来翻过几页就会发现它并没有想象中那么玄乎。openGauss 是一个开源的集中式关系型数据库起步于 PostgreSQL 9.2.4但后续做了大量自研改造形成了一个在架构、存储、事务、高可用等方面都有独立演进的数据库内核。这个系列文章就是想把 openGauss 这套源码掰开揉碎讲清楚从整体架构到关键模块从代码路径到动手实践一步步带大家把“数据库剖开看”。作为系列的第一篇我不会急着贴大段代码也不会一上来就带着你钻进某个函数。这一篇先把 openGauss 的家底讲明白它是什么、为什么值得读、代码长什么样、从哪里下手最顺。把这些问题解决了后续文章里那些 parser、optimizer、executor、WAL、Ustore 之类的“硬骨头”才有地方安放。适合谁来读正在学数据库内核的学生、看过 PostgreSQL 代码但想了解 openGauss 差异的工程师、以及准备基于 openGauss 做二次开发或者选型评估的人。如果你只是日常 CRUD 用户这篇内容也能帮你建立对数据库底层运行的整体认知。1. openGauss 是什么为什么值得读源码1.1 从 PostgreSQL 9.2.4 到 openGauss一段不断演进的代码史openGauss 的根确实是 PostgreSQL 9.2.4。但如果你抱着“这不就是一个 PG 换皮版”的心态去读代码很快就会被现实教育。openGauss 在 PG 基础上几乎重写了存储、事务、执行器、资源管理等核心模块新增了 Ustore、MOT 内存表、CSN 等一整套自研机制。代码量和复杂度早就超越了 9.2.4 时代的那套体系。它的开源时间点是 2020 年 6 月采用木兰宽松许可证 v2之后社区基本按半年到一年的节奏发布版本。早期的 1.0、1.1 版本还比较克制到了 2.0、3.0 之后开始逐步引入资源池化、可观测性、AI4DB 等方向。最近几个大的版本比如 5.0.0、6.0.0已经把资源池化、共享存储、多写多读一类的企业级能力进一步推进。从源码演进的角度看这个项目的脉络其实非常清晰PG 时代的老代码负责提供一个能被大家理解的底座openGauss 的自研模块不断在这个底座上“生长”。所以你读源码的过程中经常会有一种奇妙的感觉——同一个系统里既有 PostgreSQL 那种“稳如老狗”的经典实现又有大量完全打破传统思路的新设计。这种“新老同堂”的状态正是 openGauss 源码最有意思的地方。1.2 openGauss 到底解决了什么问题讲技术之前得先搞清楚这套数据库的价值定位。openGauss 的核心场景是企业级关键任务负载说直白点就是那种“挂了会出大事”的业务系统比如银行的账务、电力的计量、制造企业的订单中心。这类场景对强一致、高可用、数据不丢失的要求远高于互联网常见的“海量并发 最终一致”玩法。所以在源码层面你会看到 openGauss 花大量精力在 WAL 日志、恢复流程、同步复制、事务一致性上。比如它把传统 PG 的 MVCC 快照机制改成了 CSN 逻辑时钟解决了事务号耗尽和备机扩展能力不足的问题再比如它在行存之外搞出了 Ustore 原地更新引擎专门针对索引膨胀和长事务场景。这些特性的背后都是明确的企业级诉求。理解了这个定位你再看源码时就会少很多困惑。为什么 openGauss 要加线程池为了在几千个并发连接下还能压住性能。为什么要做 NUMA 感知调度因为企业级服务器普遍是多路 CPU内存访问延迟差异不能视而不见。为什么要做全密态因为合规要求数据在数据库内部也不能裸奔。这些问题串起来就是 openGauss 的完整画像。1.3 什么样的人适合啃这套代码我的经验是读 openGauss 源码不需要你天赋异禀但需要三个基础C 语言能看懂指针和结构体、对操作系统进程线程和内存有基本概念、愿意把一个 SQL 从输入到输出的完整链路走一遍。有 PostgreSQL 背景的人上手会快很多毕竟大量术语和代码风格是相通的。但反过来如果你完全没看过 PG直接读 openGauss 也完全可以只是会多花点时间适应。整体来说这套源码的入口比很多人想象中友好——至少它有完整的中文文档、活跃的社区和大量公开的架构设计说明比很多所谓“经典但无人维护”的数据库代码好读得多。2. 技术全景俯瞰openGauss 架构与核心模块2.1 从 SQL 到硬盘一条完整的数据链路在 openGauss 里一条 SQL 语句从客户端发出到最终把数据写到磁盘至少要经过五个逻辑模块接入层、SQL 引擎、执行引擎、存储引擎、日志与恢复。接入层负责处理客户端连接网络通信和会话管理在这里完成。SQL 引擎做的事情是词法分析、语法分析、语义分析、查询重写和查询优化。执行引擎拿到优化器产生的执行计划后真正去扫描表、做连接、聚合、排序。存储引擎管的是数据页、索引、缓冲区、事务可见性这些东西。日志与恢复则负责保证任何时刻数据库崩溃了都能按照 WAL 日志回到一致状态。这套分层是所有关系型数据库的通用框架openGauss 也不例外。读源码的时候你最好先在心里画清楚这条链路再具体到某个模块。否则随便抓一个函数开读很容易迷失在代码海洋里。2.2 进程模型它不是“一个数据库程序”而是一个进程家族openGauss 沿用了 PostgreSQL 的“多进程 共享内存”模型。启动数据库后你会看到一堆 gaussdb 进程其中最核心的是 postmaster 主进程它是整个数据库的守护者。客户端连接进来后postmaster 会 fork 出一个 postgres backend 进程专门服务这个会话。后台还有一堆工作者进程比如 WALwriter 负责写日志、BgWriter 负责异步回写脏页、PageWriter 负责预分配页、CheckPointer 负责检查点、SysLogger 负责日志输出。为什么 openGauss 不用多线程多进程的好处是隔离性好一个后端进程崩了不会拖垮整个数据库这符合企业级系统对稳定性的执念。但多进程也有代价——连接数上去之后进程切换和内存占用都很大。所以 openGauss 后续又搞了线程池把高频的 backend 工作转成线程池里的任务本质上是对多进程模型的一种补偿。看代码的时候建议你先确认一个函数到底跑在哪个进程或线程里。因为数据库里到处都是共享内存和全局状态你搞不清执行上下文就很容易误解变量的作用范围。2.3 CSN、存储引擎与 WAL读源码前必须认识的几个关键词CSNCommit Sequence Number是 openGauss 对 PostgreSQL 事务系统最重要的改造之一。传统 PG 用事务 ID 做快照比较openGauss 改成用一个全局递增的提交序号作为事务提交顺序标记。这样做的好处是事务号不会快速回卷备机也可以基于 CSN 构建更高效的快照。你在源码里会频繁看到 csn 相关结构体强烈建议先把这个概念吃透再看事务模块。存储引擎方面openGauss 现在是“多引擎共存”的状态。ASTORE 是对 PG 行存风格的延续追加更新旧版本保留在原页面里。Ustore 是自研的原地更新引擎更新时直接改原数据把旧版本链写到独立的 Undo 段里能显著减少索引膨胀。MOT 是内存优化表整张表活在内存里走的是完全不同的无锁乐观并发路线。再加上列存表和向量化执行openGauss 的存储层远比表面看起来复杂。WAL 就更不用说了任何数据库崩溃恢复的底气都来自日志。openGauss 在 WAL 方面做了并行日志、日志压缩、共享日志等大量优化。读存储和事务相关代码时随时准备好和 WAL 打交道。2.4 高可用与形态扩展从主备复制到资源池化openGauss 的高可用基础是主备流式复制主库把 WAL 日志实时发送给备库备库回放日志保持数据同步。支持同步、异步、quorum 等多种模式。再往上走社区还引入了 DCF 组件可以让多副本之间通过一致性协议自动选主。资源池化形态则更进一步把计算和存储分离多台计算节点共享一份存储配合 DMS 做缓存一致性。这些高级能力在源码里都有对应的模块比如 replication、dcf、dms 等目录。我的建议是初读阶段不要一头扎进这些分布式相关模块先把单机内核主链路读顺。等高可用、资源池化相关的文章更新到后面再跟着系列文章逐个深入也不迟。3. 动手之前源码下载、编译和实例启动3.1 源码获取与版本选择openGauss 的代码托管在 Gitee 官方仓库地址是 gitee.com/opengauss/openGauss。clone 命令很简单git clone https://gitee.com/opengauss/openGauss.git但我不建议你直接拉 master 分支就开始读。master 是开发分支今天看到的函数签名可能过俩月就变了。更稳的做法是先确定一个发布版本比如基于 5.0.0 或者 6.0.0 的 tag 建立本地分支git clone -b V500R001C00 https://gitee.com/opengauss/openGauss.git选择版本时要考虑两个因素一是你手上的学习资料比如社区博客、官方文档对应的版本二是你机器上操作系统和工具链的兼容性。系列文章后续默认以当前最新的稳定发布版本作为基线你尽量对齐否则有些代码位置对不上会很伤。3.2 编译环境准备依赖、磁盘和内存openGauss 的编译依赖不算特别苛刻但确实需要提前装齐。常见的依赖包括 gcc、g、make、flex、bison、readline-devel、zlib-devel、libaio-devel、ncurses-devel、openssl-devel 和 python3。系统推荐 openEuler、CentOS、Ubuntu 这类主流 Linux 发行版x86 和 ARM 架构都能编译。内存建议至少 8GB磁盘剩余空间建议保持在 50GB 以上。openGauss 的编译过程非常吃资源尤其是多进程并行编译时很容易把内存打满。磁盘方面除了源码本身编译产物和安装包都会占不少空间。编译方式上openGauss 提供了 build.sh 一键脚本。你先确认依赖库路径然后执行sh build.sh -m release -t make -3rd /path/to/binarylibs这里的 binarylibs 是预编译的三方库压缩包如果你的环境里没有需要先从社区下载对应版本的 binarylibs或者让脚本自动下载。我建了一个普通用户来做编译避免 root 账户带来的路径和权限问题这一条很多人容易忽略。3.3 初始化实例从编译成功到跑起来编译完成后安装目录下会生成 bin、lib、share 等子目录。接下来需要配置环境变量export GAUSSHOME/opt/opengauss export LD_LIBRARY_PATH$GAUSSHOME/lib:$LD_LIBRARY_PATH export PATH$GAUSSHOME/bin:$PATH然后初始化数据目录。openGauss 的 gs_initdb 跟 PG 的 initdb 类似但必须指定 node 名称gs_initdb -D /data/ogdata --nodenameprimary初始化完成后启动数据库gs_ctl start -D /data/ogdata最后用 gsql 连接测试gsql -d postgres -p 5432能正常连接上说明你的 openGauss 环境已经可以开工了。后续所有源码实验都会在这个环境上进行。4. 源码目录地图在 openGauss 里找代码的正确姿势4.1 顶层目录与 PostgreSQL 的差异我第一次打开 openGauss 源码目录时第一反应是“这目录结构怎么跟 PG 不太一样”。顶层会有 src、contrib、build 等目录但 src 下面多了一个非常显眼的子目录 gausskernel。这个目录是整个 openGauss 自研代码的核心容器。如果你带着 PostgreSQL 的经验进来需要习惯一个事实PG 原本集中在 src/backend 下的很多模块在 openGauss 里被重新组织到了 src/gausskernel 下。比如优化器、执行器、存储引擎的主要代码都能在 gausskernel 里找到对应目录。而 src/backend 下仍然保留着大量基础实现比如 postmaster、libpq、部分存储和日志代码。所以不能简单说“src/backend 是老代码gausskernel 是新代码”它们之间更像是“基础公共代码”和“深度改造/自研代码”的协作关系。4.2 src/gausskernel自研核心从这里看起我整理了一份 openGauss 关键目录速查表方便你快速定位功能位置目录主要功能src/gausskernel/storage存储引擎、缓冲区、WAL、CSN 日志src/gausskernel/optimizer查询优化器src/gausskernel/executor执行器含向量化执行src/gausskernel/parser语法与词法分析src/gausskernel/rewrite查询重写src/gausskernel/catalog系统表管理src/gausskernel/postmaster进程与线程管理src/gausskernel/tcop顶层命令处理入口src/gausskernel/nodes节点结构体定义src/gausskernel/utils内存、缓存、时间等通用工具src/gausskernel/replication主备复制src/gausskernel/dcf一致性协议组件src/gausskernel/dms资源池化相关表格只是定位用的“路标”不要把它当成严格的物理划分。实际代码里模块之间会有大量跨目录调用这是正常的。4.3 自研特性在代码中的落点如果你对某个具体特性感兴趣可以按下面的索引直接找切入点特性建议起点Ustore 存储引擎src/gausskernel/storage/access/ustoreMOT 内存表src/gausskernel/storage/motCSN 事务快照src/gausskernel/storage/access/csnlog列存与向量化src/gausskernel/executor/vec 及 cstore 相关目录线程池src/gausskernel/threadpoolWAL 并行回放src/gausskernel/storage/access/parallel_recovery这些目录在 5.0.0 左右的代码里基本都能找到。不同版本之间文件名可能略有差异但大体路径是稳定的。阅读时如果找不到多用 grep 搜关键词比照着目录树硬翻高效得多。4.4 检索代码的几个实用技巧读这种规模的源码单纯靠人肉翻肯定不行。我日常用的组合是 ripgrep ctags VSCode。ripgrep 负责全局搜函数名、宏、报错信息ctags 负责跳转定义VSCode 负责整体阅读体验。尤其是报错日志定位很多时候 SQL 执行报错会打印函数名和行号直接拿这个去源码里搜比从 main 函数开始追快十倍。5. 如何开始阅读源码一种可行的学习路线5.1 路线一按 SQL 执行链路走一遍这是最适合新手的入门路径。选定一条最简单的 SQL比如SELECT 1或者SELECT * FROM t WHERE id 1然后用调试器从客户端连接开始到解析、重写、优化、执行一步步跟下去。核心入口在 tcop 目录下的标准查询处理流程你会看到exec_simple_query、pg_parse_query、pg_analyze_and_rewrite、pg_plan_query、PortalRun这一系列函数。第一次走通这条链路你对数据库内核的认知会从一个模糊的整体变成一张清晰的地图。之后再看任何模块都会知道自己处于链路的哪个位置。5.2 路线二从存储和日志切入如果你对崩溃恢复、页结构、事务可见性更感兴趣可以从存储引擎和 WAL 入手。先搞懂数据在磁盘上长什么样再理解日志是怎么按顺序写的最后看恢复流程怎么把数据库拉回一致状态。这条路线适合想深入研究数据库可靠性的读者难度稍高但收获也大。5.3 路线三以新特性为突破口openGauss 的很多设计在传统 PG 里是看不到的比如 Ustore 的 undo 链、MOT 的无锁结构、CSN 的可见性判断。你可以选择一个自己最有好奇心的特性从社区的设计文档读到代码实现。这种“特性驱动阅读”的好处是目标明确不用面对全量代码的压迫感。5.4 调试工具辅助用 gdb 让代码“动起来”静态读代码容易卡住最好的办法是让代码跑起来在关键函数上打断点看变量变化。比如几个核心函数直接用 gdb 启动 gaussdb设置断点然后从另一个终端发起 SQL。你会亲眼看到一条 SQL 是如何一步一步变成执行计划的。日志参数也要学会用log_min_messages、debug_print_plan这类开关能帮你把内部状态打到日志里排查问题非常方便。6. 读源码过程中最容易踩的坑6.1 编译阶段常见问题速查现象可能原因处理方式gcc 版本报错系统 gcc 过旧升级 gcc 或切换更高版本工具链flex/bison 找不到未安装或版本不匹配安装 flex、bison检查 PATH编译中途 OOM内存不足增加内存或 swap减少并行编译参数三方库缺失binarylibs 没指定或下载失败下载对应版本 binarylibs配置 -3rdroot 编译报错权限和路径问题换普通用户目录属主改对6.2 启动与连接阶段常见问题现象可能原因处理方式gs_initdb 失败磁盘空间、目录权限、nodename 非法检查磁盘确认目录属主命名符合规范端口被占用默认 5432 被其他程序占用修改 postgresql.conf 的 portgsql 连接失败监听地址或 pg_hba.conf 配置不对放开 listen_addresses检查认证规则日志找不到日志目录不确定查看数据目录下的 pg_log6.3 阅读与理解阶段的认识误区最大的误区是总想着从头读到尾。openGauss 源码少说几百万行线性阅读根本不现实。正确做法是带着问题读这个模块解决什么问题它对数据结构和核心流程的改动在哪里和 PG 原版相比差异在哪第二个误区是忽视版本差异。你搜到的博客可能是 3.0 时代的代码已经更新到 6.0函数名、目录都可能变了。看任何文章前先确认版本否则会浪费时间在“找旧函数”上。第三个误区是不看日志只看代码。很多时候代码逻辑和实际运行结果之间隔着海量细节直接用日志和调试器验证比空想要有效得多。我个人在实际操作中还有一个很深的体会不要一开始就啃最复杂的部分比如 DCF、资源池化这类很容易劝退。先把单机主流程吃透再往分布式和高可用方向扩展节奏会舒服很多。这个系列后续也会按照这个思路来排下一篇会从 openGauss 的进程启动和 gs_ctl start 流程入手带大家真正把代码跑起来从第一个 fork 出来的进程开始认识这个系统。
openGauss源码解析：从架构到实践，带你读懂数据库内核
很多人一听到“数据库源码解析”第一反应是“这是大佬才能干的事”。但我想说如果你真的把 openGauss 源码拉下来翻过几页就会发现它并没有想象中那么玄乎。openGauss 是一个开源的集中式关系型数据库起步于 PostgreSQL 9.2.4但后续做了大量自研改造形成了一个在架构、存储、事务、高可用等方面都有独立演进的数据库内核。这个系列文章就是想把 openGauss 这套源码掰开揉碎讲清楚从整体架构到关键模块从代码路径到动手实践一步步带大家把“数据库剖开看”。作为系列的第一篇我不会急着贴大段代码也不会一上来就带着你钻进某个函数。这一篇先把 openGauss 的家底讲明白它是什么、为什么值得读、代码长什么样、从哪里下手最顺。把这些问题解决了后续文章里那些 parser、optimizer、executor、WAL、Ustore 之类的“硬骨头”才有地方安放。适合谁来读正在学数据库内核的学生、看过 PostgreSQL 代码但想了解 openGauss 差异的工程师、以及准备基于 openGauss 做二次开发或者选型评估的人。如果你只是日常 CRUD 用户这篇内容也能帮你建立对数据库底层运行的整体认知。1. openGauss 是什么为什么值得读源码1.1 从 PostgreSQL 9.2.4 到 openGauss一段不断演进的代码史openGauss 的根确实是 PostgreSQL 9.2.4。但如果你抱着“这不就是一个 PG 换皮版”的心态去读代码很快就会被现实教育。openGauss 在 PG 基础上几乎重写了存储、事务、执行器、资源管理等核心模块新增了 Ustore、MOT 内存表、CSN 等一整套自研机制。代码量和复杂度早就超越了 9.2.4 时代的那套体系。它的开源时间点是 2020 年 6 月采用木兰宽松许可证 v2之后社区基本按半年到一年的节奏发布版本。早期的 1.0、1.1 版本还比较克制到了 2.0、3.0 之后开始逐步引入资源池化、可观测性、AI4DB 等方向。最近几个大的版本比如 5.0.0、6.0.0已经把资源池化、共享存储、多写多读一类的企业级能力进一步推进。从源码演进的角度看这个项目的脉络其实非常清晰PG 时代的老代码负责提供一个能被大家理解的底座openGauss 的自研模块不断在这个底座上“生长”。所以你读源码的过程中经常会有一种奇妙的感觉——同一个系统里既有 PostgreSQL 那种“稳如老狗”的经典实现又有大量完全打破传统思路的新设计。这种“新老同堂”的状态正是 openGauss 源码最有意思的地方。1.2 openGauss 到底解决了什么问题讲技术之前得先搞清楚这套数据库的价值定位。openGauss 的核心场景是企业级关键任务负载说直白点就是那种“挂了会出大事”的业务系统比如银行的账务、电力的计量、制造企业的订单中心。这类场景对强一致、高可用、数据不丢失的要求远高于互联网常见的“海量并发 最终一致”玩法。所以在源码层面你会看到 openGauss 花大量精力在 WAL 日志、恢复流程、同步复制、事务一致性上。比如它把传统 PG 的 MVCC 快照机制改成了 CSN 逻辑时钟解决了事务号耗尽和备机扩展能力不足的问题再比如它在行存之外搞出了 Ustore 原地更新引擎专门针对索引膨胀和长事务场景。这些特性的背后都是明确的企业级诉求。理解了这个定位你再看源码时就会少很多困惑。为什么 openGauss 要加线程池为了在几千个并发连接下还能压住性能。为什么要做 NUMA 感知调度因为企业级服务器普遍是多路 CPU内存访问延迟差异不能视而不见。为什么要做全密态因为合规要求数据在数据库内部也不能裸奔。这些问题串起来就是 openGauss 的完整画像。1.3 什么样的人适合啃这套代码我的经验是读 openGauss 源码不需要你天赋异禀但需要三个基础C 语言能看懂指针和结构体、对操作系统进程线程和内存有基本概念、愿意把一个 SQL 从输入到输出的完整链路走一遍。有 PostgreSQL 背景的人上手会快很多毕竟大量术语和代码风格是相通的。但反过来如果你完全没看过 PG直接读 openGauss 也完全可以只是会多花点时间适应。整体来说这套源码的入口比很多人想象中友好——至少它有完整的中文文档、活跃的社区和大量公开的架构设计说明比很多所谓“经典但无人维护”的数据库代码好读得多。2. 技术全景俯瞰openGauss 架构与核心模块2.1 从 SQL 到硬盘一条完整的数据链路在 openGauss 里一条 SQL 语句从客户端发出到最终把数据写到磁盘至少要经过五个逻辑模块接入层、SQL 引擎、执行引擎、存储引擎、日志与恢复。接入层负责处理客户端连接网络通信和会话管理在这里完成。SQL 引擎做的事情是词法分析、语法分析、语义分析、查询重写和查询优化。执行引擎拿到优化器产生的执行计划后真正去扫描表、做连接、聚合、排序。存储引擎管的是数据页、索引、缓冲区、事务可见性这些东西。日志与恢复则负责保证任何时刻数据库崩溃了都能按照 WAL 日志回到一致状态。这套分层是所有关系型数据库的通用框架openGauss 也不例外。读源码的时候你最好先在心里画清楚这条链路再具体到某个模块。否则随便抓一个函数开读很容易迷失在代码海洋里。2.2 进程模型它不是“一个数据库程序”而是一个进程家族openGauss 沿用了 PostgreSQL 的“多进程 共享内存”模型。启动数据库后你会看到一堆 gaussdb 进程其中最核心的是 postmaster 主进程它是整个数据库的守护者。客户端连接进来后postmaster 会 fork 出一个 postgres backend 进程专门服务这个会话。后台还有一堆工作者进程比如 WALwriter 负责写日志、BgWriter 负责异步回写脏页、PageWriter 负责预分配页、CheckPointer 负责检查点、SysLogger 负责日志输出。为什么 openGauss 不用多线程多进程的好处是隔离性好一个后端进程崩了不会拖垮整个数据库这符合企业级系统对稳定性的执念。但多进程也有代价——连接数上去之后进程切换和内存占用都很大。所以 openGauss 后续又搞了线程池把高频的 backend 工作转成线程池里的任务本质上是对多进程模型的一种补偿。看代码的时候建议你先确认一个函数到底跑在哪个进程或线程里。因为数据库里到处都是共享内存和全局状态你搞不清执行上下文就很容易误解变量的作用范围。2.3 CSN、存储引擎与 WAL读源码前必须认识的几个关键词CSNCommit Sequence Number是 openGauss 对 PostgreSQL 事务系统最重要的改造之一。传统 PG 用事务 ID 做快照比较openGauss 改成用一个全局递增的提交序号作为事务提交顺序标记。这样做的好处是事务号不会快速回卷备机也可以基于 CSN 构建更高效的快照。你在源码里会频繁看到 csn 相关结构体强烈建议先把这个概念吃透再看事务模块。存储引擎方面openGauss 现在是“多引擎共存”的状态。ASTORE 是对 PG 行存风格的延续追加更新旧版本保留在原页面里。Ustore 是自研的原地更新引擎更新时直接改原数据把旧版本链写到独立的 Undo 段里能显著减少索引膨胀。MOT 是内存优化表整张表活在内存里走的是完全不同的无锁乐观并发路线。再加上列存表和向量化执行openGauss 的存储层远比表面看起来复杂。WAL 就更不用说了任何数据库崩溃恢复的底气都来自日志。openGauss 在 WAL 方面做了并行日志、日志压缩、共享日志等大量优化。读存储和事务相关代码时随时准备好和 WAL 打交道。2.4 高可用与形态扩展从主备复制到资源池化openGauss 的高可用基础是主备流式复制主库把 WAL 日志实时发送给备库备库回放日志保持数据同步。支持同步、异步、quorum 等多种模式。再往上走社区还引入了 DCF 组件可以让多副本之间通过一致性协议自动选主。资源池化形态则更进一步把计算和存储分离多台计算节点共享一份存储配合 DMS 做缓存一致性。这些高级能力在源码里都有对应的模块比如 replication、dcf、dms 等目录。我的建议是初读阶段不要一头扎进这些分布式相关模块先把单机内核主链路读顺。等高可用、资源池化相关的文章更新到后面再跟着系列文章逐个深入也不迟。3. 动手之前源码下载、编译和实例启动3.1 源码获取与版本选择openGauss 的代码托管在 Gitee 官方仓库地址是 gitee.com/opengauss/openGauss。clone 命令很简单git clone https://gitee.com/opengauss/openGauss.git但我不建议你直接拉 master 分支就开始读。master 是开发分支今天看到的函数签名可能过俩月就变了。更稳的做法是先确定一个发布版本比如基于 5.0.0 或者 6.0.0 的 tag 建立本地分支git clone -b V500R001C00 https://gitee.com/opengauss/openGauss.git选择版本时要考虑两个因素一是你手上的学习资料比如社区博客、官方文档对应的版本二是你机器上操作系统和工具链的兼容性。系列文章后续默认以当前最新的稳定发布版本作为基线你尽量对齐否则有些代码位置对不上会很伤。3.2 编译环境准备依赖、磁盘和内存openGauss 的编译依赖不算特别苛刻但确实需要提前装齐。常见的依赖包括 gcc、g、make、flex、bison、readline-devel、zlib-devel、libaio-devel、ncurses-devel、openssl-devel 和 python3。系统推荐 openEuler、CentOS、Ubuntu 这类主流 Linux 发行版x86 和 ARM 架构都能编译。内存建议至少 8GB磁盘剩余空间建议保持在 50GB 以上。openGauss 的编译过程非常吃资源尤其是多进程并行编译时很容易把内存打满。磁盘方面除了源码本身编译产物和安装包都会占不少空间。编译方式上openGauss 提供了 build.sh 一键脚本。你先确认依赖库路径然后执行sh build.sh -m release -t make -3rd /path/to/binarylibs这里的 binarylibs 是预编译的三方库压缩包如果你的环境里没有需要先从社区下载对应版本的 binarylibs或者让脚本自动下载。我建了一个普通用户来做编译避免 root 账户带来的路径和权限问题这一条很多人容易忽略。3.3 初始化实例从编译成功到跑起来编译完成后安装目录下会生成 bin、lib、share 等子目录。接下来需要配置环境变量export GAUSSHOME/opt/opengauss export LD_LIBRARY_PATH$GAUSSHOME/lib:$LD_LIBRARY_PATH export PATH$GAUSSHOME/bin:$PATH然后初始化数据目录。openGauss 的 gs_initdb 跟 PG 的 initdb 类似但必须指定 node 名称gs_initdb -D /data/ogdata --nodenameprimary初始化完成后启动数据库gs_ctl start -D /data/ogdata最后用 gsql 连接测试gsql -d postgres -p 5432能正常连接上说明你的 openGauss 环境已经可以开工了。后续所有源码实验都会在这个环境上进行。4. 源码目录地图在 openGauss 里找代码的正确姿势4.1 顶层目录与 PostgreSQL 的差异我第一次打开 openGauss 源码目录时第一反应是“这目录结构怎么跟 PG 不太一样”。顶层会有 src、contrib、build 等目录但 src 下面多了一个非常显眼的子目录 gausskernel。这个目录是整个 openGauss 自研代码的核心容器。如果你带着 PostgreSQL 的经验进来需要习惯一个事实PG 原本集中在 src/backend 下的很多模块在 openGauss 里被重新组织到了 src/gausskernel 下。比如优化器、执行器、存储引擎的主要代码都能在 gausskernel 里找到对应目录。而 src/backend 下仍然保留着大量基础实现比如 postmaster、libpq、部分存储和日志代码。所以不能简单说“src/backend 是老代码gausskernel 是新代码”它们之间更像是“基础公共代码”和“深度改造/自研代码”的协作关系。4.2 src/gausskernel自研核心从这里看起我整理了一份 openGauss 关键目录速查表方便你快速定位功能位置目录主要功能src/gausskernel/storage存储引擎、缓冲区、WAL、CSN 日志src/gausskernel/optimizer查询优化器src/gausskernel/executor执行器含向量化执行src/gausskernel/parser语法与词法分析src/gausskernel/rewrite查询重写src/gausskernel/catalog系统表管理src/gausskernel/postmaster进程与线程管理src/gausskernel/tcop顶层命令处理入口src/gausskernel/nodes节点结构体定义src/gausskernel/utils内存、缓存、时间等通用工具src/gausskernel/replication主备复制src/gausskernel/dcf一致性协议组件src/gausskernel/dms资源池化相关表格只是定位用的“路标”不要把它当成严格的物理划分。实际代码里模块之间会有大量跨目录调用这是正常的。4.3 自研特性在代码中的落点如果你对某个具体特性感兴趣可以按下面的索引直接找切入点特性建议起点Ustore 存储引擎src/gausskernel/storage/access/ustoreMOT 内存表src/gausskernel/storage/motCSN 事务快照src/gausskernel/storage/access/csnlog列存与向量化src/gausskernel/executor/vec 及 cstore 相关目录线程池src/gausskernel/threadpoolWAL 并行回放src/gausskernel/storage/access/parallel_recovery这些目录在 5.0.0 左右的代码里基本都能找到。不同版本之间文件名可能略有差异但大体路径是稳定的。阅读时如果找不到多用 grep 搜关键词比照着目录树硬翻高效得多。4.4 检索代码的几个实用技巧读这种规模的源码单纯靠人肉翻肯定不行。我日常用的组合是 ripgrep ctags VSCode。ripgrep 负责全局搜函数名、宏、报错信息ctags 负责跳转定义VSCode 负责整体阅读体验。尤其是报错日志定位很多时候 SQL 执行报错会打印函数名和行号直接拿这个去源码里搜比从 main 函数开始追快十倍。5. 如何开始阅读源码一种可行的学习路线5.1 路线一按 SQL 执行链路走一遍这是最适合新手的入门路径。选定一条最简单的 SQL比如SELECT 1或者SELECT * FROM t WHERE id 1然后用调试器从客户端连接开始到解析、重写、优化、执行一步步跟下去。核心入口在 tcop 目录下的标准查询处理流程你会看到exec_simple_query、pg_parse_query、pg_analyze_and_rewrite、pg_plan_query、PortalRun这一系列函数。第一次走通这条链路你对数据库内核的认知会从一个模糊的整体变成一张清晰的地图。之后再看任何模块都会知道自己处于链路的哪个位置。5.2 路线二从存储和日志切入如果你对崩溃恢复、页结构、事务可见性更感兴趣可以从存储引擎和 WAL 入手。先搞懂数据在磁盘上长什么样再理解日志是怎么按顺序写的最后看恢复流程怎么把数据库拉回一致状态。这条路线适合想深入研究数据库可靠性的读者难度稍高但收获也大。5.3 路线三以新特性为突破口openGauss 的很多设计在传统 PG 里是看不到的比如 Ustore 的 undo 链、MOT 的无锁结构、CSN 的可见性判断。你可以选择一个自己最有好奇心的特性从社区的设计文档读到代码实现。这种“特性驱动阅读”的好处是目标明确不用面对全量代码的压迫感。5.4 调试工具辅助用 gdb 让代码“动起来”静态读代码容易卡住最好的办法是让代码跑起来在关键函数上打断点看变量变化。比如几个核心函数直接用 gdb 启动 gaussdb设置断点然后从另一个终端发起 SQL。你会亲眼看到一条 SQL 是如何一步一步变成执行计划的。日志参数也要学会用log_min_messages、debug_print_plan这类开关能帮你把内部状态打到日志里排查问题非常方便。6. 读源码过程中最容易踩的坑6.1 编译阶段常见问题速查现象可能原因处理方式gcc 版本报错系统 gcc 过旧升级 gcc 或切换更高版本工具链flex/bison 找不到未安装或版本不匹配安装 flex、bison检查 PATH编译中途 OOM内存不足增加内存或 swap减少并行编译参数三方库缺失binarylibs 没指定或下载失败下载对应版本 binarylibs配置 -3rdroot 编译报错权限和路径问题换普通用户目录属主改对6.2 启动与连接阶段常见问题现象可能原因处理方式gs_initdb 失败磁盘空间、目录权限、nodename 非法检查磁盘确认目录属主命名符合规范端口被占用默认 5432 被其他程序占用修改 postgresql.conf 的 portgsql 连接失败监听地址或 pg_hba.conf 配置不对放开 listen_addresses检查认证规则日志找不到日志目录不确定查看数据目录下的 pg_log6.3 阅读与理解阶段的认识误区最大的误区是总想着从头读到尾。openGauss 源码少说几百万行线性阅读根本不现实。正确做法是带着问题读这个模块解决什么问题它对数据结构和核心流程的改动在哪里和 PG 原版相比差异在哪第二个误区是忽视版本差异。你搜到的博客可能是 3.0 时代的代码已经更新到 6.0函数名、目录都可能变了。看任何文章前先确认版本否则会浪费时间在“找旧函数”上。第三个误区是不看日志只看代码。很多时候代码逻辑和实际运行结果之间隔着海量细节直接用日志和调试器验证比空想要有效得多。我个人在实际操作中还有一个很深的体会不要一开始就啃最复杂的部分比如 DCF、资源池化这类很容易劝退。先把单机主流程吃透再往分布式和高可用方向扩展节奏会舒服很多。这个系列后续也会按照这个思路来排下一篇会从 openGauss 的进程启动和 gs_ctl start 流程入手带大家真正把代码跑起来从第一个 fork 出来的进程开始认识这个系统。
