MySQL Instance Manager has been deprecated and is removed in MySQL 5.5.
This section discusses how Instance Manager starts server instances when it starts. However, before you start Instance Manager, you should set up a password file for it. Otherwise, you will not be able to connect to Instance Manager to control it after it starts. For details about creating Instance Manager accounts, see Section 188.8.131.52, “Instance Manager User and Password Management”.
On Unix, the mysqld MySQL database server
normally is started with the mysql.server
script, which usually resides in the
/etc/init.d/ folder. That script invokes the
mysqld_safe script by default. However, you
can use Instance Manager instead if you modify the
/etc/my.cnf configuration file by adding
use-manager to the
Before MySQL 5.1.12, Instance Manager always tries to start at
least one server instance: When it starts, it reads its
configuration file if it exists to find server instance sections
and prepare a list of instances. Instance sections have names of
N is an unsigned integer (for
[mysqld2], and so forth).
After preparing the list of instances, Instance Manager starts
the guarded instances in the list. If there are no instances,
Instance Manager creates an instance named
mysqld and attempts to start it with default
(compiled-in) configuration values. This means that the Instance
Manager cannot find the mysqld program if it
is not installed in the default location.
(Section 2.1.4, “Installation Layouts”, describes default
locations for components of MySQL distributions.) If you have
installed the MySQL server in a nonstandard location, you should
create the Instance Manager configuration file.
The startup behavior just described is similar to that of mysqld_safe, which always attempts to start a server. However, it lacks the flexibility required for some operations because it is not possible to run Instance Manager in such a way that it refrains from starting any server instances. For example, you cannot invoke Instance Manager for the purpose of configuring an instance without also starting it (a task that a MySQL installer application might want to perform). Consequently, MySQL 5.1.12 introduces the following changes:
A new option,
may be used to cause Instance Manager to run with startup
behavior similar to that used before MySQL 5.1.12: If
Instance Manager finds a
instance section in the configuration file, it will start
it. If Instance Manager finds no
section, it creates one using default configuration values,
[mysqld] section to the
configuration file if it is accessible, and starts the
mysqld instance. Instance Manager also
starts any other guarded instances listed in the
Instance Manager reads its configuration file if it exists
and starts instances for any guarded instance sections that
it finds. If there are none, it starts no instances.
Instance Manager also stops all guarded server instances when it shuts down.
The permissible options for
instance sections are described in
Section 184.108.40.206, “MySQL Instance Manager Configuration Files”. In these
sections, you can use a special
option that is recognized only by Instance Manager. Use this
option to let Instance Manager know where the
mysqld binary resides. If there are multiple
instances, it may also be necessary to set other options such as
port, to ensure
that each instance has a different data directory and TCP/IP
port number. Section 5.3, “Running Multiple MySQL Instances on One Machine”, discusses the
configuration values that must differ for each instance when you
run multiple instance on the same machine.
[mysqld] instance section, if it
exists, must not contain any Instance Manager-specific
The typical Unix startup/shutdown cycle for a MySQL server with the MySQL Instance Manager enabled is as follows:
The /etc/init.d/mysql script starts MySQL Instance Manager.
Instance Manager starts the guarded server instances and monitors them.
If a server instance fails, Instance Manager restarts it.
If Instance Manager is shut down (for example, with the /etc/init.d/mysql stop command), it shuts down all server instances.