三副本下的多表事务插入的执行计划类型(分布式事务)策略的疑问

Oceanbase数据库版本:5.7.25-OceanBase_CE-v4.3.5.3

部署方式:三台服务器,分布式部署,分为zone1、zone2、zone3
zone1:192.168.0.158
zone2:192.168.2.221
zone3:192.168.3.2

创建租户语句:

CREATE RESOURCE UNIT myunit_1
                MEMORY_SIZE = '32000M',
                MAX_CPU = 10, MIN_CPU = 10,
                LOG_DISK_SIZE = '70G';
CREATE RESOURCE POOL mq_pool_01 
                UNIT='myunit_1', 
                UNIT_NUM=1, 
                ZONE_LIST=('zone1','zone2','zone3'); 
                
CREATE TENANT IF NOT EXISTS mytenant PRIMARY_ZONE='zone1,zone2,zone3', RESOURCE_POOL_LIST=('mq_pool_01') set OB_TCP_INVITED_NODES='%';

导入1384张表后,表的分布如下:
查看所有表的Leader分布:
192.168.0.158(462张表)
192.168.2.221(461张表)
192.168.3.2(461张表)

其中三张表的Leader分布:
possalegood:192.168.2.221
possaleorder:192.168.3.2
possalepay:192.168.0.158

测试非事务插入表语句:

insert into possalegood values -- 值列表
insert into possaleorder values -- 值列表
insert into possalepay values -- 值列表

查看GV$OB_SQL_AUDIT审计

SVR_IP PLAN_ID QUERY_SQL PLAN_TYPE TX_ID
192.168.0.158 12636 INSERT INTO damingfu.possalepay 1 31064
192.168.2.221 627 INSERT INTO damingfu.possalegood 1 83289
192.168.3.2 443 INSERT INTO damingfu.possaleorder 1 43167

测试事务插入表语句:

begin;
insert into possalegood values -- 值列表
insert into possaleorder values -- 值列表
insert into possalepay values -- 值列表
end

查看GV$OB_SQL_AUDIT审计

SVR_IP PLAN_ID QUERY_SQL PLAN_TYPE TX_ID
192.168.0.158 12636 INSERT INTO damingfu.possalepay 1 29932
192.168.2.221 12598 INSERT INTO damingfu.possalegood 1 29932
192.168.3.2 420 INSERT INTO damingfu.possaleorder 1 29932

客户端连接方式,通过OBProxy的2883端口连接集群执行SQL语句

我的疑问:

1.按照这三张表的Leader分布,他们分别在三个不同的zone,做事务插入的时候为什么没有产生分布式事务(根据audit查询,PLAN_TYPE 是1,文档说明1、2、3 分别表示 Local 、Remote 、Distribute 执行计划)

2.为什么三个insert语句的SVR_IP不同,但是PLAN_TYPE却又是1(表示Local本地事务)呢

3.事务是如何完成的,三次插入是在同一台机器上完成的?如果是的话,Leader的作用的含义我自己的理解就比较模糊了。分布式事务到底是什么情况下会触发。

4.既然采用多Zone的话会不可避免的产生分布式事务(我们是ERP系统,一个修改或插入事务涉及到的表关系错综复杂),而分布式事务的性能又低于本地事务,那有什么方法规避这个问题麽?还是我们这样的业务和这样的部署方式并不是Oceanbase说提倡的最优方式?

注:经过各种查询,了解到的信息是Audit中的PLAN_TYPE指的是语句执行所在机器上是否是本地执行,而不代表整个事务是不是本地执行,这样倒也能解释的通,ODP把语句发送到各自Leader所在的机器上,他们只在所在机器上单机执行力,所以为显示未1

5.那么到底什么样的部署环境,什么样的数据会导致Audit表中的PLAN_TYPE 为2或3
6.如何在语句执行后查看一个事务整体到底是不是分布式事务,Audit中的PLAN_TYPE 只能代表事务中的单条语句的类型
7.分布式事务到底相对于本机事务损耗多少,有什么规则和计算方法麽,或者感知是不是明显?

1 个赞

1 个赞

使用2881端口 , 不使用2883端口, 就会产生 分布式事务了 您可以测试下

1 个赞

@论坛小助手
帮忙回答

