PXC架构理论解析(三)——集群节点同步

PXC架构理论解析(三)——集群节点同步

我们前面通过搭建实验和参数解释大概解释了一下PXC的工作原理,我们这里在细化的说一下PXC集群同步。

此图出自运维内参

一. Galera的事务处理

我们在之前的《PXC架构理论解析(一)——Galera接口》当中有过一些介绍,Galera不参与数据库的复制同步,它只是在中间协调配合事务,将各个节点构成联系。在Galera当中所处理的最重要的一个就是验证,在每个节点之间传送是以写集为单位,验证每个节点的写集会不会冲突,这个功能就是由wsrep_pre_commit进行操作的。而写集的组成是由galera_append_key和galera_append_data接口执行的,galera_append_key将当前事务影响的行的KEY(主键+数据)+数据库名+影响行所在的表名组成一个写集KEY,每个受影响的行都会生成一个写集key。当一个事务结束后,另外一个接口galera_append_data,将当前事务产生的所有binlog都添加到当前事务的DATA集合中(DATA其实就是binlog),然后将KEY和binlog一一对应,现在的KEYS+DATA就是一个写集(write_Set)。

此图出自运维内参

在得到写集之后galera_pre_commit就进行他的两项工作:1.向其他节点replicate 写集(KEYS+DATA)2.进行验证

现在写集被传送到了各个节点,各个节点会去做复制和验证,复制我们后面说,先说验证:

验证工作其实就 是本地验证,每个节点验证当前节点传来的写集或者是本节产生的写集(我们叫做WN,这个是我自己起的)等待提交的写集(我们叫做WW,这个也是我自己起的)之间的事务验证,WN去和在缓存中的所有WW进行验证对比,如果同时满足下面三点,验证失败:

两个事务的来源不是一个节点提供。

两个事务包含相同的key(同一个行的主键+数据)。

之前的事务没有提交。

此图出自运维内参

如果验证失败,有两条路可以选择:

1.再次尝试

2.GTID大的事务调用接口wsrep_abort_pre_commit,停止事务commit,如果这个这个事务已经验证,那么将这个事务回滚。因为之前已经将写集进行发送,所以通过接口galera_replay_trx,模拟一个从节点,将这些信息APPLY。

二.Galera的消息传送(replicate)

我们在上面提到PXC在节点之间传递同步事务的时候是以写集为单位,我们知道galera_pre_commit所做的是两个操作,其中一项就是replicate数据向所有节点。运维内参当中介绍到PXC有五层,这五层的关系保证了数据之间的同步互传同步,我们先看下这个架构图。

Mysql层:MYSQL服务层 ,这一层也就是PXC的表面层,这里保证数据库之间是muliti-master多主的架构。

Galera层:galera通过一些回调函数将数据库集群的数据进行传输同步,并且将数据保证一致。

GCS层:group communacation system ,目的是操作逻辑处理部分,发送线程包括数据分片,数据分发,下层传送。接受线程包括接收,组装,通知worker线程或者丢弃。

Backend层:后端抽象层,为GCS层提供统一的接收发送接口。

GCOMM:真正接受和发送数据的地方。

Galera在处理事务写集的时候,GCS层判断事务包大小,以64k为节点,超过会切片分发,在backend层将GCOMM层接口封装,GCOMM将会给自己节点和其他节点进行分发,我们之前也说过这个。其会等待自己给自己发来的这个信息,本机在收到这个消息之后产生序列号,其实就是一个GTID。等待这个GTID收到之后就会认为其他节点也收到对应信息了。

针对于其他的节点来说,在backend层的接口backend_recv接受GCOMM传来的事务节点发来的数据,将所有的分片在这里组装,将组装玩的数据包传递给mysql层(pxc层),进行Galera_recv和process_trx,先做验证,之后通过获取binlog和这个数据包,通过wsrep_apply_cb,将写集复制到其他节点。

THAT'S ALL

BY CUI PEACE!!!!!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180524G1GAIV00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券