# 服务器网关切换后域名解析故障排查实录

## 一、故障现象：IP能通，域名却“失踪”了？

上周在维护测试环境时遇到一个诡异的网络问题：某服务器（主机A）出现**能ping通外网IP（如8.8.8.8），但无法ping通域名** 的异常现象。其他配置未变更，仅网关从`172.19.0.150`改为`172.19.0.179`。这种“能通IP不通域名”的症状，直觉指向DNS解析链路异常，但具体问题点需要一步步拆解。

![](https://blog.lc044.love/static/img/5520f3a31bc534f2ea6ce017b16b85e8.image.webp)

毫无疑问，这个问题肯定是 DNS 的问题，但是 DNS 哪出了问题，却非常诡异。

## 二、初步排查：定位DNS解析的“断链点”

### 0. **更换网关，DNS解析正常**

更换另一个网关，网络恢复正常了，说明是网关的问题，那么问题就来了，一般来说 DNS 解析是跟网关没有关系的，网关有问题的话应该 Ping 不通 IP，只更换网关恢复正常说明 DNS 配置又没问题，这就是诡异的点：**网关跟DNS到底有什么关系**。

**ChatGPT这么说：**

![](https://blog.lc044.love/static/img/fc0a0106b0be56d5195852f3e6e94b8d.image.webp)

### 1. **DNS配置验证：先看基础设置**

* **查看当前DNS服务器**

  ```bash
  cat /etc/resolv.conf  
  # 输出nameserver 8.8.8.8（已手动设置公共DNS）
  ```

  ✅ 确认主机已正确配置DNS服务器（8.8.8.8），但问题依旧存在，说明配置无错，需排查网络通路。

### 2. **路由与连通性测试：ping与traceroute的双重验证**

* **测试DNS服务器连通性**

  ```bash
  ping 8.8.8.8  # 通！说明ICMP协议可达
  traceroute 8.8.8.8  # 路由路径正常，无明显丢包
  ```

  ✅ 物理链路和基础路由正常，但域名解析仍失败，问题聚焦到**DNS协议层面**。

### 3. **DNS解析实测：用工具撕开“表象”**

* **手动触发解析请求**

  ```bash
  nslookup baidu.com  # 超时无响应
  dig baidu.com  # 同样卡住，无返回结果
  ```

  ❌ 直接证据：DNS查询未成功获取响应，说明请求可能未送达或被拦截。


## 三、深度诊断：抓包工具揭露“协议级封锁”

### 1. **tcpdump抓包：监控DNS流量细节**

执行抓包命令后再次发起解析请求：

```bash
sudo tcpdump -i enp2s0f0 port 53 -n
```

**关键输出分析**：

* **UDP请求**：主机向8.8.8.8发送了UDP 53端口的A记录查询（`A? baidu.com`），但**无任何响应包**。
* **TCP请求**：尝试使用TCP协议重新查询（`dig +tcp baidu.com`），抓包显示**三次握手成功，且DNS服务器返回了解析结果**（包含baidu.com的IP地址）。

🔍 **核心结论**：

* UDP 53端口的DNS请求被网关或链路设备拦截，导致解析失败；
* TCP 53端口未受限制，说明问题出在**协议级过滤**（常见于防火墙对UDP DNS的封锁）。

## 四、网关特性分析：iKuai路由器的“特殊规则”

由于故障网关为**iKuai（爱快）路由器**，结合其功能特性进一步排查：

### 1. **防火墙策略检查**

登录iKuai管理后台（`http://172.19.0.179`），进入 **安全设置 &gt; 防火墙规则**，发现一条针对**UDP协议、目标端口53**的出站拦截规则。该规则默认阻断内网主机通过UDP协议访问外部DNS服务器，以防止DNS放大攻击，但误判导致正常解析请求被拦截。

### 2. **规则调整与验证**

* **修改规则**：将拦截动作改为“允许”，并指定目标端口为53（UDP）。
* **重启网络服务**：确保规则生效。
* **复测解析**：

  ```bash
  dig baidu.com  # 秒级返回解析结果，问题解决！
  ```

## 五、技术总结：从现象到本质的排查逻辑

### 1. **故障链还原**

`网关切换` → `触发UDP 53端口拦截规则` → `DNS查询请求（UDP）无法回包` → `域名解析失败`。
关键点：**UDP与TCP协议的差异化处理**——多数防火墙默认允许TCP 80/443等常用端口，但可能对UDP协议实施更严格的策略。

### 2. **通用排查方法论**

* **分层验证**：按“物理层→网络层→传输层→应用层”顺序排查，先确认IP连通性，再聚焦协议细节。
* **工具优先**：善用`ping/traceroute/dig/tcpdump`等工具，通过抓包获取原始流量数据，避免主观臆断。
* **设备特性适配**：不同厂商的网络设备（如iKuai、华为、Cisco）可能有默认安全策略，需结合官方文档分析规则逻辑。

## 六、延伸思考：DNS解析的“攻防博弈”

当前网络环境中，DNS常成为安全策略的“敏感点”：

* **运营商层面**：部分ISP会拦截非官方DNS请求，强制使用自有解析服务；
* **企业防火墙**：为防范数据泄露，可能限制UDP 53端口，仅允许通过HTTP(S)/TLS加密通道传输DNS数据（如DoH/DoT）。

**应对建议**：

* 若遇UDP封锁，可临时使用TCP解析（`dig +tcp`）或部署DNS加密工具（如cloudflared）；
* 长期方案需与网络管理员协同，在安全策略与业务需求间找到平衡点。

## 结语

这次故障排查看似围绕“DNS解析”，实则涉及网络协议特性、设备策略配置、安全规则适配等多个技术维度。作为运维人员，保持“用数据说话”的习惯（如抓包分析），比依赖经验判断更能快速定位问题。下次遇到类似“能通IP不通服务”的场景，不妨从协议层开始抽丝剥茧，往往能柳暗花明。

服务器网关切换后域名解析故障排查实录

## 一、openGauss中的事务持久性

　　和业界几乎所有的数据库一样，openGauss通过将事务对于数据库的修改写入可以永久（长时间）保存的存储介质中，来保证事务的持久性。这个过程被称为事务的持久化过程。持久化过程是保证事务持久性所必不可少的环节，其效率对于数据库整体性能影响很大，常常成为数据库的性能瓶颈所在。

　　最常用的存储介质是磁盘。对于磁盘来说，其每次读写操作都有一个“启动”代价，因此在单位时间内（每秒内），一个磁盘可以进行的读写操作次数（Input/Output Operations Per Second，简称IOPS）是有上限的。HDD磁盘的IOPS一般在1000次/秒以下，SSD磁盘的IOPS可以达到10000次/秒左右。另外一方面，如果多个磁盘读写请求的数据在磁盘上是相邻的，那么可以被合并为一次读写操作，这导致磁盘顺序读写的性能通常要远优于随机读写。

　　一般来说，尤其是在OLTP场景下，用户对于数据库数据的修改是比较分散随机的。如果在持久化过程中，直接将这些分散的数据写入磁盘，那么这个随机写入的性能是比较差的。因此，数据库通常都采用预写日志（Write Ahead Log，简称WAL）来避免持久化过程中的随机IO，如图4(a)所示。所谓预写日志，是指在事务提交的时候，先将事务对于数据库的修改写入一个顺序追加的WAL日志文件中。由于WAL日志的写操作是顺序IO，因此其可以达到一个比较高的性能。另一方面，对于真正修改的物理数据文件，再等待合适的时机写入磁盘，以尽可能合并该数据文件上的IO操作。

　　在一个事务完成日志的下盘操作（即写入磁盘）以后，该事务就可以完成提交动作。如果在此之后数据库发生宕机，那么数据库会首先从已经写入磁盘的WAL文件中恢复出该事务对于数据库的修改操作，从而保证事务一旦提交即具备持久性的特点。

　　下面结合图4(b)中的例子，简单说明数据库故障恢复的原理。假设一个事务需要在表A（对应数据文件A）和表B（对应数据文件B）中各插入一行新的记录，在数据库内部，其执行的顺序如下：

　　（1）记录修改数据文件A的日志，

　　（2）记录修改数据文件B的日志，

　　（3）在数据文件A中写入新的记录，

　　（4）在数据文件B中写入新的记录。

　　在上述过程中，如果在第（4）步执行时数据库发生宕机，那么该事务对于数据文件B的修改可能全部或部分丢失。当数据库再次启动以后，在其能够接受新的业务之前，需要将这些可能丢失的修改从日志中找回来（该操作被称为日志回放操作）。

　　在日志回放过程中，数据库会根据日志记录的先后顺序，依次读取每个日志的内容，然后判断该日志记录的事务对数据库数据文件的修改是否和当前相关数据文件的内容一致。如果一致，说明上次数据库停机之前修改已经写入数据文件中，该日志修改无需回放；如果不一致，说明上次数据库停机之前修改还未写入数据文件中，上次数据库停机可能是异常宕机导致，该日志对应的事务操作需要重新在相关数据文件中再次执行，才能保证恢复成功。

　　对于本例，在数据库恢复过程中，首先读取到在数据文件A中插入记录的日志，将数据文件A读取上来之后，发现数据文件A中已经包含该记录，因此该日志无需回放；然后读取到在数据文件B中插入记录的日志，将数据文件B读取上来之后，发现数据文件B中未包含新插入的记录，因此需要将日志中的记录再次写入到数据文件B中，从而完成恢复。最终，该事务对于数据库所有的修改都得以恢复出来，事务的持久性得到了保证。

![network-asset-640-20250519224440-eokqneg.webp](/static/img/fb5f847b30a1ec1902d0bacafb5c8734.network-asset-640-20250519224440-eokqneg.webp)

　　(a) WAL日志和数据页面的关系示意图

![](https://blog.lc044.love/static/img/fb5f847b30a1ec1902d0bacafb5c8734.network-asset-640-20250519224440-eokqneg.webp)

　　(b)WAL日志和故障恢复示意图

　　图4  WAL日志和事务持久性示意图

## 二、WAL 日志：核心同步内容

　　WAL（Write-Ahead Logging）日志记录了数据库的**物理变更**（如数据页修改）和**逻辑操作**（如事务提交），是主备同步的基础。主备之间通过**WAL 日志的传输和重放**实现数据一致性：

1. **主库**：所有事务修改先记录到 WAL，通过`WAL Sender`​进程发送给备库。
2. **备库**：通过`WAL Receiver`​接收日志，并应用（重放）到本地数据文件，保持与主库一致。

　　**关键点**：WAL 日志包含了事务的最终结果（如提交 / 回滚），但不直接同步事务的中间状态（如未提交的事务）。

### 主备复制中的 Undo 日志同步

　　在 OpenGauss 的主备架构中，**Undo 日志本身不直接同步到备库**，但与 Undo 相关的关键信息会通过 WAL 日志间接同步：

#### 1. **WAL 日志包含 Undo 相关操作**

　　WAL 日志记录了**事务对 Undo 日志的修改操作**（如创建、更新 Undo 记录），但不包含 Undo 日志的完整内容。例如：

* 当主库事务提交时，WAL 会记录 “提交事务 X” 的操作，备库重放此操作时会标记相应 Undo 记录为 “已提交”。
* 若事务回滚，WAL 会记录 “回滚事务 X”，备库通过重放此操作触发 Undo 日志的应用，恢复数据。

#### 2. **备库本地生成 Undo 日志**

　　备库在重放 WAL 日志时，会**本地生成自己的 Undo 日志**，用于支持 MVCC 和事务回滚。这些 Undo 日志基于主库 WAL 中的操作重建，而非直接复制主库的 Undo 日志。

### 通过备库 Undo 日志判断事务状态的局限性

　　虽然备库上存在 Undo 日志，但**无法直接通过 Undo 日志判断主库事务的实时执行情况**：

#### 1. **Undo 日志反映的是本地状态**

　　备库的 Undo 日志是重放 WAL 后的结果，仅反映**备库自身的事务状态**。例如：

* 若主库有未提交的事务，备库可能根本不知道该事务的存在（除非 WAL 已发送相关信息）。
* 备库上的 Undo 日志状态可能滞后于主库，尤其是在异步复制模式下。

#### 2. **事务中间状态不完整**

　　Undo 日志主要记录**数据变更前的状态**，而非事务的执行流程。例如：

* Undo 日志无法告诉你事务当前执行到哪条 SQL 语句。
* 无法通过 Undo 日志判断事务是否处于等待锁的状态。

#### 3. **备库只读限制**

　　备库通常作为只读节点（支持读操作），其 Undo 日志仅用于支持查询的多版本读，而非处理写事务。因此，备库只需根据 WAL 重放结果本地维护 Undo 日志，无需与主库的 Undo 日志完全一致，备库的 Undo 日志状态与主库的写事务状态无直接关联。

## 主备日志同步状态

　　用户可以通过参数设置当前事务的同步方式。

　　**该参数属于USERSET类型参数，可被任何用户在任何时刻设置。**

　　通常情况下，一个事务产生的日志的同步顺序如下：

1. 主机将日志内容写入本地内存。
2. 主机将本地内存中的日志写入本地文件系统。
3. 主机将本地文件系统中的日志内容刷盘。
4. 主机将日志内容发送给备机。
5. 备机接受到日志内容，存入备机内存。
6. 备机将备机内存中的日志写入备机文件系统。
7. 备机将备机文件系统中的日志内容刷盘。
8. 备机回放日志，完成对数据文件的增量更新。

　　参数取值范围：枚举类型

* on：表示主机事务提交需要等待备机将对应日志刷新到磁盘。
* off：表示主机事务提交无需等待主机自身将对应日志刷新到磁盘，通常也称为异步提交。
* local：表示主机事务提交需要等待主机自身将对应日志刷新到磁盘，通常也称为本地提交。
* remote\_write：表示主机事务提交需要等待备机将对应日志写到文件系统（无需刷新到磁盘）。
* remote\_receive：表示主机事务提交需要等待备机接收到对应日志数据（无需写入文件系统）。
* remote\_apply：表示主机事务提交需要等待备机完成对应日志的回放操作。

### 同步机制对比表

|状态类型|是否同步到备库？|同步方式|一致性保障|
| ----------| ----------------------------| -------------------------------------| --------------------|
|**WAL 日志**|✅ 必须同步|实时传输与重放|数据变更的强一致性|
|**事务状态**|✅ 最终状态（提交 / 回滚）|通过 WAL 日志中的提交记录(CLOG)同步|最终一致性|
|**锁状态**|❌ 不同步|备库不维护锁表，提升为主库时重建|切换后重新初始化|
|**快照状态**|❌ 不同步|查询时本地生成快照|查询时刻的一致性|


　　‍

　　‍


openGauss事务机制（二）

事务是数据库操作的执行单位，需要满足最基本的ACID（原子性、一致性、隔离性、持久性）属性。

 **（1） 原子性：** 一个事务提交之后要么全部执行，要么全部不执行。

 **（2） 一致性：** 事务的执行不能破坏数据库的完整性和一致性。

 **（3） 隔离性：** 事务的隔离性是指在并发中，一个事务的执行不能被其他事务干扰。

 **（4） 持久性：** 一旦事务完成提交，那么它对数据库的状态变更就会永久保存在数据库中。

**显式事务和隐式事务**

* **显式事务**是指，用户在所执行的一条或多条SQL语句的前后，显式添加了开启事务`START TRANSACTION语句`和提交事务`COMMIT`语句。
* **隐式事务**是指，用户在所执行的一条或多条SQL语句的前后，没有显式添加开启事务和提交事务的语句。在这种情况下，每一条SQL语句在开始执行时，openGauss内部都会为其开启一个事务，并且在该语句执行完成之后，自动提交该事务。

## 一、事务整体架构和代码概览

事务模块总体结构如图1所示。

![图1 总体结构](https://fastly.jsdelivr.net/gh/bucketio/img14@main/2025/05/29/1748525342310-250c0510-cc7e-4b43-96ff-80b3bfeaa1a3.png)

在openGauss中，事务的实现与存储引擎的实现有很强关联，代码主要集中在src/gausskernel/storage/access/transam及src/gausskernel/storage/lmgr下，关键文件如图1所示。

1. **事务管理器**：事务系统的中枢，它的实现是一个有限循环状态机，通过接受外部系统的命令并根据当前事务所处的状态决定事务的下一步执行过程。
2. **日志管理器**：用来记录事务执行的状态以及数据变化的过程，包括事务提交日志(CLOG)、事务提交序列日志（CSNLOG）以及事务日志（XLOG）。其中CLOG日志只用来记录事务执行的结果状态，CSNLOG记录日志提交的顺序，用于可见性判断；XLOG是数据的redo日志，用于恢复及持久化。
3. **线程管理机制**：通过一片内存区域记录所有线程的事务信息，任何一个线程可以通过访问该区域获取其他事务的状态信息。
4. **MVCC机制**：openGauss系统中，事务执行读流程结合各事务提交的CSN序列号，采用了多版本并发控制机制，实现了元组的读和写互不阻塞。详细可见性判断方法见“二 事务并发控制”。
5. **锁管理器**：实现系统的写并发控制，通过锁机制来保证事务写流程的隔离性。

## 二、事务并发控制

事务并发控制机制用来保证并发执行事务的情况下openGauss的ACID特性。下面将逐一介绍事务并发控制的各组成部分。

### （一）事务状态机

openGauss将事务系统分为上层（事务块TBlockState）以及底层（TransState）两个层次。通过分层的设计，在处理上层业务时可以屏蔽具体细节，实现灵活支持客户端各类事务执行语句（BEGIN/START TRANSACTION/COMMIT/ROLLBACK/END）。

1. **事务块TBlockState**：客户端query的状态，用于提高用户操作数据的灵活性，用事务块的形式支持在一个事务中执行多条query语句。
2. **底层事务TransState**：内核端视角，记录了整个事务当前处于的具体状态。

#### 1. 事务上层状态机

事务块上层状态机结构体代码如下：

```c++
typeset enum TBlockState
{
	/* 不在事务块中的状态：单条SQL语句 */
	TBLOCK_DEFAULT,/* 事务块缺省状态 */
	TBLOCK_STARTED,/*执行单条query 语句*/
	
	/* 处于事务块中的状态：一个事务包含多条语句 */
	TBLOCK_BEGIN,/* 遇到事务开始命令BEGIN/START TRANSACTION */
	TBLOCK_INPROGRESS,/* 表明正在事务块处理过程中*/
	TBLOCK_END,/ *遇到事务结束命令END/COMMIT */
	TBLOCK_ABORT,/* 事务块内执行报错，等待客户端执行ROLLBACK */
	TBLOCK_ABORT_END,/ *在事务块内执行报错后，接收客户端执行ROLLBACK */
	TBLOCK_ABORT_PENDING,/* 事务块内执行成功，接收客户端执行ROLLBACK（期望事务回滚）*/
	TBLOCK_PREPARE,/ *两阶段提交事务，收到PREPARE TRANSACTION命令*/
	
	/* 子事务块状态,与上述事务块状态类似 */
	TBLOCK_SUBBEGIN,/* 遇到子事务开始命令SAVEPOINT */
	TBLOCK_SUBINPROGRESS,/* 表明正在子事务块处理过程中*/
	TBLOCK_SUBRELEASE,/* 遇到子事务结束命令RELEASE SAVEPOINT */
	TBLOCK_SUBCOMMIT,/* 遇到事务结束命令END/COMMIT 从最底层的子事务递归的提交到最顶层事务*/
	TBLOCK_SUBABORT,/* 子事务块内执行报错，等待客户端ROLLBACK TO/ROLLBACK */
	TBLOCK_SUBABORT_END,/* 在子事务块内执行报错后，接收到客户端ROLLBACK TO上层子事务/ROLLBACK */
	TBLOCK_SUBABORT_PENDING,/* 子事务块内执行成功，接收客户端执行的ROLLBACK TO上层子事务/ROLLBACK */
	TBLOCK_SUBRESTART,/* 子事务块内执行成功，收到ROLLBACK TO当前子事务*/
	TBLOCK_SUBABORT_RESTART/* 子事务块内执行报错后，接收到ROLLBACK TO当前子事务*/
} TBlockState;
```

为了便于理解，可以先不关注子事务块的状态。当理解了主事务的状态机行为后，子事务块的状态机转换同父事务类似。父子事务的关系类似于一个栈的实现，父事务的子事务相较于父事务后开始先结束。

显式事务块的状态机及相应的转换函数如图2所示。


![图2事务块的状态机](https://fastly.jsdelivr.net/gh/bucketio/img4@main/2025/05/29/1748525395555-b3796f0c-3d18-4646-9206-c47f0a45b827.png)


**表1 事务块状态**

| 事务状态 | 事务状态机结构体 |
| -------------- | ------------------------------ |
| 默认 | TBLOCK\_DEFAULT |
| 已开始 | TBLOCK\_STARTED |
| 事务块开启 | TBLOCK\_BEGIN |
| 事务块运行中 | TBLOCK\_INPROGRESS |
| 事务块结束 | TBLOCK\_END |
| 回滚 | TBLOCK\_ABORT |
| 回滚结束 | TBLOCK\_ABORT\_END |
| 回滚等待 | TBLOCK\_ABORT\_PENDING |

在无异常情形下，一个事务块的状态机如图2所示按照默认（TBLOCK\_DEFAULT）-\>已开始（TBLOCK\_STARTED）-\>事务块开启（TBLOCK\_BEGIN）-\>事务块运行中（TBLOCK\_INPROGRESS）-\>事务块结束（TBLOCK\_END）-\>默认（TBLOCK\_DEFAULT）循环。剩余的状态机是在上述正常场景下的各个状态点的异常处理分支。

1. 在进入事务块运行中（TBLOCK\_INPROGRESS）之前出错，因为事务还没有开启，直接报错并回滚，清理资源回到默认（TBLOCK\_DEFAULT）状态。
2. 在事务块运行中（TBLOCK\_INPROGRESS）出错分为2种情形。

 1. 事务执行失败：事务块运行中（TBLOCK\_INPROGRESS）-\>回滚（TBLOCK\_ABORT）-\>回滚结束（TBLOCK\_ABORT\_END）-\>默认（TBLOCK\_DEFAULT）；
 2. 用户手动回滚执行成功的事务：事务块运行中（TBLOCK\_INPROGRESS）-\>回滚等待（TBLOCK\_ABORT\_PENDING）-\>默认（TBLOCK\_DEFAULT）。
3. 在用户执行COMMIT语句时出错：事务块结束（TBLOCK\_END）-\>默认（TBLOCK\_DEFAULT）。由图2可以看出，事务开始后离开默认（TBLOCK\_DEFAULT）状态，事务完全结束后回到默认（TBLOCK\_DEFAULT）状态。
4. openGauss同时还支持隐式事务块，当客户端执行单条SQL语句时可以自动提交，其状态机相对比较简单：按照默认（TBLOCK\_DEFAULT）-\>已开始（TBLOCK\_STARTED）-\>默认（TBLOCK\_DEFAULT）循环。

#### **2. 事务底层状态**

TransState结构体代码如下：从内核视角的事务状态，真正意义上的事务状态。

```c++
typedef enum TransState
{
	TRANS_DEFAULT,/* 当前为空闲缺省状态，无事务开启*/
	TRANS_START,/* 事务正在开启*/
	TRANS_INPROGRESS,/* 事务开始完毕，进入事务运行中*/
	TRANS_COMMIT,/* 事务正在提交*/
	TRANS_ABORT,/* 事务正在回滚*/
	TRANS_PREPARE/* 两阶段提交事务进入PREPARE TRANSACTION阶段*/
} TransState;
```

![图3事务底层状态](https://fastly.jsdelivr.net/gh/bucketio/img11@main/2025/05/29/1748525448439-7c64ab29-4445-4eb8-9acb-5685a33e70f1.png)

内核内部底层状态如图3所示，底层状态机的描述见结构体TransState。
（1） 在事务开启前事务状态为TRANS\_DEFAULT。
（2） 事务开启过程中事务状态为TRANS\_START。
（3） 事务成功开启后一直处于TRANS\_INPROGRESS。
（4） 事务结束/回滚的过程中为TARNS\_COMMIT/ TRANS\_ABORT。
（5） 事务结束后事务状态回到TRANS\_DEFAULT。

### **（二）事务ID分配及CLOG/CSNLOG**

为了在数据库内部区别不同的事务，openGauss数据库会为它们分配唯一的标识符，即事务id（transaction id，缩写xid），xid是uint64单调递增的序列。当事务结束后，使用CLOG记录是否提交，使用CSNLOG（commit sequence number log）记录该事务提交的序列，用于可见性判断。

#### **1. 64位xid及其分配**

openGauss对每一个写事务均会分配一个唯一标识。当事务插入时，会将事务信息写到元组头部的xmin，代表插入该元组的xid；当事务进行更新和删除时，会将当前事务信息写到元组头部的xmax，代表删除该元组的xid。当前事务id的分配采用的是uint64单调递增序列，为了节省空间以及兼容老的版本，当前设计是将元组头部的xmin/xmax分成两部分存储，元组头部的xmin/xmax均为uint32的数字；页面的头部存储64位的xid\_base，为当前页面的xid\_base。

元组结构如图8所示，页面头结构如图9所示，那么对于每一条元组真正的xmin、xmax计算公式即为：元组头中xmin/xmax + 页面xid\_base。


![图8 元组结构](https://fastly.jsdelivr.net/gh/bucketio/img11@main/2025/05/29/1748525574749-a3891231-c049-489d-9527-fb7558b2af4a.png)


![图9 页面头结构](https://fastly.jsdelivr.net/gh/bucketio/img11@main/2025/05/29/1748525595270-a95fb881-c1a7-4038-b24f-1dde9de28bce.png)

当页面不断有更大的xid插入进来时，可能超过“xid\_base + 232”，此时需要通过调节xid\_base来满足所有元组的xmin/xmax都可以通过该值及元组头部的值计算出来，详细逻辑见“2. CLOG、CSNLOG”内“3） 关键函数：”中的第(3)小节。

为了使xid不消耗过快，openGauss当前只对写事务进行xid的分配，只读事务不会额外分配xid，也就是说并不是任何事务一开始都会分配xid，只有真正使用xid时才会去分配。在分配子事务xid时，如果父事务还未分配xid，则会先给父事务分配xid，再给子事务分配xid，确保子事务的xid比父事务大。理论上64位xid已经足够使用：假设数据库的tps为1000万，即1秒钟处理1000万个事务，64xid可以使用58万年。

#### **2. CLOG、CSNLOG**

CLOG以及CSNLOG分别维护事务ID-\>CommitLog以及事务ID-\>CommitSeqNoLog的映射关系。由于内存的资源有限，并且系统中可能会有长事务存在，内存中可能无法存放所有的映射关系，此时需要将这些映射写盘成物理文件，所以产生了CLOG（XID-\>CommitLog Map）、CSNLOG（XID-\>CommitSeqNoLog Map）文件。CSNLOG以及CLOG均采用了SLRU（simple least recently used，简单最近最少使用）机制来实现文件的读取及刷盘操作。

1） CLOG用于记录事务id的提交状态。openGauss中对于每个事务id使用2个bit位来标识它的4种状态。CLOG定义代码如下：

```C++
#define CLOG_XID_STATUS_IN_PROGRESS 0x00 表示事务未开始或还在运行中（故障场景可能是crash）
#define CLOG_XID_STATUS_COMMITTED 0x01 表示该事务已经提交
#define CLOG_XID_STATUS_ABORTED 0x02 表示该事务已经回滚
#define CLOG_XID_STATUS_SUB_COMMITTED 0x03 表示子事务已经提交而父事务状态未知
```

CLOG页面的物理组织形式如图10所示。

![图10CLOG页面的物理组织形式](/static/img/708021e04f6422059a85d412aceeb636.image-20250522005406-di4yqj3.webp)

图10表示事务1、4、5还在运行中，事务2已经提交，事务3已经回滚。

2） CSNLOG用于记录事务提交的序列号。openGauss为每个事务id分配8个字节uint64的CSN号，所以一个8kB页面能保存1k个事务的CSN号。CSNLOG达到一定大小后会分块，每个CSNLOG文件块的大小为256kB。同xid号类似，CSN号预留了几个特殊的号。CSNLOG定义代码如下：

```C++
#define COMMITSEQNO_INPROGRESS UINT64CONST(0x0) 表示该事务还未提交或回滚
#define COMMITSEQNO_ABORTED UINT64CONST(0x1) 表示该事务已经回滚
#define COMMITSEQNO_FROZEN UINT64CONST(0x2) 表示该事务已提交，且对任何快照可见
#define COMMITSEQNO_FIRST_NORMAL UINT64CONST(0x3) 事务正常的CSN号起始值
#define COMMITSEQNO_COMMIT_INPROGRESS (UINT64CONST(1) << 62) 事务正在提交中
```

同CLOG相似，CSNLOG的物理结构体如图11所示。

![图11 CSNLOG的物理结构体](/static/img/e282fc06a36918f3faed44fd78111e64.image-20250522005352-nolbyi1.webp)

事务id 2048、2049、2050、2051、2052、2053的对应的CSN号依次是5、4、7、10、6、8；也就是说事务提交的次序依次是2049-\>2048-\>2052-\>2050-\>2053-\>2051。

### （三）**CSN机制**

1） CSN原理简单如图1所示

![图1 CSN原理](/static/img/9d7758943973d5364c169d5eeac0a2ef.network-asset-v2-54fe468a67fcbce05332944e31d13292_r-20250522091607-z6n8xvv.webp)

每个非只读事务在运行过程中会取得一个xid号，在事务提交时会推进CSN，同时会将当前CSN与事务的xid映射关系保存起来（CSNLOG）。图5-12中，实心竖线标识取snapshot（快照）时刻，会获取最新提交CSN（3）的下一个值4。TX1、TX3、TX5已经提交，对应的CSN号分别是1、2、3。TX2、TX4、TX6正在运行，TX7、TX8是未来还未开启的事务。对于当前snapshot而言，严格小于CSN号4的事务提交结果均可见；其余事务提交结果在获取快照时刻还未提交，不可见。

### （四）**提交流程**

事务提交流程如图3所示。

![图3提交流程](/static/img/42df4308d09442e83538ffc42a6cd328.image-20250529212314-nl1419d.webp)

（1） 设置CSN-XID映射commit-in-progress标记。

（2） 原子更新NextCommitSeqNo值。

（3） 生成redo日志，写CLOG，写CSNLOG。

（4） 更新PGPROC将对应的事务信息从PGPROC中移除，xid设置为InvalidTransactionId、xmin设置为InvalidTransactionId等。

**热备支持**

在事务的提交流程步骤（1）和（2）之间，增加 commit-in-progress 的XLOG 日志。备机在读快照时，首先获取轻量锁 ProcArrayLock ，并计算当前快照。如果使用当前快照中的CSN，碰到 XID 对应的 CSN 号有 COMMITSEQNO_INPROGRESS 标记，则必须等待相应的事务提交 XLOG 回放结束后再读取对应的 CSN 判断是否可见。为了实现上述等待操作，备机在对 commit-in-progress 的 XLOG 日志 做 redo 操作时，会调用 XactLockTableInsert 函数获取相应 XID 的事务排他锁；其他的读事务如果访问到该XID，会等待在此 XID 的事务锁上，直到相应的事务提交XLOg回放结束后再继续运行。


## 参考
 
[1]openGauss数据库源码解析，https://www.zhihu.com/column/c_1233714215367319552

openGauss事务机制（一）

## 一、操作系统

openEuler 22.03 x86_64

## 二、安装依赖

**新系统需要安装**

```python
sudo dnf install -y libaio-devel flex bison ncurses-devel glibc-devel patch readline-devel jemalloc-devel libcgroup-devel libcurl-devel libedit-devel libxml2-devel lz4-devel numactl-devel unixODBC-devel zstd zstd-devel java-1.8.0-openjdk-devel openssl-devel
### openEuler安装lsb_release
sudo dnf install dkms -y
sudo dnf install -y git make cmake nano tar
```

## **三、下载代码和第三方库**

### 3.1 下载第三方库

根据自己系统选择不同的第三方库

可以通过以下网站获取编译好的binarylibs。下载后请解压缩并重命名为**binarylibs**。

各版本和分支对应编译好的三方库二进制地址如下：

| 分支 | tag | gcc版本 | 下载路径 |
| --------- | ---------- | --------- | --------------------- |
| 5.0.0 | v5.0.0 | gcc7.3 | **openEuler 20.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_openEuler_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_openEuler_arm.tar.gz) **openEuler 20.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz) **Centos_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz) **openEuler 22.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs_2203/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs_2203/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz) **openEuler 22.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs_2203/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.0.0/binarylibs_2203/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz) |
| 5.1.0 | v5.1.0 | gcc7.3 | **openEuler 20.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz) **openEuler 20.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz) **Centos_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz) **openEuler 22.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz) **openEuler 22.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc7.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz) |
| | | gcc10.3 | **openEuler 20.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz) **openEuler 20.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz) **Centos_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz) **openEuler 22.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz) **openEuler 22.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/5.1.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz) |
| 6.0.0 | | gcc10.3 | **openEuler_arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz) **openEuler_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz) **Centos_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz) **openEuler 22.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz) **openEuler 22.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/6.0.0/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz) |
| master | | gcc10.3 | **openEuler_arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_arm.tar.gz) **openEuler_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_x86_64.tar.gz) **Centos_x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_Centos7.6_x86_64.tar.gz) **openEuler 22.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_arm.tar.gz) **openEuler 22.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz) **openEuler 24.03 arm:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2403_arm.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2403_arm.tar.gz) **openEuler 24.03 x86:** [https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2403_x86_64.tar.gz](https://opengauss.obs.cn-south-1.myhuaweicloud.com/latest/binarylibs/gcc10.3/openGauss-third_party_binarylibs_openEuler_2403_x86_64.tar.gz) |

注：6.0.0及以后的版本请使用gcc10.3的三方库进行编译

2. **将第三方库传到服务器上**

```bash
scp ./openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz zhousk@172.19.0.131:/home/llm10086
```

3. **解压**

```bash
tar -xzvf /home/llm10086/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz
```

4. **改名**

```bash
mv /home/llm10086/openGauss-third_party_binarylibs_openEuler_2203_x86_64.tar.gz /home/llm10086/binarylibs
```

### 3.1 下载代码

```bash
git clone https://gitcode.com/opengauss/openGauss-server.git
cd openGauss-server
pwd
# 输出当前路径
```

### 3.2 修改环境变量

```bash
nano ~/.bashrc
```

写入下面内容

```bash
export PATH
export CODE_BASE=/home/llm10086/project/openGauss-server # openGauss-server的路径
export BINARYLIBS=/home/llm10086/binarylibs # binarylibs的路径
export GAUSSHOME=$CODE_BASE/dest/
export GCC_PATH=$BINARYLIBS/buildtools/gcc10.3 # gcc的版本，根据三方包中对应的gcc版本进行填写即可，一般有gcc7.3或gcc10.3两种
export CC=$GCC_PATH/gcc/bin/gcc
export CXX=$GCC_PATH/gcc/bin/g++
export LD_LIBRARY_PATH=$GAUSSHOME/lib:$GCC_PATH/gcc/lib64:$GCC_PATH/isl/lib:$GCC_PATH/mpc/lib/:$GCC_PATH/mpfr/lib/:$LD_LIBRARY_PATH
# :$GCC_PATH/gmp/lib/
export PATH=$GAUSSHOME/bin:$GCC_PATH/gcc/bin:$PATH
```



Ctrl + X 保存

### 3.3 选择一个版本进行配置

**debug**版本：

```
# gcc10.3.1版本（一般用于openEuler + ARM架构）
./configure --gcc-version=10.3.1 CC=g++ CFLAGS='-O0' --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-debug --enable-cassert --enable-thread-safety --with-readline --without-zlib

# gcc10.3.0版本
./configure --gcc-version=10.3.0 CC=g++ CFLAGS='-O0' --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-debug --enable-cassert --enable-thread-safety --with-readline --without-zlib

```

**release**版本：

```
# gcc10.3.1版本（一般用于openEuler + ARM架构）
./configure --gcc-version=10.3.1 CC=g++ CFLAGS="-O2 -g3" --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-thread-safety --with-readline --without-zlib

# gcc10.3.0版本
./configure --gcc-version=10.3.0 CC=g++ CFLAGS="-O2 -g3" --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-thread-safety --with-readline --without-zlib

```

**memcheck**版本：

```
# gcc10.3.1版本（一般用于openEuler + ARM架构）
./configure --gcc-version=10.3.1 CC=g++ CFLAGS='-O0' --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-debug --enable-cassert --enable-thread-safety --with-readline --without-zlib --enable-memory-check

# gcc10.3.0版本
./configure --gcc-version=10.3.0 CC=g++ CFLAGS='-O0' --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-debug --enable-cassert --enable-thread-safety --with-readline --without-zlib --enable-memory-check

```

> **注意**
>
> * **[debug | release | memcheck]** 表示有三个目标版本可用。
> * 在**ARM**平台上，需要把 **-D__USE_NUMA** 添加至 **CFLAGS** 中。
> * 在**ARMv8.1**及以上平台（如鲲鹏920），需要把 **-D__ARM_LSE** 添加至**CFLAGS**中。
> * 如果**binarylibs**被移至**openGauss-server**中，或者在**openGauss-server**中创建了到**binarylibs**的软链接，则不需要指定 **--3rd** 参数。但请注意，这样做的话，该文件很容易被`git clean`命令删除。


### 3.5 编译安装

```bash
make -j8
make install -j8
```

显示如下信息，表示编译和安装成功。

```
openGauss installation complete.
```

* 编译后的软件安装路径为: **$GAUSSHOME**。
* 编译后的二进制文件存放路径为： **$GAUSSHOME/bin**。

openGauss编译指南

Motor: Enabling Multi-Versioning for Distributed Transactions on Disaggregated Memory

👨🏻‍💻这是一个充满知识💬的链接，快点进来看看你的好友给你分享了什么干货吧❣️