Mysql日志分组复制(MGR)要同步哪些信息给从节点?

2020-05-23 00:00:00 更新 事务 节点 冲突 检测

分别是什么?

介绍冲突检测实现原理之前,先介绍一下广播信息 transaction message、冲突检测内存 certification info 的结构组成。

(1) transaction message

如图 8 所示,transaction message 保存是事务 T1 要更新行的的相关信息,有 transaction_context_log_event 和 gtid_log_event 及 log_event_group 三部分组成。

具体组成:

  • write set 叫写入集合,是事务更新行相关信息的 Hash 值。write set=Hash(库名+表名+主键(键)字段信息)
  • gtid_executed 为已经执行过的事务 gtid 集合,也即事务快照版本。
  • 把 write set 和 gtid_executed 打包成为事务上下文信息,transaction_context_log_event。
  • gtid_log_event为已经执行过的事务 gtid 集合。
  • log_event_group 为事务日志信息,后续要更新到 relay log 中。
  • 把 3 和 4 和 5 一起打包成为 transaction message 广播给其它节点。



图 8:广播信息的内容结构

(2) certification info

广播的信息到达冲突检测模块 certification 之后是如何工作?

每个节点都有一个 certification info 的内存结构,certification info 保存了通过冲突检测的事务的 write set 和 gtid_executed。

certification info 相当于一个 map,key 是 string 结构,保存 write set 中提取的主键值;value 是 set 集合,保存 gtid_executed 事务快照版本。

例如 T1 事务,T1 更新数据库 d1 中的表 t1 中两行数据 id=1 和 id=2,它对应快照版本 UUID_MGR 是 :1-100,刚开始 certification info 为空,所以直接提交,之后 certification info 中快照版本直接更新为 1-101。



图 9:certification info 结构图

6. 冲突检测核心机制!敲黑板!

通过上面的例子可知通过冲突检测标准:若 transaction UUID_MGR ">="certification info UUID_MGR,则冲突检测通过。



图 10:冲突检测事务执行举例

根据上述标准举例,事务 T2,更新 id=2 的行,事务 T2 的 UUID_MGR 为 1-102,节点中冲突检测模块中的 certification info 中的 UUID_MGR 为 1-101,这里 T2:UUID_MGR:1-102>UUID_MGR:1-100,则 T2 冲突检测通过。

反之,事务 T3,更新 id=1 的行,事务 T3 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中的 UUID_MGR 为 1-101,很明显 T3:UUID_MGR:1-100

上面是针对于单独一个写来进行判断,现在我们来展示一下多节点模式中,多个事务同时写入时冲突检测机制。

如下图所示,三个事务 T4、T5、T6 并行写入某个 MySQL 节点,通过了 Paxos 协议模块达成一致性共识,进行冲突检测时遵循下面三个原则:

  • 多个事务修改同一个 id 对应的数值,需要按照先后顺序进行冲突检测。
  • 多个事务同时对不同的 id 进行修改,各自进行修改即可。
  • 不同的事务对同一个 id 修改,需要按照先后顺序进行冲突检测即。



图 11:多事务同时写入示意图

如图 11 所示,事务 T4 和事务 T5 同时更新 id=1 的行,按照先来后到顺序进行冲突检测,T4 先到先进行冲突检测。

  • 事务 T4,更新 id=1 的行,事务 T4 的 UUID_MGR 为 1-102,节点中冲突检测模块中的 certification info 中 id=1 的 UUID_MGR 为 1-101,很明显 T2:UUID_MGR:1-102>UUID_MGR:1-101,则 T4 冲突检测通过,更新为 certification info 中 UUID_MGR 为 1-103。
  • 事务 T5,更新 id=1 的行,事务 T5 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中 id=1 的 UUID_MGR 为 1-102,其中 T5:UUID_MGR:1-100>UUID_MGR:1-102,则 T5 冲突检测不通过。
  • 事务 T6,更新 id=3 的行,事务 T6 的 UUID_MGR 为 1-100, 节点中冲突检测模块中的 certification info 中 id=3 的 UUID_MGR 为空,其中 T6:UUID_MGR:1-100>UUID_MGR,则 T6 冲突检测通过,更新为 certification info 中 UUID_MGR 为 1-101。

如下图 12 所示,事务 T4 和事务 T5 并行修改 id=1,T4 写入成功,T5 丢弃,T6 写入 id=3 事务,写入成功。



图 12:多事务同时写入结果图

随着 write set 不断写入 certification info 中,内存消耗会相应增大,MGR 有配套的 write set 清理线程,每隔一段时间去清理已经在节点应用或者回放的事务的 write set 信息。

相关文章