Comments on: The perils of InnoDB with Debian and startup scripts

By: Markus

Markus — Thu, 12 Feb 2009 08:14:01 +0000

g, you don’t need to cry, as ch wrote above the behaviour was already changed about a year ago.

By: g

Sun, 01 Feb 2009 03:26:32 +0000

Yet another brain damaged Debian “improvement”.

Memo to debian package maintainers: You are *package maintainers*. If you want to change the way MySQL *behaves*, SUBMIT A PATCH LIKE EVERYONE ELSE, IF FOR NO OTHER REASON THAN TO HAVE IT REFLECTED IN THE OFFICIAL DOCUMENTATION EVERYONE (except a few of us crusty old farts who don’t trust anyone or anything we don’t build ourselves) RELIES UPON.

Seriously…

By: Baron Schwartz

Baron Schwartz — Fri, 30 Jan 2009 02:48:27 +0000

I agree 100%. One thing I didn’t say — there might be a reason for a custom startup script — but it’s not this. Just don’t put mysql_check_upgrade (that only needs to be run *one time*!) and don’t put mysqlcheck in it. But you might put a script to warm up your indexes or something like that. Something that’s too complex to put in the –init-file option.

By: peter

peter — Fri, 30 Jan 2009 02:45:20 +0000

Baron,

In reality it is not clear to me why do it this way all together.
If you want tables to be checked and repaired on startup myisam_recover is the decent option. If this causes problems because MySQL starts to check and repair a lot of tables at the same time blocking all connections may be MyISAM is simply not the right choice for you.

Running check in the background is the broken middle ground – you still have some queries ran against corrupted MyISAM tables which can cause wrong query results or further corruption and you can still get MySQL stalled/running out of connections when a lot of connections block waiting for some large commonly accessed table which is being checked.

By: Baron Schwartz

Baron Schwartz — Thu, 29 Jan 2009 14:05:55 +0000

Norbert, I don’t think it’s the init script Vide meant; it’s the install/deinstall. I agree — it shouldn’t try to start/stop automatically. This is not a mistake unique to Debian

By: Baron Schwartz

Baron Schwartz — Thu, 29 Jan 2009 14:02:09 +0000

Changing the script isn’t enough to avoid the problems with the data dictionary, BTW. Just touching the table causes InnoDB to allocate space for it, which it will never release again until it’s restarted. And you have to touch the table to find out its engine, so you can’t know a priori which tables not to touch. Any scripts that query the INFORMATION_SCHEMA upon startup are also a very bad idea on installations with lots of tables.

I still advise to disable the script, period, unless you know you want it enabled.

By: Norbert Tretkowski

Norbert Tretkowski — Thu, 29 Jan 2009 11:29:59 +0000

Vide, just drop a mail to the Debian BTS with your suggestions and patches. It’s too late to change things for lenny, but we can talk about your suggestions and patches for squeeze.

Btw, I’m using the stock init scripts in “real mysql installations” (50+ servers), and they are working just fine.

By: Vide

Vide — Thu, 29 Jan 2009 09:24:38 +0000

Yep, the stock Mysql Debian init script sucks so badly that it’s almost mandatory for every sysadmin out there with a real Mysql installation to fine tune them. Moreover it sucks almost as well that scripts in the .deb packages stop/start Mysql without asking. There are situations in which you want to update the binary quickly but you want a controlled restart.

By: Brice Figureau

Brice Figureau — Thu, 29 Jan 2009 06:57:35 +0000

My first action after installing mysql on Debian is to comment the check_for_crashed call (actually not really me, but Puppet is doing it for me).

By: http://www.anvilon.com/

http://www.anvilon.com/ — Wed, 28 Jan 2009 21:03:30 +0000

I have also used the “KILL 7″ approach in the past and found that another thread is often opened up immediately with a “CHECK TABLE” on the next table in the database. I needed to keep killing threads until it gets to the end. [Ubuntu 8.04 Hardy]