Hi everyone, its been a while since the last release of Group Replication. During this period we have been working hard to improve the plugin and give you a better user experience. Focused on solving several existing bugs, address performance issues and improving user
experience we renamed some variables, introduced new ones and changed some of the plugin policies.

We now present the gist of the changes for MySQL Group Replication for 5.7.14

Variable renames

Introduced in the last release, the group_replication_peer_addresses option is now named:

•   group_replication_group_seeds

We found the old name to be misleading, often inducing the users into thinking this was a fixed list of members that a member knows and talks to while in the group, or a list of donors to be used.
None of that is true, the user should see this option like a set of members in the group for whom a new member can ask for the current status in order to join. The only requirement is that this list contains at least one alive member that is in the group you want to join.

New Variables

With many improvements on the plugin and its communication layer, we now introduce new variables that came alongside them.

> Plugin related options:

In terms of plugin related options we now have:

•   group_replication_allow_local_disjoint_gtids_join

This variable is an override mechanism for a new security feature in the plugin. When you try to add to the group a server that has more data than the existing members, by default the joining member will be rejected.
The purpose is to avoid possible recovery and run time errors in the plugin leading to data divergence and other issues. If you are sure of what you are doing, and that the extra data is safe, then you can use this option.

Default: False
Possible values: True or False

•   group_replication_gtid_assignment_block_size

GTID related operations were found to be a source of contention in Group Replication scenarios when GTID gaps appeared due to high parallel loads. As such, one decided to add this variable as a performance tuning option
To deal with this issue,  you can define a range value that members will reserve in a deterministic way and from which they will pick GTIDs as needed. When exhausted the members will reserve another range according the current free GTIDs.

Example: a block size of 100 will usually result in a member using GTIDs from 1 to 100 and other member will use from 101 to 200.

Default: 1
Possible values: 1 to 9223372036854775807

> Communication layer related options:

Related to the plugin communication layer, the following queries were added:

•   group_replication_force_members

This option is to be used when you are facing a network partition, causing a group majority loss. Sometimes, members can become unreachable and for that reason you may want to redefine the group only with the remaining healthy members.

Example: You have 7 members, server 1 to server 7. The router that connects server 4 to 7 catches fire and they become unreachable.
While your colleagues clean the mess, you can re-size the group to the three remaining members by doing:

All members that are not present in the new configuration, must be stopped by the user.

Default: “”
Possible values: a coma separated list of members with hostname:port
Example: “hostname1:port1,hostname2:port2”

•   group_replication_ssl_mode

Specifies the security mode of the connection between Group Replication members. This option follows the SSL setting set in the server.
Read more about that here: Configuring MySQL to Use Secure Connections

Default: DISABLED
Possible values: “DISABLED”, “REQUIRED”, “VERIFY_CA”, “VERIFY_IDENTITY”
These options are described here: Server SSL mode

•   group_replication_compression_threshold

With this option, the user can define the value in bytes above which compression is enforced for the messages in the communication layer.
When set to zero, it deactivates compression.

Default: 0
Possible values: 0 to 2147483647

•   group_replication_ip_whitelist

This option can be used to specify which members are allowed to connect to this member. The input takes the form of a comma separated list of IPv4 addresses or subnet CIDR notation. In addition, the user can also set as input the value ‘AUTOMATIC’, in which case active interfaces on the host will be scanned and those with addresses on private subnetworks will be automatically added to the IP whitelist. The address 127.0.0.1 is always added if not specified explicitly in the whitelist.

Default: AUTOMATIC
Possible values:  IPv4 addresses or subnet CIDR notation.
For example: 192.168.1.0/24,10.0.0.1

• group_replication_poll_spin_loops

This is an advanced option to improve the response time of the group communication layer in some cases. In some cases is better to try a set number of times for the communication layer to be free instead of suspending the calling thread.

Default: 0
Possible values: 1 to 4294967295

> Server side options

In the server side we now have:

•   transaction-write-set-extraction

This is not a new variable, but we chose to mention it here because of its new value:

For large data sets, it is safer to use 64 bits algorithms to lower the risk of collisions when identifying which table and column(s) were updated. This algorithm is also faster in most cases.

Changes to defaults

Alongside the variable renames and the new options, we also changed some of the plugin defaults.

•  group_replication_start_on_boot

The start on boot option is now enabled by default meaning that after installing the plugin, when you start a server, Group Replication will also start.

New default: ON

• group_replication_recovery_retry_count

This option had a default value similar to a slave retry count. This value did not make sense in group replication environments however, since after some time, the member maybe be too far behind to recover.

New default: 10 tries

Note that the retry interval is still set to 60 seconds so the member may will only quit after 10 minutes.

• group_replication_recovery_complete_at

This option configures when the plugin declares the member ONLINE at the end of the recovery process. In older versions this was set to “TRANSACTIONS_CERTIFIED”, i.e, the member would be declared ready when it certified all the received data. Now, it is only declared ONLINE when all received data is executed.

New default: TRANSACTION_APPLIED

Security changes in Recovery

In previous versions of Group Replication you could set the user and password in your server settings or configuration file. To avoid this need of having a password exposed in the configuration file, we leveraged the CHANGE MASTER structure and reused it for this purpose.

For that reason we removed:

Now, to configure the user and password that recovery needs to fetch the information from the other members, the admin shall execute a command in the form of:

Note that this comes at a cost, as you cannot configure a server to run group replication when it starts for the first time. You need to start the server, configure the recovery user and password and only then you can make a full use of group_replication_start_on_boot.

Behavioral changes and new features

Introduced to improve the monitoring experience of the user when checking the group’s member status, we now present some of the changes around this area.

The ERROR state

In the past, whenever the plugin encountered an error on recovery or when applying a transaction, its state would go to OFFLINE,  but the plugin would continue running. This often confused users so this behavior was reworked.

When a joining member fails to find a valid donor or the applier fails because of some lost data in some member, the plugin will leave the group, its state will change to ERROR, and the server the server will enable read only mode to prevent further writes

The plugin stays running in read only mode to avoid a false assumption that everything is fine as queries would not fail otherwise.

This state can be queried in:

The UNREACHABLE state

Due to its distributed nature, group replication can be affected by some nasty issues like split brain scenarios. For that reason, as pointed in Matt’s blog post, you should always start a non even number of members.

In these mentioned scenarios, members can sometimes lose communication with one another and get stuck. This phenomenon is due to the nature of consensus, meaning that the communication layer needs to hold a majority in the group to take decisions.
To query that, the user can now use the replication_group_members table. Any member that becomes separated from the group will show all non contactable members as being UNREACHABLE.
Usually, you can check that a member lost its contact from the majority and can no longer execute new transactions when the table shows more than a half of the members shown as UNREACHABLE.

Note that the member itself will never be shown in the state UNREACHABLE when you query its table, as this state only represents the view it has from the group. Also, it is important to point that this is a local mechanism and as so, members might display different values, according to the partition side where they.

Example: If a member losses contact with the other two members in a group of three, its state will be:

Conclusion

With this collection  of changes we hope to give you a better user experience with Group Replication.

If you encounter any issues with the release, I would encourage you to file a bug report or open a support ticket. Your feedback is really critical to myself and the rest of the team as we work on Group Replication!