Further to our earlier blog post about Fail-safe enhancements to Group Replication, where we discussed enhancements against data modification in members which are not ONLINE, we now present here additional changes to protect data from being accidentally modified by asynchronous replication channels. Asynchronous replication is one of the pillars of MySQL and widely used with MySQL databases. They are also widely used across Group Replication clusters to scale out the reads by connecting asynchronous read slaves to a group and to bind groups together with circular replication for the wide area clusters.

We have provided the following enhancements to protect Group Replication members from receiving unwanted data from asynchronous replication channels:

Preventing involuntary asynchronous updates through secondary members

Let’s take as an example a setup where single-primary Group Replication (primary member P and secondary members S1 and S2 forming a group) is combined with asynchronous replication (M and S2 acting as master and slave), where S2 acts as both secondary server in the group and slave in the asynchronous replication. In a Single-primary mode secondary members are set to read-only mode (with super-read-only=ON ), so that they process only retrievals and blocks updates; all writes are done in the primary that handles the request concurrency. But enabling read-only mode does not prohibit asynchronous replication to update data on secondary members. The secondary member S2 was accepting transactions from M through asynchronous replication which were then propagated to the group.

This enhancement prevents secondary members of a single-primary group from creating an asynchronous replication channels. It also prevents Group Replication to be started on the secondary member when asynchronous replication is already running.

This enhancement is fixed for BUG#85047 and added to MySQL 8.0.2 and MySQL 5.7.19 release.

Enforce Group Replication requirements on incoming transactions through asynchronous channels

On a member which had both Group Replication and asynchronous replication running simultaneously, asynchronous replication was not respecting following restrictions required by the Group Replication:

1. operations on a table without Primary Key are not allowed when running Group Replication.
2. only operations on table with Innodb storage engine are supported with Group Replication.
3. If a table has foreign key with a CASCADE clause, then operations on such table are not allowed in Group Replication multi-primary mode.

This was also not respected when using mysqlbinlog tool against a group member.

Now after this enhancement, data on members running both Group Replication and asynchronous replication, do fulfill Group Replication requirements. If any asynchronous replication channel tries to apply data that does not observe these requirements, it is immediately stopped with an error.

This enhancement is fixed for BUG#85164 and added to MySQL 8.0.3 release.

Stopping Group Replication also stops other replication channels

When a primary member also running asynchronous replication was stopped, these channels were not getting stopped and kept on applying data changes. Even the super_read_only mode which gets activated on group replication stop was not stopping asynchronous channels from applying data changes. This meant that changes could be made locally on the member, and the asynchronous replication channels had to be stopped manually.

Now after this enhancement when the Group Replication stops by executing STOP GROUP_REPLICATION command or due to an error, all the asynchronous replication channels are also stopped.

This enhancement is fixed for BUG#86222 and added to MySQL 8.0.4 and MySQL 5.7.20 release.

Improved coordination between Group Replication and other replication channels on server start

On a member which had both Group and asynchronous replication started on-boot, the asynchronous replication channels can start adding data before Group Replication starts and the member becomes ONLINE, which can create issues when this member tries to join the group.

The following changes were made in this enhancement:

1. We delayed the start of asynchronous replication channels, when member is a non-bootstrap member (the member that is not in charge of starting the group) and Group Replication is started on-boot, until member is in ONLINE status.
2. While waiting for the Group Replication member to become ONLINE, if the Group Replication fails to start then asynchronous replication channels also fail to start with an error, so that local changes are not added to this member.
3. In the Secondary member when the Group Replication and asynchronous replication channel are started on-boot, the Group Replication will start successfully and asynchronous channels fail with an error. Earlier before this enhancement Group Replication was getting into OFFLINE status and asynchronous channels were getting started successfully.

This enhancement is fixed for BUG#87474 and added to MySQL 8.0.11 release.

Conclusion

Please try these enhancements and let us know your feedback, so that we can keep improving Group Replication!

Thanks for using MySQL Group Replication!