OB两阶段提交中的两个参与者到底是什么？

OceanBase 技术问题
#1

在mysql数据库中，事务的两阶段提交中涉及的两个参与者分别是binlog和redo log，那么在Oceanbase V4版本中的两阶段提交里，它的两个参与者又是什么呢？

1 个赞
#3

参与者是日志流

1 个赞
#4

另外你描述的mysql那个两阶段提交，跟OB的两阶段提交不是一个概念，OB两阶段提交针对的是分布式事务，MYSQL不存在分布式事务一说，分布式事务中涉及协调者和参与者，OB这里的参与者和协调者指的是日志流

1 个赞
#5

MySQL的两阶段提交（2PC）是InnoDB引擎用于保证redo log（重做日志）和binlog（二进制日志）数据一致性的核心机制‌，OB的两阶段提交是用来保证分布式事务一致性

2 个赞
#6

  1. 先是分布式事务，之后才是数据落盘原理，V4日志流是参于者。
    两阶段提交-V4.4.0-OceanBase 数据库文档-分布式数据库使用文档

  2. 当数据落到OceanBase的每个observer 节点上，事务提交遵循以下流程（这块比较像mysql落盘原理）

  1. 内存修改：事务在内存中进行修改操作，例如更新行数据。
  2. clog 持久化：事务的提交信息被记录在 clog（Commit Log）中，用于持久化事务的提交状态。
  3. Redo 日志写入：事务的修改被写入 Redo 日志，确保事务在崩溃恢复时不会丢失。
  4. sstable 异步合并：事务的修改异步合并到 sstable（Sorted String Table）中，最终实现数据的持久化。
1 个赞
#7

明白了，这么说，在OB里，如果我的事务并不是一个分布式的事务，比如一张表不是分区表，所有数据只存储在一个ob server 里，那么我现在开启了一个事务，事务中只对这张表的一条数据做update话，那这个事务的参与者只有一个，只是这张表所在的日志流，对吧？

1 个赞
#8

对于4X来说是这样的，但是存在一种情况下虽然修改的是单个日志流中涉及的数据，也会是分布式，比如会话执行的节点，跟数据所在的节点不是一个节点，虽然涉及的日志流是一个，这个事务也是分布式事务

image
image1920×1055 177 KB

2 个赞
#9

@论坛小助手

1 个赞
#10

在 OceanBase V4 中，如果您的事务不是一个分布式事务，例如一张表不是分区表，且所有数据只存储在一个 OBServer 里，那么您现在开启的事务，事务中只对这张表的一条数据做 update 操作的话，该事务的参与者确实只有一个，即这张表所在日志流的 leader。这符合单日志流事务的定义。

具体信息可参考以下文档:

  1. 事务日志说明
  2. 分布式事务概述
1 个赞
#11

举个例子，只设置了租户（1-1-1架构）的primary zone，
如果primary zone是Z1>Z2>Z3，那么这个租户涉及的日志流就1个，参与者最多是1个。
如果primary zone是Z1=Z2>Z3，那么这个租户涉及的日志流就1个，参与者最多是2个，取决与参与事务的分区是否分布在Z1和Z2。
如果primary zone是Z1=Z2=Z3，那么这个租户涉及的日志流就1个，参与者最多是3个，取决与参与事务的分区是否分布在Z1和Z2和Z3。

个人理解，参考

2 个赞
#12

:+1:~

#13

:wave:~

#14

:wave: :+1: