Description:
Upon executing:
select group_replication_get_write_concurrency();
I get:
ERROR: 1123: Can't initialize function 'group_replication_get_write_concurrency'; Member must be ONLINE and in the majority partition.
In a InnoDB Cluster, multi-primary, server on version 8.0.40, shell & router on v8.4.5, I use a 3rd party monitoring tool, dolphie, to monitor my instances.
The issue only arises when using Dolphie, so, maybe it's more a Sev4 / Feature request, however I just wanted to bring it to someones attention as I think it's relevant.
Adding a read-replica _within_ an InnoDB Cluster, is a cluster option, added via addReplicaInstance / add-replica-instance. So it would make sense for this replica instance to have knowledge of the cluster it's replicating from, albeit it's a read replica and may never become more than just that.
However, when executing "select group_replication_get_write_concurrency()" via dolphie, I get an error, because, as defined, this replica instance isn't a group replication member, albeit, a "2nd cousin" instance, once removed.
But it is part of the high availability cluster that is not only defined previously, but a must-have pre-requisite for the addReplicaInstance to work.
And, in fact, I could use the read replica instance to monitor my group's event horizon of the valid candidate members from this peripheral instance.
How to repeat:
Connect via mysql / mysqlsh to the replica instance and execute:
select group_replication_get_write_concurrency();
ERROR: 1123: Can't initialize function 'group_replication_get_write_concurrency'; Member must be ONLINE and in the majority partition.
Suggested fix:
Detect that the instance is in fact a read replica instance:
select rcs.CHANNEL_NAME, rcc.HOST as 'Src Primary', rcs.SERVICE_STATE as 'State', rcs.LAST_HEARTBEAT_TIMESTAMP from performance_schema.replication_connection_status rcs, performance_schema.replication_connection_configuration rcc where rcs.CHANNEL_NAME = rcc.CHANNEL_NAME and rcc.CHANNEL_NAME = 'read_replica_replication'
.. within an InnoDB Cluster and produce a different / more appropriate error or 'output' in line with it's role and participation within the cluster.
Or, share the value for the whole cluster, highlighting which instances are, and are not, valid for the cluster group's event horizon.
