doc: 阅读mysql group replication文档
This commit is contained in:
@@ -50,4 +50,33 @@ source将会应用事务,并对事务进行提交。之后,事务会异步
|
|||||||
### group replication
|
### group replication
|
||||||
group replication是一种用于实现fault-tolerant系统的技术。replication group是一系列servers的集合,其中每个server都含有数据的完整副本,servers之间通过message进行交互。
|
group replication是一种用于实现fault-tolerant系统的技术。replication group是一系列servers的集合,其中每个server都含有数据的完整副本,servers之间通过message进行交互。
|
||||||
|
|
||||||
group中的communication layer提供了一系列保证,例如atomic message和total order message delivery。
|
group中的communication layer提供了一系列保证,例如atomic message和total order message delivery。
|
||||||
|
|
||||||
|
Mysql Group Replication基于这些特性、抽象,实现了`multi-source update everywhere replication protocol`。一个replication group由多个server组成,每个server在每时每刻都独立的执行事务。
|
||||||
|
- read/write事务都只在其被group同意之后才提交;即对于read/write事务,都要由整个group决定其是否能被提交,故而提交操作并不是由源服务器单方面决定的。(read/write transaction代表事务中包含写操作的事务)。
|
||||||
|
- read-only事务则是不需要group内其他server的协助,立刻就能提交
|
||||||
|
|
||||||
|
当`read/write`事务准备好在源server上提交时,都会原子性的广播`write values`和`write set`:
|
||||||
|
- write values:代表被修改后的整行数据
|
||||||
|
- write set:被修改数据的唯一标识符
|
||||||
|
|
||||||
|
由于transaction是被原子广播的,故而,要么`group中所有servers都接收到该事务`,要么`group中所有servers都未收到该事务`。并且,`对于所有servers,其接收到的所有事务都相同,并且所有事务按照相同的顺序被接收`,并且,会为所有事务建立一个`global total order`。
|
||||||
|
|
||||||
|
但是,事务在不同的servers上并行执行时,可能会发生冲突。在被称为`certification`的过程中,该冲突通过查看和比较两个不同并行事务的write sets来检测。在certification的过程中,冲突检测在行级别执行:如果两个并行的事务在不同的servers上执行,并且修改了相同的行,那么这将会存在冲突。
|
||||||
|
|
||||||
|
该冲突将会按照如下方案被解决:对于在global total order中排序靠前的事务,其将会在所有server上被提交;而排序靠后的事务则是会终止,在源服务器上被提交,并且被group中的其他servers丢弃。
|
||||||
|
|
||||||
|
例如,t1和t2在不同的servers上并发执行,两者都修改了同一行,t2的排序在t1之前,那么在冲突中t2将会获胜而t1会回滚。上述规则则是分布式的`first commit wins rule`。
|
||||||
|
|
||||||
|
> 如果两个事务发生冲突的可能性高于不冲突的可能性,那么最好让其在相同的server上执行,并且通过server的local lock机制来对事务进行同步;而不是在不同的server上执行,并因certification造成回滚。
|
||||||
|
|
||||||
|
对于已经被认证的事务进行`applying`和`externalizing`,group replicaion允许server`在不破坏一致性和有效性的前提下`偏离`agreed order of the transactions`。`group replication`是一个最终一致性的系统,代表incoming traffic降低或停止时,所有的group members都将包含相同的data content。当traffic较高时,事务可以以稍微不同的顺序进行externalizing,并且,事务在进行externalizing时,在一些servers进行externalizing的时机也可能早于其他servers。(`externalizing`指的即是实际提交事务并使事务的修改对client可见;`applying`指的是server应用来自其他server的事务修改)。
|
||||||
|
|
||||||
|
例如,在mulit-primary模式下,一个本地事务可能在certification之后立马就被externalized,即使一个来自remote server的transaction在global order中顺序更靠前并且尚未被applied。当certification过程中,多个transactions间不涉及冲突时,该操作是被允许的。
|
||||||
|
|
||||||
|
在single-primary模式下,在primary server上,可能小概率会发生`并发、非冲突的本地事务按照和global order agreed by group replication的顺序进行提交和externalized`。
|
||||||
|
|
||||||
|
在不接受来自客户端写入操作的secondaries节点上,事务总是按照agreed order被提交和externalized。
|
||||||
|
|
||||||
|
具体mysql group replication protocol的示意图如下所示:
|
||||||
|
<img src="https://dev.mysql.com/doc/refman/8.4/en/images/gr-replication-diagram.png" style="width: 100%; max-width: 725px;">
|
||||||
Reference in New Issue
Block a user