Implement character_set and other options #167

Merged
merged 13 commits into from Jul 2, 2013

Conversation

Projects
None yet
5 participants
Contributor

abraham1901 commented Apr 4, 2013

You can change the default server and client character set.
http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html

Performance tuning parameters:

  • Adding key_buffer parameter to mysql::config
  • Adding thread_stack parameter to mysql::config
  • Adding thread_cache_size parameter to mysql::config
  • Adding myisam-recover parameter to mysql::config
  • Adding query_cache_limit parameter to mysql::config
  • Adding query_cache_size parameter to mysql::config
  • Adding max_connections parameter to mysql::config
  • Adding tmp_table_size parameter to mysql::config
  • Adding table_open_cache parameter to mysql::config
  • Adding long_query_time parameter to mysql::config
  • Updating mysql_config spec tests
  • Fixing lint warnings

Replication parameters:

  • Adding server_id parameter to mysql::config
  • Adding sql_log_bin parameter to mysql::config
  • Adding log_bin parameter to mysql::config
  • Adding max_binlog_size parameter to mysql::config
  • Adding binlog_do_db parameter to mysql::config
  • Adding expire_logs_days parameter to mysql::config
  • Adding log_bin_trust_function_creators parameter to mysql::config
  • Adding replicate_ignore_table parameter to mysql::config
  • Adding replicate_wild_do_table parameter to mysql::config
  • Adding replicate_wild_ignore_table parameter to mysql::config
  • Adding expire_logs_days parameter to mysql::params
  • Adding max_binlog_size parameter to mysql::params

abraham1901 added some commits Apr 4, 2013

