Support For IPv6 And For Mixed IPv6 And IPv4 Groups Recall that the system is blocked and the current configuration is the following (as perceived by the local failure detector on s1): mysql>  SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members; +--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE | | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE | | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE | | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE | | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE | +--------------------------------------+--------------+ The first thing to do is to check what is the local address (group communication identifier) for s1 and s2. Log in to s1 and s2 and get that information as follows. mysql>  SELECT @@group_replication_local_address; mysql>  SET GLOBAL group_replication_force_members=" 127.0.0.1:10000,127.0.0.1:10001"; Once you know the group communication addresses of s1 ( 127.0.0.1:10000 ) and s2 ( 127.0.0.1:10001 ), you can use that on one of the two servers to inject a new membership configuration, thus overriding the existing one that has lost quorum. To do that on s1: And then on s2. mysql>  SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members; +--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE | | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE | +--------------------------------------+--------------+ This unblocks the group by forcing a different configuration. Check  replication_group_members  on both s1 and s2 to verify the group membership after this change. First on s1. mysql>  SELECT * FROM performance_schema.replication_group_members; +--------------------------------------+--------------+ | MEMBER_ID | MEMBER_STATE | +--------------------------------------+--------------+ | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE | | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE | +--------------------------------------+--------------+ When forcing a new membership configuration, make sure that any servers are going to be forced out of the group are indeed stopped. In the scenario depicted above, if s3, s4 and s5 are not really unreachable but instead are online, they may have formed their own functional partition (they are 3 out of 5, hence they have the majority). In that case, forcing a group membership list with s1 and s2 could create an artificial split-brain situation. Therefore it is important before forcing a new membership configuration to ensure that the servers to be excluded are indeed shut down and if they are not, shut them down before proceeding. After you have used the  group_replication_force_members  system variable to successfully force a new group membership and unblock the group, ensure that you clear the system variable.  group_replication_force_members  must be empty in order to issue a  START GROUP_REPLICATION  statement. 3756 18.5.5 Support For IPv6 And For Mixed IPv6 And IPv4 Groups