Description:
MySQL reports its version via SELECT VERSION(), @@VERSION. Normally this version might be a 3-digit value such as 8.0.42 / 8.4.5 / 9.3.0 (current versions).
In the past the version reported by MySQL might have a suffix and indeed if you have a patched version of MySQL the version might report itself differently. Also OCI based versions of MySQL also do this.
So @@VERSION may have values like:
- '8.0.34'
- '8.0.34-u1-cloud'
- '8.0.34-u2-cloud'
- '8.0.42'
- '8.0.42-SR1'
etc. You get the idea. The full string version provides a suffix which may provide more information on the MySQL specific patch or version even if the base version is 8.0.34 / 8.0.42 in the cases shown above. This can be useful if you happen to be managing a lot of servers as it's possible that not all servers run the exact same version. Tooling can use this information if needed to do patching or version checks.
GR cluster reporting has a table replication_group_members which provides information on each server of the members of the cluster.
root@host1 [performance_schema]> select * from replication_group_members;
+---------------------------+--------------------------------------+-------------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 3ac7cd52-3bd3-11f0-9e42-fa163eed17ab | host1.example.com | 3306 | ONLINE | PRIMARY | 8.0.42 | MySQL |
| group_replication_applier | 508043a4-46e3-11f0-8f07-fa163e1b1f1e | host2.example.com | 3306 | ONLINE | SECONDARY | 8.0.42 | MySQL |
| group_replication_applier | 620b1347-43b5-11f0-8598-fa163ecde038 | host3.example.com | 3306 | ONLINE | SECONDARY | 8.0.42 | MySQL |
| group_replication_applier | 8a21a052-a8e2-11ef-9284-0a3069c96e6b | host4.example.com | 3306 | ONLINE | SECONDARY | 8.0.42 | MySQL |
| group_replication_applier | a73be435-3a42-11f0-a851-fa163e8169df | host5.example.com | 3306 | ONLINE | SECONDARY | 8.0.42 | MySQL |
| group_replication_applier | b9149e27-43b3-11f0-90ad-fa163ef02bba | host6.example.com | 3306 | ONLINE | SECONDARY | 8.0.42 | MySQL |
+---------------------------+--------------------------------------+-------------------+-------------+--------------+-------------+----------------+----------------------------+
6 rows in set (0.00 sec)
This is a modified example from one of my clusters.
However, if I check the @@VERSION output of host hosts mentioned I notice that some of them have an '8.0.42-SR1' version and others do not and this information is invisible to me as part of the cluster information provided by GR.
What
How to repeat:
See above.
Suggested fix:
Please adapt the output of replication_group_members to provide the @@VERSION provided by each of the group members instead of the version shown which is I believe an internal 4 byte representation (leading byte is zero) of the version shared amongst the cluster members. I believe the MEMBER_VERSION column should show the @@VERSION. Internal handling inside GR can use the internal representation that's been used up to now.
This has many advantages:
- it exposes the full MySQL version of each server in the cluster so improves instrumentation
- it makes it easier to see when doing OCI rolling upgrades in the cloud how this is progressing by looking at the cluster information alone.
- it makes it easier for me if I need to run a patched version of MySQL to ensure that all members of the cluster are using that version. That patching may come from Oracle or it may come from internal patching of binaries.
Without this information the output from replication_group_members only provides a partial view of the binaries running in the cluster.
Related I believe to bug#102558 though it's invisible to me.