* Adding `key_buffer` parameter to `mysql::config`
* Adding `thread_stack` parameter to `mysql::config`
* Adding `thread_cache_size` parameter to `mysql::config`
* Adding `myisam-recover` parameter to `mysql::config`
* Adding `query_cache_limit` parameter to `mysql::config`
* Adding `query_cache_size` parameter to `mysql::config`
* Adding `max_connections` parameter to `mysql::config`
* Adding `tmp_table_size` parameter to `mysql::config`
* Adding `table_open_cache` parameter to `mysql::config`
* Adding `long_query_time` parameter to `mysql::config`
* Updating mysql_config spec tests
* Fixing lint warnings
* Adding `server_idparameter to `mysql::config`
* Adding `sql_log_bin` parameter to `mysql::config`
* Adding `log_bin` parameter to `mysql::config`
* Adding `max_binlog_size` parameter to `mysql::config`
* Adding `binlog_do_db` parameter to `mysql::config`
* Adding `expire_logs_days` parameter to `mysql::config`
* Adding `log_bin_trust_function_creators` parameter to `mysql::config`
* Adding `replicate_ignore_table` parameter to `mysql::config`
* Adding `replicate_wild_do_table` parameter to `mysql::config`
* Adding `replicate_wild_ignore_table` parameter to `mysql::config`
* Adding `expire_logs_days`  parameter to `mysql::params`
* Adding `max_binlog_size` parameter to `mysql::params`

Vye commented May 17, 2013

@abraham1901,

Any luck getting the build to pass? I'd like to see the functionality for this commit merged into master.

Contributor

abraham1901 commented Jun 16, 2013

Fixed

Contributor

apenney commented Jun 16, 2013

I'm wondering if we're reaching the point where we need to rethink how we're configuring mysql altogether. Rather than attempting to provide for every possible option as a variable we might want to think about a conversion to passing in a config hash that has just the defaults as standard.

This would let users create a mysql::config_hash entry in hiera and pass in a full mysql configuration without us having to handle each configuration option by hand.

Upsides: No more PRs for adding new options.
Downsides: Less verification around making sure options that are passed in make coherent sense. We could have a class that just attempts to ensure mutually exclusive options aren't passed in. I don't know what makes sense here.

Contributor

razorsedge commented Jun 16, 2013

The idea around Puppet modules (that I have always worked toward) was that the knowledge of domain experts would be distilled into logic that not only makes for easy, automated set up but also advanced configuration. As many configuration options as possible should be provided, and verification inside the module that options work well together and follow best practice should be encouraged.

This does lead to two things:

  1. Lots of PRs and code maintenance, especially for complex software like MySQL.
  2. Hardcore domain expertise for the module maintainers.

Of course there comes a point where a user should just start dropping their own files in /etc/mysql/conf.d. Perhaps this should be better documented?

Contributor

apenney commented Jun 16, 2013

Yeah, it's a tough distinction. I think it would be possible to have a base configuration hash, toggles that merge other hashes with the main configuration hash, and then finally the ability to pass in custom_config => {} stuff that also gets merged into the main hash would certainly meet the goals of allowing for automated choices while allowing advanced users to override and inject new configuration options.

I think as an end user it becomes overwhelming to open init.pp and see hundreds of variables at all the same top level. It's hard to see what's important and what's just there for advanced users to tweak.

Admittedly we should always support adding conf.d/ type stuff anywhere it's possible for advanced users. We should make that usage clear.

Member

hunner commented Jun 17, 2013

The idea around Puppet modules (that I have always worked toward) was that the knowledge of domain experts would be distilled into logic that not only makes for easy, automated set up but also advanced configuration. As many configuration options as possible should be provided, and verification inside the module that options work well together and follow best practice should be encouraged.

This is an excellent explanation of why a module should contain more than simple "configuration pass-through" abilities :).

This does lead to two things:

  1. Lots of PRs and code maintenance, especially for complex software like MySQL.
  2. Hardcore domain expertise for the module maintainers.

Also true. The issues with 1. in the past is that sufficient amounts of time were not accounted for this, but we are working to fix that. As for 2., we continue to rely heavily on community members such as yourself for this kind of quality input and resource scaling. Thanks for contributing!

Of course there comes a point where a user should just start dropping their own files in /etc/mysql/conf.d.

This is what the defined resource mysql::server::config is meant to do, in a very light sense. Perhaps we should ditch mysql::config altogether and provide standard "replication" and "backup" and "performance" configuration classes that take advantage of this instead of lumping them all together? Basically, out-of-the-box configuration sets for specific use-cases.

Any input you have on this would be appreciated!

Contributor

abraham1901 commented Jun 18, 2013

This is what the defined resource mysql::server::config is meant to do, in a very light sense. Perhaps we should ditch >mysql::config altogether and provide standard "replication" and "backup" and "performance" configuration classes that >take advantage of this instead of lumping them all together? Basically, out-of-the-box configuration sets for specific >use-cases.

Configuration of Mysql Server is flat by design and options usually realized several functions at the same time. That’s why it is impossible to predict all configurations of mysql in a several narrow specialized classes.
For example, option “bin-log” can be used for replication, for making backups, for analytics and for data recovery at the same time. It isn’t rational to make a few classes with a lot of overlapping options witch not cover all possible configurations. It's better to make one main class that will realized all possible options from my.cnf and to make another separate classes on the basis of this class for the most commonly used configurations.

Contributor

abraham1901 commented Jun 21, 2013

What's the result?
@hunner, can you merge this pull request?

Contributor

apenney commented Jul 2, 2013

Hey,

Can you rebase this against master as we've been merging in other PRs and it's no longer cleanly mergable. I'd like to get this merged for now and argue over other ways to configure things in future. :)

Contributor

abraham1901 commented Jul 2, 2013

Done.

Ashley thanks for your work.

Contributor

apenney commented Jul 2, 2013

Hey, still a few issues remaining:

CONFLICT (content): Merge conflict in spec/classes/mysql_config_spec.rb
CONFLICT (content): Merge conflict in manifests/config.pp

This is all my fault as I just merged even more PRs while trying to catch everything up. I won't commit anything else until you have a chance to look at these, promise. :)

Merge branch 'master' of https://github.com/puppetlabs/puppetlabs-mysql
Conflicts:
	manifests/config.pp
	spec/classes/mysql_config_spec.rb
Contributor

abraham1901 commented Jul 2, 2013

Done.

apenney added a commit that referenced this pull request Jul 2, 2013

Merge pull request #167 from abraham1901/master
Implement character_set and other options

@apenney apenney merged commit 731036e into puppetlabs:master Jul 2, 2013

1 check passed

default The Travis CI build passed
Details
Contributor

apenney commented Jul 2, 2013

And merged, thanks for all your work on this, it was a huge PR and I appreciate you putting in the work.

Contributor

abraham1901 commented Jul 2, 2013

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment