到底是如何判定日志类型是ob_log_trans_mutator还是 ob_log_trans_redo呢

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】3.1.5
【问题描述】
同一事务，触发了一次即时日志ob_log_trans_mutator，commit后出现了ob_log_trans_redo 和 ob_log_trans_redo_with_prepare。 为什么commit后的增量数据是trans_redo，而没有在commit前就生成ob_log_trans_mutator？（mutator和redo日志的data_len都差不多）
会不会是因为commit前事务内存数据还没达到2M，commit后就将这部分事务数据转化为clog时，为了保证日志数据长度不超过1.875M，于是就拆分成了一个redo，剩下的redo和prepare融合成了ob_log_trans_redo_with_prepare？

#3

看文档介绍，OB_LOG_MUTATOR 是事务执行时的日志，OB_LOG_TRANS_REDO是事务提交时的日志，至于OB_LOG_TRANS_REDO_WITH_PREPARE和OB_LOG_TRANS_REDO有什么区别，文档里面看不出来。。你这是通过代码来看出这块的变化的么

image
image1920×786 113 KB

image
image1900×1080 253 KB

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001431764

1 个赞
#4

其实我的疑问是为什么redo中记录的那些数据变化 没有在事务进行中的时候就给它持久化为mutator日志。

#5

都持久化了啊。。你看我上面的两个截图
事务执行时和事物提交时对应的OB_LOG_MUTATOR 和OB_LOG_TRANS_REDO 都做了持久化的，我能想到对应的场景就是比如leader节点事务写入过程中宕机，其他follwer节点其实是实时应用了这部分未提交事物的日志，这个时候需要回滚数据，所以在follower上其实都会持久化来保证切主后回滚的数据一致性

#6

我都看了，我知道都持久化了。。。您可能没太理解我的意思或者我没表述清楚。没事，谢谢您回复。
是问 提交时持久化的trans_redo日志里所记录的数据变化 为什么不在事务进行中持久化的trans_mutator日志里记录。

#7

你这么说我理解了，确实看文档这块说的不太清楚。。没有说明事务进行时修改内容的持久化和事务提交时修改内容的持久化是否为相同数据
个人理解如果是相同数据的冗余设计，可能是为了保证提交时的数据正确性
如果是不同内容，那就需要咱们论坛里面的大佬在详细解释下 :joy:

#8

你的理解基本正确。在 OceanBase 数据库中，Redo 日志的最大大小为 2 MB。当事务在执行过程中产生的数据量超过 2 MB 时，会生成 Redo 日志并提交到 Clog 模块，以确保日志不会过大。

具体来说，commit 前事务内存数据未达到 2 MB，因此只触发了一次 OB_LOG_MUTATOR 日志。而在 commit 时，为了保证日志数据长度不超过 1.875 MB，事务数据被拆分成了多个日志条目，分别生成了 OB_LOG_TRANS_REDO 和 OB_LOG_TRANS_REDO_WITH_PREPARE 日志。

这种机制有助于提高性能，因为在事务提交时，每条日志都需要经过 Multi-Paxos 同步到多数派副本，这个过程涉及较多的网络通信，耗时较多。因此，将大事务拆分成多个较小的日志条目可以减少每次同步的时间，提高整体性能。

总结：

  • 事务在执行过程中产生的数据量未达到 2 MB 时，只生成一次 OB_LOG_MUTATOR 日志。
  • 在 commit 时，为了保证日志数据长度不超过 1.875 MB，事务数据被拆分成了多个日志条目，分别生成了 OB_LOG_TRANS_REDO 和 OB_LOG_TRANS_REDO_WITH_PREPARE 日志。
  • 这种机制有助于提高性能，减少每次同步的时间。