Group Replication — an Overview

Within the MySQL team, we’re extremely excited about Group Replication! More and more of our users are also starting to become aware of this exciting feature–which offers native synchronous replication with support for multi-master or active/active update-anywhere replication clusters. Our developers and users alike are eager to see easy, native HA come to MySQL!

Moving beyond the general descriptions of Group Replication, however, many people wonder about how things will work, look, and feel. So I wanted to share a presentation that offers a quick general overview of the new feature. This presentation is based on Tiago’s recent presentation given at FOSDEM (Tiago is one of the leading developers on the MySQL GCS or Group Communication System):

If you’re interested in more details, I would encourage you to check out the other blog posts that go into greater detail:

Please let us know your thoughts! Any feedback is very valuable to us. You can reach out to me via the comments here or directly via Twitter or email. I’d love to discuss your use cases and feature requests. If you encounter anything that you feel is a bug, it would be extremely helpful if you can file a bug report for us to properly track and address.

As always, THANK YOU for using MySQL! I look forward to getting your feedback.

7 thoughts on “Group Replication — an Overview

  1. For group replication,can following scenario happen?

    session A updates a row and commits it in server S1,the update is queued in S2 but not applied.

    session B in S2 needs to read the row and update another table row based on what it reads.

    since the update session A made is not applied in S2,session B will update another table row with wrong values,am I right?

    thanks

    1. Hi Gavin,

      Yes, write skew is a problem. It’s a problem that exists within a single server as well, when using snapshot isolation. The issue is that write/write conflict detection is used rather than read/write conflict detection (which serializable will also do).

      It’s an interesting problem that we’d definitely like to try and address after 1.0. There’s a lot of interesting academic work happening around this subject.

      Thanks!

  2. what did you mean when you said snapshot isolation,is it read committed?
    I think for my above scenario,in a single server,no issues if we use read committed.because if the previous update gets committed,the data which will be read is the committed data,which is the right data we want,so no issues,am I right?

    thanks

    1. Hi Gavin,

      You can see a basic description here:
      https://github.com/aphyr/distsys-class#acid-isolation-levels

      And additional info here (including discussions of the “write skew” anomaly that you described):
      http://sqlperformance.com/2014/06/sql-performance/the-snapshot-isolation-level
      https://en.wikipedia.org/wiki/Snapshot_isolation

      You can’t really use read-committed across a group replication cluster. You can use read-committed on each node for the optimistic execution, but the consistency guarantees are not honored during the group consensus at commit time.

      Best Regards

      1. thanks Matt for your responses.

        Another question:

        can group replication support foreign key and unique index?

        thanks

        1. Hi Gavin,

          Unique keys are not a problem. The write set certification will detect unique key conflicts and properly enforce those constraints at commit time (using a first committer wins policy). Foreign key support is, however, limited. The issue is with multiple levels of FKs, for example, chained ON DELETE CASCADE relationships. This poses problems because in MySQL 5.7 there’s not currently FK support at the SQL layer; it’s handled entirely within the InnoDB storage engine. The situation should improve with the new global Data Dictionary, as we can then properly walk a dependency tree for foreign keys. Building on that, we can add some FK intelligence into the SQL layer above the storage engine. Finally, we can then build upon all of that to improve the write set certification process in Group Replication to properly detect and handle multiple level FK conflicts. You can read more about the new Data Dictionary here:
          http://mysqlserverteam.com/category/dictionary/

          Thanks for the great questions! :)

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter. *