my.cnf custom settings, mysqld fails to start

[TheSerapher]

When trying to use some overrides of the default settings it seems that those cause the MySQL server to fail.

I have looked a bit into this and it seems that the Debian package forces a server restart. This means that, after restart, the server will come up with the default percona my.cnf which has different settings than mine.

Here the DEBUG output of Vagrant:

[2012-10-04T14:55:20+02:00] DEBUG: STDERR: Stopping MySQL (Percona Server): mysqld.
Starting MySQL (Percona Server) database server: mysqld ..
Checking for corrupt, not cleanly closed and upgrade needing tables..

Now when the template is written MySQL will fail to start:

InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 301989888 bytes!
121004 14:55:55 [ERROR] Plugin 'InnoDB' init function returned error.
121004 14:55:55 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
121004 14:55:55 [ERROR] Unknown/unsupported storage engine: InnoDB
121004 14:55:55 [ERROR] Aborting

The only workaround I was able to find was to delete my logfile and let MySQL recreate them.
I think innodb_log_file_size is causing this, I upgraded that to 288 MB.

I am not sure how this could be fixed other than not using this custom variable at all. I doubt the Cookbook could stop the package from restarting the server.

[TheSerapher]

I have moved the template generation above the install step which seemed to have helped. Maybe this could be used to ensure the proper configuration is used?

[phlipper]

@TheSerapher thanks for this report. This sounds like it is related to #9. Can you elaborate on what steps you changed for your situation? I'd be happy to work on a fix or accept a pull request. Thanks!

[TheSerapher]

It's not a Percona 5.5 issue per say. I'd think its related to their Debian package which enforces a restart once installed.

Since it comes with its own my.cnf these settings are used prior to writing the appropriate template with chef. The mentioned setting is causing the server to fail when restarting again.

I am on my phone now but all I did was re-arrange the chef recipe so the my.cnf template is written before the package is installed. This seemed to work fine. The Debian package did not overwrite my file with its defaults.

[TheSerapher]

Sure enough this is indeed a duplicate of #9 - helps reading it entirely. Moving discussion there.

[patcon]

I think the root of this issue is undesired behaviour of the percona package. If the debian percona package is forcing a restart, I think that's an issue that should be taken up with the package maintainers. My understanding is that this is bad practice in sysadmin land. A service should not be auto-started. Perhaps there is a flag to suppress?
heavywater/chef-jenkins#4 (comment)

Also perhaps this is rooted in the fact that MySQL was not stopped prior to installing percona?
http://docs.1h.com/Percona_MySQL_installation_tutorial

Have we tried forcing an immediate stop prior to installing? Perhaps the package is smart enough to realize a restart is not needed in this scenario...

(Please feel free to reopen this issue if you also feel it's a distinct problem)

[TheSerapher]

Since there was no package installed prior to running the percona installation I would be unable to run a mysql stop.
I would agree that this could be a package issue instead of a cookbook issue. Maybe we should ask their developers?

[patcon]

OK, I'm reading through this again, and perhaps I misunderstood: It seems the piggybacking on the mysql cookbook would solve this. I'm already using this approach in another percona cookbook, the gist of which I'm hoping to merge into this one at some point:
https://github.com/myplanetdigital/vagrant-ariadne/blob/master/Cheffile#L18-28

The critical mysql cookbook patch (seen in the Cheffile) is already merged, so the approach is already viable:
sous-chefs/mysql#33

So I guess this is technically solved by the other issue's suggestion, if only because the mysql cookbook seems to have solved it :)

Sooo.... sorry for wasting time. It appears that issue, while indirect, would solve this!

[phlipper]

@TheSerapher, @patcon,

Is there anything actionable that can be done on this issue at the moment (code, README notes, etc.) to address this, or is the issue closable?

Thanks for the reports!

[TheSerapher]

@phlipper : As for the InnoDB log size I would think only writing the template file prior to installing the package would be able to fix this. Each package comes with it's own config file not to mention we have no control over the restart behavior when a package is installed. Using a pre-installed template would ensure those settings are used. And obviously the size can not be changed via chef afterwards which should be mentioned in the README.

[patcon]

I think this will be addressed by #73, so going to close this. Feel free to re-open if you disagree :)

[patcon]

As I was working through the update, seems this might have something to do with percona 5.6 being released. I have every version working except 5.6, which throws the same error on both centos64 and precise1204

Will update this if i find anything

EDIT: As per this thread, setting this is my.cnf at least made the problem go away, but it doesn't make much sense to me yet:

innodb_buffer_pool_size = 8M

It was 128M before, for what it's worth.

[patcon]

As I started trying to narrow it down, it got much more complicated. For what it's worth, removing the cnf file solves the "problem". Not sure which of the defaults is "bad"

http://stackoverflow.com/questions/7020836/where-is-perconas-my-cnf-file

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.