数据库 - MO干货 | 高效DEBUG事务正确性BUG - 个人文章

作者：张旭 MO研发工程师

Part 1. 事务回顾

Part 2. 事务的正确性问题

Part 3. 如何高效 DEBUG

熟悉数据库分布式事务的读者，应该能够理解DEBUG分布式事务正确性问题的BUG是一件非常有挑战的事情。本文主要是给大家介绍一下，MatrixOne在研发过程中，是如何DEBUG事务正确性问题的。

1. 事务回顾

我们首先来回顾一下，在 MatrixOne 中，事务是如何实现的。

1.1 数据存在哪儿

MatrixOne 是一个云原生的数据库，数据库中大部分的数据都存储在对象存储（可以是任何S3兼容的对象存储）中，这部分数据是不变的。数据不可变带来了非常多的好处，比如不需要考虑这些数据的一致性问题。

除了存储在对象存储中的数据外，还有非常少的数据存储在LogService中，LogService是一个使用 Raft 实现的高性能的 WAL 服务。这部分数据在 MatrixOne 中被称为 LogTail。这部分数据是变化的，可以认为是 MatrixOne 集群最新的 Commit 数据。

对象存储 + LogTail组成了 MatrixOne 的全量数据。

1.2 事务隔离级别

MatrixOne 的事务支持RC和SI的隔离级别，默认是RC。

1.3 事务模式

MatrixOne 的事务支持悲观和乐观的模式，默认是悲观。

1.4 事务并发控制

MatrixOne 使用 MVCC 来实现事务并发控制。并且使用 HLC 来实现事务时钟。

1.5 事务读操作

对于事务的读操作而言，首先需要确定的就是哪些数据对于事务是可见的。在任何一个时刻，对于事务可见的数据包括:

对象存储中所有CommitTimestamp < txn.SnapshotTimestamp的数据
LogTail中所有CommitTimestamp < txn.SnapshotTimestamp的数据
事务的Workspace中所有的Uncommitted的数据

在我们明确哪些数据对于事务是可见的时候，就需要确定满足条件的数据在读发生的时候，是否完整。

Workspace中的数据，任何时刻对于事务都是完整的。需要保证的就是对象存储和LogTail的数据了。由于LogTail是整个 MatrixOne 集群最新的数据写入，所以只要保证LogTail的数据完整了，那么对象存储对应的数据对于事务也就完整了。

现在的问题就是如何保证LogTail的数据对于事务是完整的。

MatrixOne 的事务在CN节点创建，事务创建后，就会明确一个事务的SnapshotTimestamp（这个时间戳对于SI是整个事务生命周期不变的，对于RC是每个Statement的生命周期内是不变的）。

LogTail的数据在TN节点产生，并且写入LogService。CN使用订阅的方式来获得最新的LogTail数据，并且把这些LogTail中的数据Apply到CN的内存中。

CN在内存中维护了一个最大的Apply的CommitTimestamp，可以根据这个时间戳的水位和事务的SnapshotTimestamp来确保，LogTail的数据对于事务是完整的。

1.6 事务的写操作

MatrixOne 事务的 Uncommitted 的数据，都是写入 Workspace，这个 Workspace 在CN的内存中。

一个事务写入的数据越多，这个Workspace占用的内存越大，知道OOM发生。MatrixOne 为了解决这个问题，对于Workspace的内存大小有一个阈值（默认是1MB），当发现Workspace的内存超过这个阈值，就会把Workspace中的数据写入到对象存储，在Workspace的数据会被替换成对象存储上临时文件名。

事务在没有Commit之前，不会和TN交互，在Commit的时候，会把Workspace的数据发送给TN节点做Commit处理。

2. 事务的正确性问题

2.1 什么是正确性问题

上面的章节我们回顾了事务，现在需要说明一下，什么事事务正确性的问题。在 MatrixOne 的研发过程中遇到事务正确性的BUG主要有以下几种：

RC模式下的Lost Update
悲观事务锁服务失效
Workspace数据问题

这几个问题都会产生事务正确性问题。这些问题，都会产生事务读了错误的数据，或者提交了错误的数据。

2.2 如何测试

MatrixOne 很多的测试，来帮助我们发现这些事务正确问题，这些测试包括：

