Bug #87834 node joins group even though it is not whitelisted on one of the group member
Submitted: 22 Sep 2017 8:00 Modified: 21 Feb 2018 16:01
Reporter: Dhruthi Komarlu Vasudeva Murthy Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Group Replication Severity:S3 (Non-critical)
Version:5.7.21 OS:Any
Assigned to: CPU Architecture:Any

[22 Sep 2017 8:00] Dhruthi Komarlu Vasudeva Murthy
Description:
Even though new node is not whitelisted on a group member it joins the group.
Consider a scenario with 3 nodes N1, N2, N3.
case 1>
1. N1 has whitelisted N2.
2. N2 has whitelisted N1, N3.
3. start and bootstrap group on N1, add N2.
4. start GR on N3. --> This fails with ERROR-3092 because N3 is not whitelisted on N1.
N3> start group_replication;
ERROR(3092)The server is not configured properly to be an active member of the group. Please see more details on error log.

So, N3 fails to join the group.

Case2>

1. N1 has whitelisted N2, N3
2. N2 has whitelisted N1.
3. start and bootstrap group on N1, add N2.
4. start GR on N3. --> This successful and N3 is declared ONLINE.
(N3 should not join group because it is not whitelisted on N2)

In we further continue testing, by stopping GR on N1,
N2, N3 are blocked because both of them see each other UNREACHABLE.

Note that in both cases, N3 contacts N1 prior to N2.

How to repeat:
apply attached diff.

mysql-test-extra/mysql-test/jet$cat jet.properties
jet.testlogpath=path/to/logs
jet.installpath.mysql=/5.7/server/binaries

jet.clientmachines=brage01
jet.servermachines=brage01,brage02,brage03

mysql-test-extra/mysql-test/jet$ant run -Dxmlfile=com/sun/mysql/jet/tests/replication/groupReplicationIPWhitelistTest.xml -Dpropfile=jet.properties
[21 Feb 2018 16:01] David Moss
Posted by developer:
 
Thank you for your feedback, this has been fixed in upcoming versions and the following was added to the 8.0.5 changelog:
When using group_replication_ip_whitelist, it was possible to configure a group so that it functioned even though all members could not establish the internal group communication connection to each other, resulting in inconsistent behavior. Now, incoming connections are accepted if the IP is in the white list or if the IP belongs to a current member of the XCom configuration. This ensures members are always able to create the internal network required for group communication.