(mysql.info.gz) Starting server

Info Catalog

(mysql.info.gz) Automatic start

(mysql.info.gz) Unix post-installation

 
 2.9.2.3 Starting and Troubleshooting the MySQL Server
 .....................................................
 
 If you have problems starting the server, here are some things you can
 try:
 
    * Specify any special options needed by the storage engines you are
      using.
 
    * Make sure that the server knows where to find the data directory.
 
    * Make sure the server can use the data directory.  The ownership and
      permissions of the data directory and its contents must be set
      such that the server can access and modify them.
 
    * Check the error log to see why the server doesn't start.
 
    * Verify that the network interfaces the server wants to use are
      available.
 
 
 Some storage engines have options that control their behavior.  You can
 create a `my.cnf' file and set startup options for the engines you plan
 to use.  If you are going to use storage engines that support
 transactional tables (`InnoDB', `BDB'), be sure that you have them
 configured the way you want before starting the server:
 
    * If you are using `InnoDB' tables, refer to the `InnoDB'-specific
      startup options.  In MySQL 3.23, you must configure `InnoDB'
      explicitly or the server will fail to start.  From MySQL 4.0 on,
      `InnoDB' uses default values for its configuration options if you
      specify none.   `InnoDB' configuration InnoDB configuration.
 
    * If you are using `BDB' (Berkeley DB) tables, you should familiarize
      yourself with the different `BDB'-specific startup options.  
      BDB start.
 
 
 When the `mysqld' server starts, it changes location to the data
 directory.  This is where it expects to find databases and where it
 expects to write log files. On Unix, the server also writes the pid
 (process ID) file in the data directory.
 
 The data directory location is hardwired in when the server is compiled.
 This is where the server looks for the data directory by default. If
 the data directory is located somewhere else on your system, the server
 will not work properly.  You can find out what the default path
 settings are by invoking `mysqld' with the `--verbose' and `--help'
 options.  (Prior to MySQL 4.1, omit the `--verbose' option.)
 
 If the defaults don't match the MySQL installation layout on your
 system, you can override them by specifying options on the command line
 to `mysqld' or `mysqld_safe'. You can also list the options in an
 option file.
 
 To specify the location of the data directory explicitly, use the
 `--datadir' option. However, normally you can tell `mysqld' the
 location of the base directory under which MySQL is installed and it
 will look for the data directory there.  You can do this with the
 `--basedir' option.
 
 To check the effect of specifying path options, invoke `mysqld' with
 those options followed by the `--verbose' and `--help' options.  For
 example, if you change location into the directory where `mysqld' is
 installed, and then run the following command, it will show the effect
 of starting the server with a base directory of `/usr/local':
 
      shell> ./mysqld --basedir=/usr/local --verbose --help
 
 You can specify other options such as `--datadir' as well, but note
 that `--verbose' and `--help' must be the last options.  (Prior to
 MySQL 4.1, omit the `--verbose' option.)
 
 Once you determine the path settings you want, start the server without
 `--verbose' and `--help'.
 
 If `mysqld' is currently running, you can find out what path settings
 it is using by executing this command:
 
      shell> mysqladmin variables
 
 Or:
 
      shell> mysqladmin -h HOST_NAME variables
 
 HOST_NAME is the name of the MySQL server host.
 
 If you get `Errcode 13' (which means `Permission denied') when starting
 `mysqld', this means that the access privileges of the data directory
 or its contents do not allow the server access.  In this case, you
 change the permissions for the involved files and directories so that
 the server has the right to use them.  You can also start the server as
 `root', but this can raise security issues and should be avoided.
 
 On Unix, change location into the data directory and check the
 ownership of the data directory and its contents to make sure the
 server has access. For example, if the data directory is
 `/usr/local/mysql/var', use this command:
 
      shell> ls -la /usr/local/mysql/var
 
 If the data directory or its files or subdirectories are not owned by
 the account that you use for running the server, change their ownership
 to that account:
 
      shell> chown -R mysql /usr/local/mysql/var
      shell> chgrp -R mysql /usr/local/mysql/var
 
 If the server fails to start up correctly, check the error log file to
 see if you can find out why.  Log files are located in the data
 directory (typically `C:\mysql\data' on Windows, `/usr/local/mysql/data'
 for a Unix binary distribution, and `/usr/local/var' for a Unix source
 distribution).  Look in the data directory for files with names of the
 form `HOST_NAME.err' and `HOST_NAME.log', where HOST_NAME is the name
 of your server host. (Older servers on Windows use `mysql.err' as the
 error log name.)  Then check the last few lines of these files.  On
 Unix, you can use `tail' to display the last few lines:
 
      shell> tail HOST_NAME.err
      shell> tail HOST_NAME.log
 
 The error log contains information that indicates why the server
 couldn't start.  For example, you might see something like this in the
 log:
 
      000729 14:50:10  bdb:  Recovery function for LSN 1 27595 failed
      000729 14:50:10  bdb:  warning: ./test/t1.db: No such file or directory
      000729 14:50:10  Can't init databases
 
 This means that you didn't start `mysqld' with the `--bdb-no-recover'
 option and Berkeley DB found something wrong with its own log files
 when it tried to recover your databases.  To be able to continue, you
 should move away the old Berkeley DB log files from the database
 directory to some other place, where you can later examine them.  The
 `BDB' log files are named in sequence beginning with `log.0000000001',
 where the number increases over time.
 
 If you are running `mysqld' with `BDB' table support and `mysqld' dumps
 core at startup, this could be due to problems with the `BDB' recovery
 log.  In this case, you can try starting `mysqld' with
 `--bdb-no-recover'.  If that helps, then you should remove all `BDB'
 log files from the data directory and try starting `mysqld' again
 without the `--bdb-no-recover' option.
 
 If either of the following errors occur, it means that some other
 program (perhaps another `mysqld' server) is using the TCP/IP port or
 Unix socket file that `mysqld' is trying to use:
 
      Can't start server: Bind on TCP/IP port: Address already in use
      Can't start server: Bind on unix socket...
 
 Use `ps' to determine whether you have another `mysqld' server running.
 If so, shut down the server before starting `mysqld' again.  (If
 another server is running, and you really want to run multiple servers,
 you can find information about how to do so in  Multiple
 servers.)
 
 If no other server is running, try to execute the command `telnet
 your-host-name tcp-ip-port-number'.  (The default MySQL port number is
 3306.) Then press Enter a couple of times.  If you don't get an error
 message like `telnet: Unable to connect to remote host: Connection
 refused', some other program is using the TCP/IP port that `mysqld' is
 trying to use.  You'll need to track down what program this is and
 disable it, or else tell `mysqld' to listen to a different port with the
 `--port' option.  In this case, you'll also need to specify the port
 number for client programs when connecting to the server via TCP/IP.
 
 Another reason the port might be inaccessible is that you have a
 firewall running that blocks connections to it. If so, modify the
 firewall settings to allow access to the port.
 
 If the server starts but you can't connect to it, you should make sure
 that you have an entry in `/etc/hosts' that looks like this:
 
      127.0.0.1       localhost
 
 This problem occurs only on systems that don't have a working thread
 library and for which MySQL must be configured to use MIT-pthreads.
 
 If you can't get `mysqld' to start, you can try to make a trace file to
 find the problem by using the `--debug' option.   Making trace
 files.
 
  Windows troubleshooting, for more information on troubleshooting
 Windows installations.
 

Info Catalog

(mysql.info.gz) Automatic start

(mysql.info.gz) Unix post-installation