单元测试
集成测试
PR Merge之前的CI测试
PR Merge之后的性能基准测试
7*24小时执行的稳定性测试
daily的各种测试
chaos 测试

这些测试都会帮助我们发现事务正确性问题。

2.3 常规分析问题的手段

对于研发来说，我们常规的分析问题的手段一半是这几种:

断点Debug
分析日志
Metrics
Tracing

对于分析分布式集群的事务问题，其中最有用的就是日志，其余手段几乎没有用。断点DEBUG只能分析必现的问题，Metrics只能观测到系统的一个大概情况，不能定位数据问题。Tracing一般是指调用链监控，可以用来分析性能问题，但是对于数据错误的问题，无法提供帮助。

总结来看，分析正确性问题几乎只有日志可用。

2.3.1 需要哪些日志

事务正确性问题，归根结底是对于一行记录，读到了错误的数据或者写入错误的数据。这个问题的本身，是数据的内容错了。数据的内容错了，问题可能出现在这行数据所有发生读写的地方。

如果我们需要分析事务正确性问题，那么就需要分析问题出在哪一个事务发生读写的地方。并且还有一个条件，就是能够根据出问题的事务，出问题的行，把这些地方的日志信息全部串联起来，就可以找到问题所在。

但是问题是复杂的，由于悲观事务的模式，多个并发事务会相互影响，所以还需要串联起来有冲突的事务的所有相关信息一起分析。

2.3.2 日志的问题

我们分析问题需要那些信息，上文我们分析了，这些信息需要都记录到日志中。这些日志不可能运行在Info的日志级别，只能在DEBUG级别。这样就带来了一些问题：

在一些测试中无法打开DEBUG级别的日志
在性能测试中，是无法打开DEBUG日志的。如果错误出现在性能测试中出现，几乎无法分析。
DEBUG日志难以重现问题
事务正确性问题，有时候非常难以重现，可能需要满足特定的并发时序。如果是在不能打开DEBUG的测试中出现，需要打开DEBUG日志级别，跑一样的负载，DEBUG日志过多，改变了系统运行的时序，问题会更加难以复现。
日志难以分析
当具备完备的DEBUG的日志的时候，这个日志的规模可能非常非常大，并且是一个在分布式环境中，产生的各自节点和进程的日志，分析的难度也是异常艰难的。

3. 如何高效DEBUG

在 MatrixOne 的研发过程中，Fix 事务正确性的BUG，一直是痛苦的经历。MatrixOne 还处于快速发展阶段，系统中有非常多的优化还没有去处理，这些修改，都有可能带来新的事务正确性的BUG。所以我们需要一个高效DEBUG事务正确性BUG的工具和方法。

3.1 设计目标

使用日志去分析的问题弊端，我们已经有扩深刻的经历。现在需要达成的设计目标有3点：

在任何测试场景中，只要出现BUG，不需要重新复现，就有足够的信息分析问题
不能对于性能测试有太大的影响，10%以内的性能影响是可以接受的
要提供非常丰富的分析信息的方式和手段

3.2 设计挑战

在测试中会产生非常巨大的需要分析的数据。这些数据如何存储，如何提供丰富的分析查询能力。因为分析问题的时候，需要根据各种各样的条件去分析查询信息。

3.2.1 如何提供分析查询能力

首先我们不考虑数据如何存储，先来看如何提供数据查询分析能力，解决了这个问题，可能数据如何存储的问题就解决了。

目前为止，没有比以SQL的方式来提供这些数据的查询更方便的，语意更丰富能力的分析查询方式了。如果我们可以提供一SQL的方式来提供DEBUG数据的分析查询能力，这个好处是显而易见的，并且DEBUG的效率也是提升巨大的。

所以我们决定以SQL的方式提供DEBUG数据的查询分析。

3.2.2 数据如何存储

存储方式就显而易见了，因为提供SQL的方式来提供查询能力，那么数据就需要存储的数据库中。所以我们需要一个能够提供强大AP能力的数据库来存储这些DEBUG数据。

结论显而易见了，MatrixOne 自己就是一个支持高性能AP查询的数据库。

3.2.3 数据如何写入

我们有一个设计目标是，开启收集DEBUG信息的时候，对于性能不能有超过10%的性能影响。我们需要对数据写入到数据库有一些特殊的设计：

