mysql_config require package mysql-server: problem when specifying a log file size

[daks]

Hello,

I'm using this formula with an option to change the InnoDB log file size.

innodb_log_file_size: 256M

It causes problem on my Debian VM: mysql is installed, configured but can't (re)start. The error tells about the current log file size which is different from the one specified in my.cnf.

I think what happens is the following:

• packages installation: Debian creates a default my.cnf, and then starts mysql server
• creation of the /etc/mysql/my.cnf
• restart of the mysql service: this is where it fails

I modified the formula to make mysql_config state run before the mysql.server package installation, and it solved my problem.

What do you think about this? Should it be possible, and safe, to change the states order?

Thanks.

[vschum]

You would have to test this on more than just Debian to see how other
package managers handle installation of mysql when a pre-existing my.cnf
already exists. In theory, it shouldn't be a problem as sane behavior is to
install a copy of the my.cnf the package manager includes with an
additional file extension and leave the pre-existing my.cnf.

On Wed, Jul 27, 2016, 05:13 Éric Veiras Galisson notifications@github.com
wrote:

Hello,

I'm using this formula with an option to change the InnoDB log file size.

innodb_log_file_size: 256M

It causes problem on my Debian VM: mysql is installed, configured but
can't (re)start. The error tells about the current log file size which is
different from the one specified in my.cnf.

I think what happens is the following:

• packages installation: Debian creates a default my.cnf, and then
  starts mysql server
• creation of the /etc/mysql/my.cnf
• restart of the mysql service: this is where it fails

I modified the formula to make mysql_config state run before the
mysql.server package installation, and it solved my problem.

What do you think about this? Should it be possible, and safe, to change
the states order?

Thanks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#127, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABagufrdq2bQp8BGw8zqkd0eTkHsmS9bks5qZyExgaJpZM4JV_Q1
.

[Hybrid512]

+1
Debian 7 and 8, same problem, when setting innodb_log_file_size, installation always fails that way :

• mysql-server is installed but for unknown reason, the log file size is wrong and the server can't start thus, the package can't be fully installed.
• everytime, I must add an "exit 0" in the init file in order to force mysql start (at least think it is started) so that debconf can finish its task
• then, I remove this "exit 0" and delete my ib_logfiles then re-run salt, at that time, the my.cnf is correct, the server starts and re-creates its ib_logfiles with good size and everything is ok

This is really annoying because I have dozens mysql-servers to deploy and everytime there is an upgrade of the package I must fix each of them one by one.

[StyXman]

I modified the formula to make mysql_config state run before the mysql.server package installation, and it solved my problem.

@daks you mean something like this? master...StyXman:patch-1

[daks]

@StyXman i'm not sure about what your code does, it seems to do the same on Debian or everyone else.

What I did is remove

  - require:
      - pkg: {{ mysql.server }}

on mysql_config in config.sls, so that state can run before package installation.

[StyXman]

It's installing the config file before installing the package. I'm not sure that actually fixes the problem, but it's what I understood that you did. I'll try to test it soon, but let me know what you think about it.

[aboe76]

Instead of modifying the require stuff, why not use listen_in, on the config files,
that way salt will install the package, install the config file and notify the service to restart.

[daks]

@aboe76 the problem is: if you change InnoDB log file size after mysql server had started, a restart doesn't work, as config log file size is not coherent with the actual on-disk log file size.
You can verify it adding something like this on your pillar

innodb_log_file_size: 256M

[Hybrid512]

Might be ... but that's not really an acceptable answer unless one can convince Oracle to change that behaviour.

[aboe76]

@Hybrid512 I know, I'm sorry if I offended someone. I will rephrase

[aboe76]

@daks, thanks for the clarification, reading in to the issue, I see only a nightmare in trying to automate salt for this:

1. first stop mysql,
2. adjust the config file,
3. check and see if mysql is truly stopped
4. check logfile names...
5. move the old logfiles out of the way,
6. start mysql again and verify...if new logfiles are created....

[aboe76]

@daks I was looking in to the official puppetlabs mysql module and they specify the following order:

  Anchor['mysql::server::start'] -> 
  Class['mysql::server::config'] ->
  Class['mysql::server::install'] ->
  Class['mysql::server::binarylog'] ->
  Class['mysql::server::installdb'] ->
  Class['mysql::server::service'] ->
  Class['mysql::server::root_password'] ->
  Class['mysql::server::providers'] ->
  Anchor['mysql::server::end']