Calling for all mysql_install_db feature requests

mysql_install_db is the program that is responsible for bootstrapping a fresh copy of MySQL and making sure all of the system tables are setup correctly. This program is usually invoked by other programs as part of installation, but in the case of .tar.gz downloads will need to be executed manually.

As part of our ongoing efforts to refactor and improve MySQL, we are looking at converting mysql_install_db from its current Perl script to a program written in C++. The aim of this change is to reduce external dependencies (Perl + a set of modules) and improve our cross-platform experience.

We plan for this transition to be mostly function neutral, but are open to feature requests for additional improvements as well.

Have you worked in packaging MySQL?
Do you have any suggestions on how mysql_install_db can be improved?
Please leave a comment, or get in touch!

Published by


I joined MySQL AB in 2006, left, and am now back at Oracle working on the MySQL team. I’ve also worked at Percona and InPowered.

  • Giuseppe Maxia

    Hi Morgan,

    Thanks for the feedback request.

    I have a few wishes for mysql_install_db:

    * The ability of disabling (or modifying the path) for $BASEDIR/my.cnf;

    * The ability of setting a path where .mysql_secret is created;

    * Compatibility between MySQL 5.6 and 5.7 about –random-passwords. MySQL 5.7 should support the option as a non-op, rather than suppressing it (what happened to the deprecation-and-removal-in-the-next-version routine?) so that DBAs can run “mysql_install_db –random-passwords” for both versions and get the same result.

    * The ability of deferring the configuration for InnoDB after the installation. Up to MySQL 5.5, mysql_install_db did not create innodb files, and thus it was safe to use innodb parameters at server start. Now we can’t do that, because the defaults may be different from the intended setup. This means that DBAs need to know at bootstrap time what setup they require, or else they have to perform extra operations before deploying the server (such as deleting innodb log files with “wrong” size.)

    In short, I would like mysql_install_db to be more mindful of deployments that require multiple instances, and avoid creating files in places that can’t be changed at run-time (such as $HOME/.mysql_secret, $BASEDIR/my.cnf).

    A last wish is about testing. This script, as far as I can see, is not used in the test suite. It shouldn’t be a big deal adding a test that runs the installer and checks the result. You could use MySQL::Sandbox for that purpose. It includes a test called ‘smoke test’, which I created when I was working in the MySQL team to make sure that mysql_install_db was safe to ship.

    Anyway, if mysql_install_db was tested to make sure that it works according to the installation procedure described in the official manual, we would have less usability issues.



    • hartmut holzgraefe

      * make the transition lesss painful / buggy than the recent .sh -> .pl one (wasn’t that, and all the pain involved, about being more cross platform, too 😉
      * now it will hurt even more that mysql_install_db is the only script in mysql-…/scripts and not in …/bin like all the other scripts that are part of the distribution?

    • These are great suggestions Giuseppe. Thank you for spending the time to write them.

  • This brings this (fixed, closed) bug to mind:
    The bottom line is that every tool should be scriptable. Especially those having to do with deployments. This should also make it easier to test the tools.

    And I also found this related bug:
    This bug has a valid point in that some scripts have to be converted to C/C++/exe files other ones can be made into a SQL file (like the innodb memcached install stuff).

    I think python can also be a valid option as that’s what’s being used in MySQL Utilities. Having a dependency on a runtime (perl and/or python) can ofcourse be difficult on some platforms. Let alone the different perl and/or python versions…but that can be solved in the java way by shipping the a interpreter with every application (Symantec also does that with many of the ex-Veritas products)

  • Include it in another binary (mysqld or mysql_upgrade for example)