异步以Load的方式写入数据到数据库
DEBUG数据的写入可以skip掉事务中一些耗时的操作（去重，冲突检测）
尽可能的减少不必要的信息

3.3 Trace框架设计

从 MatrixOne 1.2版本开始，MatrixOne 提供一个mo_debug的内置数据库，并且根据之前分析日志的经验，对分析事务问题需要的数据进行了抽象，提供了一些表来存储数据。

并且提供了一些专门的语句来动态的打开和关闭Trace的功能。

由于篇幅问题，本文不会描述这些表的具体设计含义，只会简单介绍一下，主要目的还是给分享一下思路。

3.3.1 数据表

create table trace_event_txn (
    ts                   bigint       not null,
    txn_id            varchar(50)  not null,
    cn                varchar(100) not null,
    event_type        varchar(50)  not null,
    txn_status          varchar(10),
    snapshot_ts       varchar(50),
    commit_ts         varchar(50),
    info              varchar(1000)
)

create table trace_event_data (
    ts                   bigint          not null,
    cn                varchar(100)    not null,
    event_type        varchar(50)     not null,
    entry_type          varchar(50)     not null,
    table_id           bigint UNSIGNED not null,
    txn_id            varchar(50),
    row_data          varchar(500)    not null, 
    committed_ts      varchar(50),
    snapshot_ts       varchar(50)
)

create table trace_event_txn_action (
    ts                   bigint          not null,
    txn_id            varchar(50)     not null,
    cn                varchar(50)     not null,
    table_id          bigint UNSIGNED,
    action            varchar(100)    not null,
    action_sequence   bigint UNSIGNED not null,
    value             bigint,
    unit              varchar(10),
    err               varchar(100) 
)

create table trace_event_error (
    ts                   bigint          not null,
    txn_id            varchar(50)     not null,
    error_info        varchar(1000)   not null
)

create table trace_statement (
    ts            bigint          not null,
    txn_id     varchar(50)     not null,
    sql        varchar(1000)   not null,
    cost_us    bigint          not null 
)

这些数据表主要记录了，在执行过程中所有数据发生的写入，读取，以及事务的元数据变更，执行的SQL，并发冲突等等关键信息。

3.3.2 Filter表

create table trace_table_filters (
    id              bigint UNSIGNED primary key auto_increment,
    table_id        bigint UNSIGNED not null,
    table_name      varchar(50)     not null,
    columns         varchar(200)
);

create table trace_txn_filters (
    id             bigint UNSIGNED primary key auto_increment,
    method         varchar(50)     not null,
    value          varchar(500)    not null
);

create table trace_statement_filters (
    id             bigint UNSIGNED primary key auto_increment,
    method         varchar(50)     not null,
    value          varchar(500)    not null
);

这些Filter表，用来做过滤，尽可能的减少需要记录的数据量。

3.4 效果

打开Trace后，对于性能的影响在5%左右。依靠 MatrixOne 提供能的高性能的AP查询服务能力，研发人员可以根据SQL来查询DEBUG问题，查询执行期间所有需要的数据变更，事务元数据变更等等所有的对于DEBUG问题有帮助的信息。

这样极大的提高了效率，提升了 FIX 事务正确性的BUG的速度。

About MatrixOne

MatrixOne 是一款基于云原生技术，可同时在公有云和私有云部署的多模数据库。该产品使用存算分离、读写分离、冷热分离的原创技术架构，能够在一套存储和计算系统下同时支持事务、分析、流、时序和向量等多种负载，并能够实时、按需的隔离或共享存储和计算资源。云原生数据库MatrixOne能够帮助用户大幅简化日益复杂的IT架构，提供极简、极灵活、高性价比和高性能的数据服务。

MatrixOne企业版和MatrixOne云服务自发布以来，已经在互联网、金融、能源、制造、教育、医疗等多个行业得到应用。得益于其独特的架构设计，用户可以降低多达70%的硬件和运维成本，增加3-5倍的开发效率，同时更加灵活的响应市场需求变化和更加高效的抓住创新机会。在相同硬件投入时，MatrixOne可获得数倍以上的性能提升。

关键词：超融合数据库、多模数据库、云原生数据库、国产数据库。

MO干货 | 高效DEBUG事务正确性BUG