关于您的问题,以下是详细的解答和相关的文档内容:

  1. 分布式事务的触发条件:

    • 在OceanBase中,分布式事务的触发通常是因为事务涉及到了多个分区的Leader副本。然而,事务的分布式特性并不完全由表的Leader分布决定,而是由事务所操作的数据分区决定的。如果一个事务的所有操作都在同一个分区上执行,即使这些表的Leader分布在不同的节点上,该事务仍然被认为是本地事务。
  2. PLAN_TYPE为1的解释:

    • PLAN_TYPE为1表示的是单个SQL语句在执行时是在本地节点上执行的。即使事务中的所有SQL语句分别在不同的节点上执行,只要每个SQL语句在其对应的Leader节点上执行,PLAN_TYPE就会显示为1。这意味着每个SQL语句都是在本地节点上执行的,而不是跨节点执行。
  3. 事务的执行过程:

    • 在您的场景中,事务中的三条INSERT语句分别在不同的节点上执行,但每个语句都是在其对应的Leader节点上执行的。事务的提交是由OBProxy协调的,OBProxy会确保所有参与事务的节点都成功提交。因此,尽管每个SQL语句在不同的节点上执行,整个事务仍然是一个协调的分布式事务,但在审计日志中,每个SQL语句的PLAN_TYPE显示为1,因为它们在各自的Leader节点上执行。
  4. 规避分布式事务的方法:

    • 分区设计: 通过合理的设计分区键,尽量将相关的数据放在同一个分区上,减少跨分区的操作。
    • 事务设计: 尽量将事务拆分成多个小事务,每个小事务只涉及少量的表或数据分区。
    • 分区 Leader 分布: 通过调整分区 Leader 的分布,使得相关的表的Leader尽可能集中在同一个节点上,减少跨节点的事务。
  5. PLAN_TYPE为2或3的条件:

    • PLAN_TYPE为2表示远程执行,通常是因为SQL语句涉及到了远程分区的数据。
    • PLAN_TYPE为3表示分布式执行,通常是因为事务涉及到了多个分区的Leader副本,需要协调多个节点的执行。
  6. 查看事务的整体类型:

    • 要查看一个事务的整体类型,可以通过查看事务的TX_ID,找到所有涉及的SQL语句,分析这些SQL语句的PLAN_TYPE。如果事务中的任何一条SQL语句的PLAN_TYPE为2或3,则该事务整体上是一个分布式事务。
  7. 分布式事务的性能损耗:

    • 分布式事务的性能损耗主要来自于网络延迟和协调成本。具体损耗的多少取决于多个因素,包括网络延迟、事务的复杂度、涉及的节点数量等。一般来说,分布式事务的性能会低于本地事务,但具体的损耗可以通过性能测试来量化。

相关文档内容:

  • 文档1 提供了关于OBServer使用对象存储备份时报错误的原因及解决方法,与您的问题无关。
  • 文档2 提供了关于OBServer和应用服务器之间的通信细节,与您的问题无关。
  • 文档3 提供了关于clog同步延迟的查询SQL,与您的问题无关。
  • 文档4 提供了关于OceanBase数据库连接超时的相关配置,与您的问题无关。
  • 文档5 提供了关于删除节点后的配置问题,与您的问题无关。
  • 文档6 提供了关于SQL调优的计划缓存案例,与您的问题无关。
  • 文档7 提供了关于连接池配置的建议,与您的问题无关。
  • 文档8 提供了关于ODP的功能介绍,与您的问题无关。
  • 文档9 提供了关于JDBC连接池配置的建议,与您的问题无关。
  • 文档10 提供了关于OceanBase数据库字符集和字符序的介绍,与您的问题无关。
  • 文档11 提供了关于DBA_OB_ARCHIVELOG_PIECE_FILES表的字段说明,与您的问题无关。
  • 文档12 提供了关于DBA_OB_ARCHIVELOG_PIECE_FILES表的字段说明,与您的问题无关。
  • 文档13 提供了关于DBA_OB_LS_REPLICA_TASK_HISTORY表的字段说明,与您的问题无关。
  • 文档14 提供了关于DBA_OB_LS_REPLICA_TASK_HISTORY表的字段说明,与您的问题无关。
  • 文档15 提供了关于CDB_OB_ARCHIVELOG_PIECE_FILES表的字段说明,与您的问题无关。

总结来说,您的问题主要涉及到事务的执行计划和分布式事务的触发条件。通过合理的分区设计和事务设计,可以有效减少分布式事务的出现,从而提升系统的性能。