5 ms·

> 1) MySQL requires one file to configure it: my.cnf. This is not exactly a huge amount of configuration which needs to occur. Installs via puppet, Chef or Ansi

by cwyers 10y ago

> 1) MySQL requires one file to configure it: my.cnf. This is not exactly a huge amount of configuration which needs to occur. Installs via puppet, Chef or Ansible tend to consist of two commands - one to install the package, and one to write the my.cnf (templates are good so you can use the same command on any sized server). You can add one more command to set up the initial users, should you so desire. Really? The mysql System Database is filled with tables that hold important configuration information. You can say "add one more command to set up the initial users," but if you have a lot of grants, you've got six levels of database privileges -- global, database, table, host, stored procedure/functions and proxies -- that all need to be configured. You've got the event scheduler. If you have UDFs that you expect on every server, those need to be configured. None of this is in my.cnf. Maybe at the scale you've worked at, you've never had issues with any of those things in a three-command puppet/Chef/Ansible setup, but maybe Uber has problems at a scale that you don't have, rather than them not understanding how MySQL is configured?

devoply 10y ago
Both of you have good points.
falcolas 10y ago
If you're storing the `mysql` DB part of your docker container, you're in for a bad time as well. There's a tremendous amount of mutating metadata which is stored in that DB which needs to be monitored. Much better to store it as its own version controlled SQL file which is run against a newly started DB (that third command I referenced). You could break out every statement into its own provisioner command, but then you are beginning to muddle the line between machine-level configuration and database level configuration. So yes, I still stand by my original assertion that you can stand up a fully functional DB with three Ansible/puppet/chef commands. > maybe Uber has problems at a scale that you don't have I will admit that it is entirely possible. But from what they present to the public (which is all any of us outside of Uber have to go on), their problems aren't really that unique: a heavy write workload which is easily sharded. Only their chosen method of resolving them is proving to be unique, and they appear to disregard any and all normal methods of resolving their issues. Sometimes the boring way of doing things - accepting that critical stateful processes are indeed different from stateless processes and managing them accordingly - is still the best way. Getting away from this means getting away from MySQL and its ilk entirely. I hope we can get there one day; managing DB instances separately from your stateless instances is a pain in the ass.
user5994461 10y ago
I think you're talking about different things. MySQL only needs the my.cnf to start a server. The permissions are stored along the database files (If i remember well), which is a separate problem. 1) It's only configured once on the master 2) Uber says that they don't reuse volumes [which implies many other consequences and special management around that]. By the way, Chef/Puppet/Ansible have build-in commands to manage that as well.

by cwyers 10y ago

devoply 10y ago

Both of you have good points.

falcolas 10y ago

If you're storing the `mysql` DB part of your docker container, you're in for a bad time as well. There's a tremendous amount of mutating metadata which is stored in that DB which needs to be monitored. Much better to store it as its own version controlled SQL file which is run against a newly started DB (that third command I referenced). You could break out every statement into its own provisioner command, but then you are beginning to muddle the line between machine-level configuration and database level configuration. So yes, I still stand by my original assertion that you can stand up a fully functional DB with three Ansible/puppet/chef commands. > maybe Uber has problems at a scale that you don't have I will admit that it is entirely possible. But from what they present to the public (which is all any of us outside of Uber have to go on), their problems aren't really that unique: a heavy write workload which is easily sharded. Only their chosen method of resolving them is proving to be unique, and they appear to disregard any and all normal methods of resolving their issues. Sometimes the boring way of doing things - accepting that critical stateful processes are indeed different from stateless processes and managing them accordingly - is still the best way. Getting away from this means getting away from MySQL and its ilk entirely. I hope we can get there one day; managing DB instances separately from your stateless instances is a pain in the ass.

user5994461 10y ago

I think you're talking about different things. MySQL only needs the my.cnf to start a server. The permissions are stored along the database files (If i remember well), which is a separate problem. 1) It's only configured once on the master 2) Uber says that they don't reuse volumes [which implies many other consequences and special management around that]. By the way, Chef/Puppet/Ansible have build-in commands to manage that as well.