I often see things go past my eyes where customers (and users – i.e. those that don’t send wads of cash our way and hence are not financially supporting my beer, curry and photography habits) have amazing uptime and reliability requirements.
When talking to businesses that use MySQL, it’s not uncommon to have the “if the DB is down, our business doesn’t operate” line bandied around. How people make sure this never happens can differ (hint: it often involves replication and good sysadmin practices).
One thing I like doing is making things easier for people. Sometimes it’s also a much more complicated problem than you’re initially led to believe.
I think configuration files are obsolete. Okay, maybe just for databases. Everything should be changable as an online operation. This should also be able to be done via a standard interface – in our case, SQL. This means it’s suddenly really easy to write portable UIs around the admin functionality (no getting the parsing and generation – most trickily, the modification of text based config files right) just the issuing of SQL to the server, relativly simple. This even enables web apps to tune the database a bit, opting for various amounts of automation for various applications – in a cross platform way!
One of my visions for NDB (MySQL Cluster) is to get rid of the (user visible) configuration file and manage everything through SQL (or management client, something like that). This way you could ALTER CLUSTER ADD NODE, ALTER CLUSTER SET DataMemory=4GB etc and things should “just work”, take however long it needs – without downtime.
In a clustered environment, we could do these operations transactionally so that in the event of node or system failure we have some hope of being in a nicely consistent state and that during system recovery (or node recovery) we’re not performing a configuration change in addition to restarting (e.g. if you edited a config file and then had a crash).
Config changes could also have EXPLAIN, a non-modifying operation that would EXPLAIN what would be done – e.g. rolling restart, taking approximately X minutes per node and Y minutes total. This could help in planning and scheduling of configuration changes.
(i wonder if that made any sense)
Yes, this made sense. And there are a lot of other things, that a database could do “the database way”. Creating or dropping fields and tables with INSERT and DELETE statements on system tables (properly handled). UPDATE cluster SET memory = 4GB WHERE … like this. Getting the list of available datatypes is almost available in MySQL (it’s an unfinished feature). When relational databases use special keywords (DDL) for metadata management (which is just data) is kind of odd, isn’t it?
Users = Customers. That’s why the phrase “paying customer” isn’t redundant.
i guess so… i was just kinda waffling for a bit and didn’t reread anything. that two people have understood what i said is rather surprising
I’m still pretty early in my MySQL career, and I’ve already run into some instances where it would be great to have simple online configuration changes. In a small company without a dedicated DBA, it’s easy to get developers who know enough about SQL, but aren’t versed in the specifics of MySQL configuration. Heck, I’m not that good at config options (though I’m working on it). Life could be made much simpler by just being able to find in the reference manual what option needs changing and then do it, in a format and language familiar to everyone.
Pingback: Pythian Group Blog » Log Buffer #23: a Carnival of the Vanities for DBAs