Data seem sometimes to have their own life and will, and they refuse to behave as we wish.
Then, you need a firm hand to tame the wild data and turn them into quiet and obeying pets.

Sunday, March 18, 2012

MySQL 5.6 too verbose when creating data directory

When I install a MySQL package using MySQL Sandbox, if everything goes smoothly, I get an informative message on standard output, and I keep working.

This is OK

$HOME/opt/mysql/5.5.15/scripts/mysql_install_db --no-defaults \
--user=$USER --basedir=$HOME/opt/mysql/5.5.15 \
--datadir=$HOME/sandboxes/msb_5_5_15/data \
--lower_case_table_names=2
Installing MySQL system tables...
OK
Filling help tables...
OK
To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/Users/gmax/opt/mysql/5.5.15/bin/mysqladmin -u root password 'new-password'
/Users/gmax/opt/mysql/5.5.15/bin/mysqladmin -u root -h gmac4.local password 'new-password'
Alternatively you can run:
/Users/gmax/opt/mysql/5.5.15/bin/mysql_secure_installation
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the manual for more instructions.
You can start the MySQL daemon with:
cd /Users/gmax/opt/mysql/5.5.15 ; /Users/gmax/opt/mysql/5.5.15/bin/mysqld_safe &
You can test the MySQL daemon with mysql-test-run.pl
cd /Users/gmax/opt/mysql/5.5.15/mysql-test ; perl mysql-test-run.pl
Please report any problems with the /Users/gmax/opt/mysql/5.5.15/scripts/mysqlbug script!

I can actually suppress this output, confident that, if something goes wrong, the error comes to my screen loud and clear. For example, if I try to install to a data directory that is write protected, I get this:

This, way, I know that there was an error, it is very clear and readable. I don't need to hunt it down within the regular messages. The standard error is a separate file descriptor, which can be read independently from the standard input.

Why is this bad? Because you don't see at a glance what is right and what is wrong. All the above messages are printed to the standard error, the kind of output that should be reserved for, well, errors! If the standard error is used for regular messages, you may miss the important error messages that are instead mixed with the "all is OK" messages.

There is Bug#60934 filed about this issue, but it has been considered a feature request, and as such unlikely to be fixed.

In the above text there is something more. There are warnings, mixed with the standard text, telling me of errors that the bootstrap operation is not in a position to fix, like replication metadata and slave_master_info.

MySQL developers, please fix this issue. Users need error messages when there is something wrong, and warning or error messages about something that can actually be fixed. When MySQL 5.6 goes GA, this issue will hit most everybody.

@anonymous,Let's try not to convert this discussion into a bicycle shed color debate.The issue here is that developers do this kind of thing because they need debugging information (it happened with the event scheduler, which was writing every event start and stop to the error log and was removed after popular outcry) and some of the developers don't try to put themselves in the DBA's shoes.So, ask any DBA if they consider useful to mix notices and errors, and see what you get.And ask anyone who needs to write a wrapper around the bootstrap to package MySQL for a specific installer, if they find this new "feature" useful, and see what kind of consensus you may get.

Maybe there is room for compromise.During install/bootstrap, maybe some of this information is extraneous. An obvious step here would be to cut back on the detailed shutdown information.(In normal operation this would be useful to users with large installations where shutting down can take a very long time.)For now, grep is the easy and obvious fix for normal operation, but recent servers have analogs of sql_print_error/info/warning() for use by plugins, so who knows what the future might hold once everything goes through a central facility?