Re: ndb_restore

[Shawn Hogan]

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?