【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
oblogproxy v2.0.1
【 使用版本 】
【问题描述】清晰明确描述问题
关于GtidLogEvent的生成
/*
+======================================+
| fixed | commit_flag 0 : 1 | 事务是否提交
| part +----------------------------+
| | gtid_uuid 1 : 16 | GTID中的uuid,2个uuid字符占一个字节（不包含'-'）
| +----------------------------+
| | gtid_txn_id 17 : 8 | GTID中的事务号
| | ts_type 25 : 1 | 逻辑时间类型
| | last_committed 26 : 8 | 逻辑时间s
| | sequence_number 34 : 8 | 以微秒为逻辑时间的sequence number
+======================================+
| variable| check_sum | 校验和，4字节
| part | |
+======================================+
*/
对应的代码部分
// set common _header
uint32_t event_len = COMMON_HEADER_LENGTH + GTID_HEADER_LEN + gtid_log_event->get_checksum_len();
auto* common_header =
new OblogEventHeader(GTID_LOG_EVENT, get_timestamp_sec(record), event_len, this->_cur_pos + event_len);
gtid_log_event->set_header(common_header);
gtid_log_event->set_ob_txn(get_transaction_id(record));
gtid_log_event->set_checkpoint(get_checkpoint_usec(record));
gtid_log_event->set_last_committed(record->getTimestamp());
gtid_log_event->set_sequence_number(record->getRecordUsec());
这里设置last_committed和sequence_number都是时间戳的意义是什么，根据我的了解，这两个参数主要用的从库的并行复制， 基于Lock-Based方案的话，能够并行复制的话，last_committed和sequence_number承担了locking interval的区间，能够并行复制的话应该满足条件：如果所有正在执行的事务的最小的sequence_number大于一个事务的transaction.last_committed，那么这个事务就可以并发执行
从结果来看设置的两个结果如下，并没有该作用，所以想要了解下这两个参数设置时间戳的意义
#240401 7:24:33 server id 100 end_log_pos 197 GTID last_committed=1711956273 sequence_number=433302 rbr_only=yes