浅析MySQL 5.7组复制技术（Group Replication）

 

    Group Replication is know as an up to date HA(High Availablity) solution which is supported in official version of MySQL 5.7 since Dec. 2016.It's similar with the other two tools —— MHA(By Yoshinorim) & PXC(By Percona),but not as same as them. Group Replication(I'll call it MGR later) provides features below:

 

• high consistency
  

 

    MGR protocol lies on the algorithm of Paxos(Which is a kind of consensus protocol usually be used in distributed system and presented by Mr.Lamport.) to guarantee data consistency.What's Paxos?There's something about it below:

    theory of Paxos: http://www.the-paper-trail.org/post/2009-02-03-consensus-protocols-paxos/

    Mr Lamport's introduction on wiki: https://en.wikipedia.org/wiki/Leslie_Lamport

    MGR provides a built-in membership 

service which can strongly coordinate the servers in the same group to do switchover between master and slave automatically with high efficiency and strong consistency.All members in the same group will communicate with each other from time to time by GSC protocols.The group members always come up to an agreement in an order of global transaction sequence in order to decide whether to commit or abort transactions when commit operations happen.

 

• high flexibility
  

    

    MGR supports both single-primary and multi-primary mode.In the single-primary mode,there's a machenism called "primary election" automatically while failure is detected and only the primary server can update data simultanuously.In the multi-primary mode,update can be done on all the servers in the group even though they update data concurrently.You can choose the appropriate way to implement your MySQL Servers.

 

• high fault-tolerance
  

    

   Only if most of your servers crash,the service will continuously proceed.There's an "failure detector" machenism when fault occurs or the servers in group don't get privilege to update data.that also prevents "brain-split" when one member cannot communicate with others in the same group(Which usually caused by network failure or something else). it's recommended to implement MGR with three server at least,as the number of tolerance depend on the formula:n=2*f+1.For instance,there's five members in the MGR group,so the tolerance is two.

 

• high scalability

      One server in group can be replicated from another one automatically until it become equal when adding or removing it.MGR will maintain a view which contains informations about these group members if they changes,All the members join or leave the group voluntarilly or not will dynamically reconfigure the view.

       

    In order to distinguish MGR and traditional replication technology,let's see the pictures below:

 

Asynchronous Replication:

Semisynchronous Replication(after_sync):

    From the above two pictures,we can see that there's no HA function in the master-slave traditional replication(both asyn mode and semisync mode).whenever the master crashes,the service won't be available anymore.

    In most scenarios,master has one or more slaves.Commits of transactions take place merely on the master.Binlogs are transited(asynchronously).Each server has a full copy of data 'cause it shares nothing here.

Group Replication(multi-primary):

 

    Above is the multi-primary mode of MGR,There're something diffrerent such as "certify" and "consensus" in the picture.The consensus based on paxos make sure the consistencies between the masters.but it's still a shared-nothing replication the same as the classical replication. 

    Notice,in multi-primary mode,all ther masters can execute transactions and commit independently,if there's a confilct(which always happens in the certification procedure),for example,they want to update the same row of one table,only one master who has the earlier golobal transaction sequence will get the privilege to finish the operation(what seems like first commit win principle).

 

Summary:

• Be compared with MHA & PXC,MGR is the newest supplement in MySQL high availability family.
• There're still few case using MGR to implement in product system nowadays.
• MySQL Servers don't need to failover but the application does.
• The practical usage of MGR is together with some middleware product such as ProxySQL.