Implement character_set and other options

[abraham1901]

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

[Vye]

@abraham1901,

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

[abraham1901]

Fixed

[apenney]

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.

[razorsedge]

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?

[apenney]

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.

[hunner]

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!

[abraham1901]

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.

[abraham1901]

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

[apenney]

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. :)

[abraham1901]

Done.

Ashley thanks for your work.

[apenney]

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. :)

[abraham1901]

Done.

[apenney]

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

[abraham1901]

👍