Bug #91163 MGR member cannnot be joined, which has more executed transactions than present

• Submitted: 7 Jun 2018 1:10
• Modified: 22 Jun 2018 15:31
• Reporter: Yue Wang Wang
• Status: Can't repeat
• Category: MySQL Server: Group Replication
• Severity: S1 (Critical)
• Version: 8.0.11
• OS: CentOS (7.4)
• Assigned to: MySQL Verification Team
• CPU Architecture: Any

[7 Jun 2018 1:10] Yue Wang Wang

Description:
The variable [group_replication_allow_local_disjoint_gtids_join], which is removed in version 8.0.4, allow the current server to join the group even if it has transactions not present in the group.

However, when I was installing an MGR on MySQL 8.0.11, I find I cannot start group_replication. I check error logs, it shows an error as follows:

2018-06-06T09:28:37.464689Z 0 [ERROR] [MY-011526] [Repl] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: d679c37b-696a-11e8-bfd3-5254afe41c38:1-3 > Group transactions: a522c230-6965-11e8-a1be-5254a1b04c9e:1-3,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-5'
2018-06-06T09:28:37.464791Z 0 [ERROR] [MY-011522] [Repl] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

Does it really allow the current server to join the group even if it has transactions not present in the group in version 8.0.11? Is it a bug?

How to repeat:
Use mysql-8.0.11-linux-glibc2.12-x86_64.tar.gz which is down-loaded from Official website to install MGR. The first node is ok to start a group replication using command 'START GROUP_REPLICATION;', but other nodes failed to join.

Suggested fix:
I think the variable group_replication_allow_local_disjoint_gtids_join is set to 'OFF' as default in version 8.0.11

[7 Jun 2018 1:13] Yue Wang Wang

My username as well as my e-mail '[e-mail]' is hacked.
Contact me with '[e-mail]' if necessarily.

[7 Jun 2018 2:17] Yue Wang Wang

There is an alternative way to build an MGR within version 8.0.11.
I copy all the datafile and archfile to a new cluser member, without initialize a new DB. Thus, there is no more executed transactions than those present in the cluster, which bypass the problem.

[22 Jun 2018 15:31] MySQL Verification Team

Hi,

I'm not sure what exactly are you doing but I can't reproduce this the way you described.

Are you upgrading the existing setup or what? Setting up cluster with 8.0.11 worked ok for me, don't see what your issue is. Can you write step by step how are you reproducing this issue? With all the config files attached please.

kind regards
Bogdan