Note: This version of the VDT (1.10.1) is supported, but is not our latest stable release. The current stable release is 2.0.0.

MySQL

Why is the MySQL configuration so unusual?

The VDT installs MySQL as needed to support packages that use a database. Our goal is to make the VDT MySQL instance independent of any other existing or future MySQL instance on the same machine. That is, the VDT MySQL should neither affect with nor be affected by another MySQL.

To reach this goal, we had to make two, interrelated configuration changes to MySQL:

The VDT MySQL must run on its own Unix (filesystem) socket and TCP/IP port. This is a requirement for running multiple MySQL instances on a machine, regardless of other configuration settings. MySQL is configured to run on an alternative port instead of the standard port of 3306. For more information, see the MySQL documentation for running multiple servers.

The MySQL options for controlling connections are socket and port. These options may be specified on the command line for each MySQL program:
```
<mysql-executable> --port=<port> --socket=<socket> ...
```
However, to make sure that the options are used consistently, we put them in the VDT MySQL local option file:
```
[mysqld]
port=<port>
socket=<socket>
....
[client]
port=<port>
socket=<socket>
....
```
Note that the options must be set for both the MySQL server process (mysqld) and the client programs separately, because the [client] option group does not include mysqld.
The VDT MySQL must always read its local options file and no others, especially the global /etc/my.cnf options file. MySQL reads option settings from environment variables, option files, and command-line switches, in that order. Furthermore, there are up to four locations for options files, all of which are read if present. The first options file that is read is the global one at /etc/my.cnf.

We have encountered a problem when installing the VDT MySQL on systems that have a global options file for a newer version of MySQL. When the VDT MySQL starts up, it reads the global options file. If that file specifies options that do not exist in the VDT MySQL, it issues an error and quits immediately. While there are mechanisms for avoiding these sorts of conflicts, they all involve modifying the global options file, which we cannot count on doing. Thus, the VDT MySQL must not read the global options file.

For any MySQL command that reads options files, one can specify a --defaults-file switch to name the one and only options file to read at startup. We use this switch to avoid reading the global options file and to read the VDT options file instead.

However, the switch must be used whenever a MySQL command that reads options files is invoked. We cannot rely on all users and scripts doing so. Instead, we moved the actual MySQL commands to a directory that is not in the PATH environment variable. In their place, we created simple wrapper shell scripts that invoke the same-named MySQL commands, inserting the --defaults-file switch as the first argument. Although this approach may be cumbersome, it guarantees that users and scripts will get a correctly configured VDT MySQL.

Note that packages that communicate with MySQL using the MySQL client API (or JDBC, ODBC, etc.) must be configured separately to use the correct socket or port. This configuration is handled separately in those packages that require it.

Built Using OpenSSL

In the VDT , MySQL is built with SSL enabled. In order to have a consistent SSL library location and version, we build all of our SSL-enabled packages (including MySQL) against the version of OpenSSL that comes with Globus Toolkit .