Remove hinting at MySQL 8-specific behavior

[gianlucaborello]

Found this comment to what apparently looks like MySQL 8 specific behavior that threw me off.

I'm testing with both 5.7 and 8.0 and a (MISSING) instance seems very normal. All it takes is deleting a cluster pod, and the instance will stay in the missing status until the pod is replaced and the new instance rejoins the cluster:

{
    "clusterName": "MySQLCluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "mysql-0.mysql:3306",
        "ssl": "REQUIRED",
        "status": "OK_NO_TOLERANCE",
        "statusText": "Cluster is NOT tolerant to any failures. 1 member is not active",
        "topology": {
            "mysql-0.mysql:3306": {
                "address": "mysql-0.mysql:3306",
                "mode": "R/W",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "mysql-1.mysql:3306": {
                "address": "mysql-1.mysql:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "mysql-2.mysql:3306": {
                "address": "mysql-2.mysql:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "(MISSING)"
            }
        }
    },
    "groupInformationSourceMember": "mysql://root@mysql-0.mysql:3306"
}

Just bringing this up here in case there are some broken assumptions on your side, I'm planning to use this project for some production workload and so I'd like to make sure all the logic is expected :-)

Still working on the details for the CLA.

[prydie]

The current plan is not to support 5.7 in the next release. I was actually under the impression that master was already incompatible. If that’s not the case then we should reconsider (though providing a 5.7 -> 8 upgrade path will likely have to fall outside of scope at least for the moment).

Interesting that you’re seeing (MISSING) on MySQL 8 as well. I’d been led to believe this was no longer the case. Good catch.

[gianlucaborello]

Yes, MISSING is definitely very frequent, at least in my tests. If you have a different experience it would be nice to know.

With regards to 5.7 vs 8.0, it's working for me, but consider that I'm not using any sort of backup/restore feature, I am essentially just interested in the agent behavior with regards to handling and maintaining the cluster membership of the instances under several different failure scenarios (I have about a dozen failure scenarios I'm currently try to run through, hoping to catch the majority of issues that users in the wild might run into).

Are you aware of any breaking changes in cluster management between 5.7 and 8.0? It's completely fine to just point me to RTFM.

[prydie]

I am also seeing MISSING with 8.0.11 on closer inspection; it seems I was misinformed.

I am essentially just interested in the agent behavior with regards to handling and maintaining the cluster membership of the instances under several different failure scenarios (I have about a dozen failure scenarios I'm currently try to run through, hoping to catch the majority of issues that users in the wild might run into).

It would be great to ensure we capture all these failure secentrios in e2e tests. We should cover a good proportion already but I'd be very keen to put together a list of the gaps and start plugging them.

Are you aware of any breaking changes in cluster management between 5.7 and 8.0? It's completely fine to just point me to RTFM.

It was the cluster management elements and required mysqld flags for InnoDB group replication that we struggled with when migrating from 5.7 -> 8.0. There were a number of changes required to get the mysql-agent to work with 8.0. I've reached out internally to the InnoDB clustering team to better understand the changes and I'll update here (my team's expertise is on the Kubernetes side rather than the MySQL side).