Spoke with Brian the other day on what was required to get NDB to be a pluggable engine – and started hacking.
The tricky bits invole dependencies of things like mysqldump and ndb_restore on some headers to determine what tables shouldn’t be dumped (hint: the cluster database used for replication).
Also, all those command line parameters and global variables – they’re fun too. It turns out InnoDB and PBXT are also waiting on this. In the meantime, I’ve done a hack that puts config options in a table.
Currently blocked on getting the embedded server (libmysqld) to build properly – but i now have a sql/mysqld binary with pluggable NDB. All libtool foo too.
Hopefully i’ll be able to post soon with a “it works” post
didn’t monty just commit some code to move the cluster.* stuff into the mysql database?
not sure… i haven’t seen it though…
In the future we plan to expose various performance and informational metrics through a table interface, the idea being that these tables would be in the ‘cluster’ database.
Since we also have customers running this… it would be an interesting patch that doesn’t break backwards compatibility (especially for online upgrades)
Monty moved the “cluster” database into the MySQL schema. There are exceptions for the MySQL schema (and its the only schema that should be used for system tables).
Hope it works with online upgrades as I beleive we’re going to have to support this for some customers…