Bug #110180 Unable to fetch live group_replication member data from any server in cluster

• Submitted: 23 Feb 2023 9:41
• Modified: 28 Feb 2023 17:07
• Reporter: zetang zeng (OCA)
• Status: Verified
• Category: MySQL Router
• Severity: S4 (Feature request)
• Version: 8.0.30
• OS: Any
• CPU Architecture: Any

[23 Feb 2023 9:41] zetang zeng

Description:
When MySQL Cluster dissolved and then re-configed, router fail to connect cluster and report error:

2023-02-23 17:29:58 metadata_cache ERROR [7f5642f9e700] Unable to fetch live group_replication member data from any server in cluster 'myCluster'

How to repeat:
- config a three instance MySQL Cluster using mysqlsh

var cluster;
cluster = dba.getCluster("myCluster");
if (cluster) {
} else {
    cluster = dba.createCluster("myCluster");
}
cluster.addInstance(key1, {recoveryMethod: "incremental"});
cluster.addInstance(key2, {recoveryMethod: "incremental"});
cluster.addInstance(key2, {recoveryMethod: "incremental"});

- connect to master using mysqlsh

/opt/tiger/mysql-shell/bin/mysqlsh -ucluster -pxxx --host=master -P3306

- dissolve the cluster:

dba.getCluster().dissolve()

- config a three instance MySQL Cluster using mysqlsh again

var cluster;
cluster = dba.getCluster("myCluster");
if (cluster) {
} else {
    cluster = dba.createCluster("myCluster");
}
cluster.addInstance(key1, {recoveryMethod: "incremental"});
cluster.addInstance(key2, {recoveryMethod: "incremental"});
cluster.addInstance(key2, {recoveryMethod: "incremental"});

- cluster is recovered:

- the router crashed:

2023-02-23 17:29:58 metadata_cache ERROR [7f5642f9e700] Unable to fetch live group_replication member data from any server in cluster 'myCluster'

Suggested fix:
the router should be able to recover after reconfig.

[28 Feb 2023 17:07] MySQL Verification Team

Hi,

I do not see how is this a bug. The documentation clearly states that "This function stops group replication and unregisters all members from the cluster metadata." so cluster is gone, dissolved, you can create new one but there's nothing to "recover". 

I will push this to our InnoDB Cluster dev team as a Feature Request so they might decide to implement some behavior like this, but a bug, nope, this is not a bug.

Thanks for the request, the FR makes sense.