2 Dec

MySQL Gotchas on Debian (and Ubuntu)

Blue Gecko works with clients who run many different operating systems.  Our preference generally is RedHat Enterprise Linux or CentOS, but we have customers who range far and wide from there including Solaris, Windows, SuSE, and (more and more) Debian and Ubuntu.

As we’ve become more familiar with Debian and Ubuntu we have found that those customers who use the MySQL packages that are distributed with these OSs have a few quirks to be aware of.

Baron Schwartz posted a long description of one of these, the challenge with /etc/mysql/debian-start at the MySQL Performance Blog.  In the short version, if this script isn’t disabled, it will run a mysqlcheck each time /etc/init.d/mysql start is invoked.  This has been changed in later versions of Debian, but legacy systems may still have this issue.  We’ve run into it with new clients (bringing us older systems) as recently as this week.

Another gotcha that we’ve run into is the default behavior of putting an include at the bottom of the /etc/my.cnf.  Since we often come into machines that have been set up by someone else, we start with an audit of the database.  When we went to make some changes to /etc/my.cnf to tune some variables there was some initial confusion since those configuration changes had been made in an included file.   Easily sorted out,  but momentarily annoying none the less.

And lastly, Debian’s MySQL is configured to send all the MySQL logs to syslog.  Now, I’m generally in favor of using the syslog infrastructure for logging where possible, but it is definitely non-standard for MySQL.   On the positive side, it does add the benefit of rotating the error logs for you.

I’d love to hear about other non-standard customizations in the MySQL packages for Debian and Ubuntu and other distributions.  Drop them in the comments.  To simplify management, we generally use the packages from MySQL in order to have the most recent GA version as well as a standard filesystem layout.

Related posts from the blog:

  1. RPM “multiple packages” oddity, fixed
    I deal with all shipes and sizes, and distributions, of Linux. Each Linux distribution has quirks. Particularly with...
  2. MySQL 5.1GA
    As is usually the case with fresh versions of software, we advise clients to move forward judiciously. This...
  3. Percona Server Goodies
    I’m posting to describe some of the features and improvements that I have been utilizing with the Percona...
  4. OurSQL Episode 70: Table Manners, part 1
    We called this podcast table manners because we are often asked what MySQL fork to use. This is...
  5. MySQL Editions and Support- what do I get with community?
    The new licensing that was announced by Oracle earlier this month caused some FUD in the community that...

7 Responses to “MySQL Gotchas on Debian (and Ubuntu)”

  1. Monty Taylor 03. Dec, 2010 at 2:37 am #

    The debian-sys-maint user is another thing to be aware of – especially when configuring ha clusters and the like. The logrotate scripts use the debian-sys-maint user to log in and flush logs… so if you sync the mysql dir from another box, you want to make sure that /etc/mysql/debian.cnf carries the change as well.

    Are Oracle distributing debs now? I tried for about 2 years while I was at MySQL to get official apt repositories, but alas… you know how that goes. In Drizzle we avoid this problem by uploading to Debian ourselves. :)

  2. Daniël van Eeden 03. Dec, 2010 at 5:04 am #

    Is the “standard filesystem layout” documented anywhere?

  3. Norbert Tretkowski 03. Dec, 2010 at 5:06 am #

    Your first point was fixed a while ago during the lenny release-cycle. Today no one should still use etch or earlier releases.

    Your second point is a nice-to-have, especially when you understand how dpkg handles configuration files. No one forces you to use it, but everyone else on every other MySQL installation is also able to split out some configuration items into separate files. It’s possible since MySQL 5.0.4.

    And your third point, using syslog, is possible in MySQL since 5.1.20.

  4. snovotny 05. Dec, 2010 at 2:29 pm #

    Norbert, thanks for the further info!

    we still occasionally run into the mysql-start issue still on legacy systems that have been in production awhile without much attention.

    I agree that the include file is nifty, and we make extensive use of that sort of extension with other software packages. It’s just something that I think of as non-standard and has slowed us down occasionally.

    The same can be said of sending logs to syslog. It’s great in an infrastructure that uses remote syslogging. I was only calling it out because it differs from what i think of as a cannonical package (the MySQL.com RPM).

  5. snovotny 05. Dec, 2010 at 2:36 pm #

    Daniël

    There is documentation that MySQL provides that for standard filesystem layouts 5.0, 5.1, and 5.5.

    At Blue Gecko, we use the RPMs unless there is a very specific reason that we want or need to compile for a client.

  6. Gerry 06. Dec, 2010 at 2:34 pm #

    I have to say that the !include directive is very handy and we use it to automate our provisioning on CentOS 5 using the community RPMs.

    What annoys me to no end is all the utilities that instead of using ‘my_print_defaults’ or ‘show global variables’ or , go with the contents of my.cnf and miss the !include with the real settings all together. Example: MySQL Enterprise Backup (the utility previously known as InnoDB Hot Backup)

    My $.02 and a rant … sorry

  7. Jerome W. 17. Dec, 2010 at 2:13 pm #

    What would be the actual work of a distribution if all software were using the “cannonical package (the MySQL.com RPM)” as you call it.
    Even RedHat is not using their RPM.
    As far as those changes bring interesting features, or ease of use, do not break anything and are easy to identify, I say go!

Leave a Reply