I’m suprised to find that there is relatively little work needed to get Webmin to play nicely with ndb_cluster. The option to remove table types that you don’t want to allow (ie, anything that IS NOT NDBCLUSTER) would be nice, but not imperative.
What I’m up against this very second is that the various API nodes for MySQL do not share user information. I have Webmin pointed at my MySQL balancer, and that works fine, but if I create a new user, it only gets created on the node that I happened to wind up point to this particular time.
Is there any way to have the user modification code set up to handle more than one server, and when any user modifications/permissions changes occur, hit all of the listed servers with it and not just the one, or are we talking major code adjustments here?
That sounds pretty cool. I’d never noticed ndb_cluster before. It’d be cool to have a brief writeup of how you setup your cluster (or some pointers to existing docs on the web if there is such a thing–I didn’t find anything in a brief googling).
I don’t think it would be dramatic at all to have Webmin’s MySQL module handle user creation across N machines. Webmin is already network aware for the database modules, so having it iterate over a list of them instead of just one for some actions, would almost certainly be almost trivial.
I’ll ask Jamie to check out this thread. If it’s low-hanging fruit, it’d be nice to have those database scaling features built right in.
Hi Tony,
So is it just a matter of adding the same entries to the ‘user’ and ‘db’ tables in the ‘mysql’ database for each machine in the cluster? If so, that would be possible, with a little work…
Yeah, that’s really all there is to it. I can give you MySQL NDBCLUSTER in a nutshell. It has 3 components, all referred to as nodes. You can run one or all three of the node types on a single box:
Management Node
API Node
NDB Node (Storage Node)
The API nodes are what you send the MySQL commands to. NDB literally does the memory storage (Until 5.1 hits production-readiness, at which time it can do storage to disk). The management nodes are required to keep everything in sync. At the moment I have 3 boxes, each running all three of the above, and then my Virtualmin server is also running a management node, and it is the primary management node.
When I set up to do Virtualmin, I had it connecting to a single API node. That required me to set up root privs for remote MySQL access to work correctly, and I had to do that three times (n times, n = the number of API nodes).
The other trick of course is that if I need to scale up to more API nodes, there would need to be a facility to duplicate out the existing user permissions to the new API node.
The management node is dead simple. It’s controlled by the program ndb_mgm. I don’t know if there is a perl module that plugs into that yet or not, but it essentially provides a central interface to shutdown and startup nodes, and even do backups. The only part of this that webmin would really care about is giving a quick glance at node health, and possibly the ability to start and stop individual nodes, but honestly that might be best handled through Webmin’s built in clustering facility. Dunno. I’ll leave that decision up to you.
There’s really no reason that Webmin should ever touch the ndb nodes directly that I can think of. It’s not something that should be messed with from a web interface. Honestly, it gets started, it gets stopped. That’s about it. Not toys to play with, nothing interesting to see.
I’d edit my post, but it keeps saying “hacking attempt”. Pfft.
Anyway, I put haproxy out in front of the API nodes, and then point Virtualmin at the haproxy box. Obviously, if webmin were going to know about this, what it would probably want is the haproxy address, and then the addresses of the actual API nodes so it could manage users and permissions across all of them. Again, I leave how that’s implemented up to you.
What I will probably do then is add an option for other MySQL servers to create accounts on, in addition to the primary that it connects to for creating databases and tables.
Actually, I am surprised that ndbcluster doesn’t handle this already, as presumably other DB operations are already replicated across the cluster.
The reason for this is that MySQL does allow you to do non-ndb operations on a per-node basis, and they don’t just automatically presume that all users are valid on all api nodes, which given that attitude, I guess is fair.
But the truth of the matter is that if you’re going to add API nodes to a cluster, and user virtualmin with it, I can’t think of a situation where you would intentionally create that type of split-brain scenario, and if so, then just don’t add it to the options.
Virtualmin 3.44 will definately include this feature … I just finished coding it.
I have added a new field to the Module Config page for specifying extra MySQL servers to create users and permissions on.
Honestly, it gets started, it gets stopped. That’s about it. Not toys to play with, nothing interesting to see.