Hello Stewart,

As I mentioned before, this is a bug in my opinion. If applications have to know the architecture of a cluster, the application is far less portable than it could, no should be. It also misleads the developer into thinking that by storing a procedure on the server, it's available permanently no matter which part of the cluster they connect to. This is obviously (thanks to your explanation) inaccurate.

As a DBA, I want to make using MySQL cluster as transparent to users as possible. If any node in a cluster goes off-line, the others should be able to take over without any special efforts of any of the applications before or after the outage. From my perspective, the cluster should transparently present itself as a single entity as if it were not a cluster at all. The fact that the table(s)'s storage engine is(are) cluster-based should be so transparent that only the DBA should notice the difference.

IMNSHO, applications should not have to be hard-coded to adapt to a cluster's configuration. You're saying that a stored proc should be created on each SQL server in a cluster. How is that portable? What happens when I decide that my cluster needs to be moved to a different set of servers on different IP addresses? All I should have to update is DNS (when the migration is completed) and the rest should fly automatically.

I understand that stored procedures are still relatively new in MySQL development. I want to make sure that those features become as integrated as the rest of the legacy code. Until that's true, certain "new" features are unusable in a clustered environment from a maintainability perspective.

It seems to me that DBA's should be able to specify a default storage engine of NDBCluster for the entire database and specify which nodes will automatically get tables when created. They also ought to be able to say that all nodes in a cluster get a particular table or all tables in a database as well as any associated stored procedures, or views.