Hi Alex. It seems that mysqld and all the client programs insist on reading /etc/my.cnf first.
To overide this behaviour for a particular instance of mysqld you need to pass the --defaults-file option as the FIRST parameter to mysqld_safe or mysqld if you are not using mysqld_safe. --defaults-extra-file=path The name of an option file to be read in addition to the usual option files. If given, this option must be first. --defaults-file=path The name of an option file to be read instead of the usual option files. If given, this option must be first. --no-defaults Do not read any option files. If given, this option must be first. More options are found in /usr/local/mysql-5.0.18/man/man1/mysqld_safe.1 I found this behaviour very annoying at first. But I now use this to my advantage. I have split my my.cnf file like this: /etc/my.cnf only has parameters used by mysql client programs. the my.cnf that lives in the mysqld installation directory only contains directives pertinent to that particular version of mysqld, and nothing there for the client programs. That way you have total control over all the parameters passed to all client programs in one central place, /etc/my.cnf. You do not have to worry about mysqld reading the wrong parameters for its invocation, because you have a seperate my.cnf just for that version of mysqld. I have written the following script to start a particular version of mysqld. This lives in /usr/local/mysql-<version>/bin/ #! /bin/sh # # start the MySQL database server /usr/local/mysql-5.0.18/bin/mysqld \ --defaults-file=/usr/local/mysql-5.0.18/my.cnf \ --port=xxxx \ --socket=/var/lib/mysql/mysql.sock \ --pid=/var/lib/mysql/laptop.pid \ --user=mysql \ --datadir=/var/lib/mysql & And this script gets called from /etc/init.d/boot.local when the machine boots up. /etc/init.d/halt.local calls the following script to shutdown the mysqld server gracefully. #! /bin/sh # # stop the MySQL database server /usr/local/mysql-5.0.18/bin/mysqladmin shutdown \ -usqlsuperuser -pxxxxxxxxxxxx \ --socket=/var/lib/mysql/mysql.sock The other advantage of passing parameters on the command-line to mysqld is that you can actually see, using a visual process manager like http://www.student.nada.kth.se/~f91-men/qps/ * if mysqld is running OK * what parameters you passed to mysqld, eg the port, socket, datadir etc, each mysqld is using * how many different versions of mysqld you have running I find this very helpfull when running two versions of mysqld at a time, eg testing a newer version against an already installed version, before removing the older version. HTH Keith In theory, theory and practice are the same; In practice they are not. On Mon, 13 Mar 2006, Alex Moore wrote: > To: mysql@lists.mysql.com > From: Alex Moore <[EMAIL PROTECTED]> > Subject: mysql5 options file location > > I am building mysql5 latest from source on Solaris. > > The location of the options file is very confusing and does not work > according to the online documentation. For example, I have --basedir > of /opt/csw/mysql5 and --datadir of /opt/csw/mysql5/var. If I put > my.cnf in datadir or in basedir, the file is not used. I am using > mysqld_safe to start mysqld. my.cnf options will only work if I put > the file in /etc/ > > './libexec/mysqld --verbose --help' returns: > Default options are read from the following files in the given order: > /etc/my.cnf ~/.my.cnf > > This is very different from my mysql4 builds from source, which include > the documented server-specific file listed after /etc/my.cnf > > How can I get mysql5 to use a server-specfic options file? Am I > missing a configure option or defines for mysql5? > > Thanks, > > Alex -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
