It's very much appreciated, at least we have a direction now to try and get things back to normal/stabilized.
I'll file some bug reports with the traces to hopefully help you guys sort out what was going on.
As far as the ndb_schema_dist_upgrade_allowed option goes, maybe some thought should be given as to what the appropriate default (and location) should be. As it stands now, if it's a mysqld option, you are putting it in the hands of a SQL client to decide when it's appropriate to upgrade internals on a cluster. In our case, it was a mysqld node that someone uses on occasion to run reporting on their laptop. Should we really trust that someone's laptop isn't going to auto-update mysqld and then if it does, assume it's going to use the correct options to *not* screw up the entire cluster? That would be a best case scenario. In a worst case scenario, it feels like it could be used as a very simple attack vector to intentionally ruin a cluster in about 10 seconds. Ideally, I feel like the schema upgrade shouldn't *ever* be triggered by a sql node unless all data and sql nodes have been upgraded first. And even then, I feel like such major internal changes to the cluster should be somehow controlled by the management nodes, not controlled by a single rogue sql node that is allowed to connect and make major structural changes that affect every nodes ability to even use the cluster.
You obviously know the internals better than I do, but is there ever a scenario where you would legitimately want mysqld to upgrade the cluster to the 8.0 schema system if you still had data nodes and sql nodes on 7.6?
January 28, 2020 11:32AM
February 05, 2020 11:05AM
February 05, 2020 01:12PM
February 05, 2020 04:32PM
February 09, 2020 03:38PM
February 11, 2020 09:51AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.