MySQL Bugs: #84795: STOP GROUP_REPLICATION sets super_read

Bug #84795	STOP GROUP_REPLICATION sets super_read_only=off
Submitted:	2 Feb 2017 13:44	Modified:	29 Jun 2017 20:01
Reporter:	Kenny Gryp	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Group Replication	Severity:	S3 (Non-critical)
Version:	5.7.17	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
STOP GROUP_REPLICATION resets super_read_only.

How to repeat:
mysql
mysql> start group_replication;
Query OK, 0 rows affected (1.01 sec)

mysql> select @@global.super_read_only;
+--------------------------+
| @@global.super_read_only |
+--------------------------+
|                        1 |
+--------------------------+
1 row in set (0.00 sec)

mysql> stop group_replication;
Query OK, 0 rows affected (35.05 sec)

mysql> select @@global.super_read_only;
+--------------------------+
| @@global.super_read_only |
+--------------------------+
|                        0 |
+--------------------------+
1 row in set (0.00 sec)

Suggested fix:
Please care about my data, make sure I don't get a split brain! do not put super_read_only=off when stopping group replication!

Hello Kenny,

Thank you for the report.

Thanks,
Umesh

Posted by developer:
 
Hi Kenny,

Thank you for evaluating Group Replication, your (and all community) feedback is important!

We are working on this one.

Best regards,
Nuno Carvalho

Hello.
Not sure that is the same bug, but my problem is similar.
Mysql 5.7.17
MysqlRouter 2.1.3
Debian 8.5
Kernel 3.16.0-4-amd64

I configured 3 nodes in 3 different machines. Everything works fine connected in Mysql Workbench, 1 Primary and 2 secondary.

If command STOP GROUP_REPLICATION, the MySQL Workbench still keep connected in this machine like a master. Other new clients connect in the new master defined by MySQL Router, but the current connection keep updating data (split-brain).

Posted by developer:
 
Thank you for your feedback, this has been fixed in upcoming versions and the following was added to the 8.0.2 change log:
In previous versions issuing STOP GROUP_REPLICATION stopped the plugin but there was a period during this process when the server still accepted transactions. This meant the transactions were not transmitted to the group, and if the plugin failed to stop correctly further transactions were accepted. To make STOP GROUP_REPLICATION safer, now super_read_only is set to ON immediately upon issuing STOP GROUP_REPLICATION, which ensures no transactions are accepted.

Hi everyone.

I installed Mysql 5.7.19, but the bug persists.
I set up 3 instances in 3 different servers.
On the R/W server, I issued STOP GROUP_REPLICATION. The expected result for variable SUPER_READ_ONLY=YES, but the server keep the value in OFF. At. this moment I 1 machine writing and not sync with cluster.

Hi all,

This fix was added to 5.7.20.

Best regards,
Nuno Carvalho