ocf:mysql — Manages a MySQL database instance
[OCF_RESKEY_binary=string] [OCF_RESKEY_client_binary=string] [OCF_RESKEY_config=string] [OCF_RESKEY_datadir=string] [OCF_RESKEY_user=string] [OCF_RESKEY_group=string] [OCF_RESKEY_log=string] [OCF_RESKEY_pid=string] [OCF_RESKEY_socket=string] [OCF_RESKEY_test_table=string] [OCF_RESKEY_test_user=string] [OCF_RESKEY_test_passwd=string] [OCF_RESKEY_enable_creation=integer] [OCF_RESKEY_additional_parameters=string] [OCF_RESKEY_replication_user=string] [OCF_RESKEY_replication_passwd=string] [OCF_RESKEY_replication_port=string] [OCF_RESKEY_max_slave_lag=integer] [OCF_RESKEY_evict_outdated_slaves=boolean] mysql [start | stop | status | monitor | monitor | monitor | promote | demote | notify | validate-all | meta-data]
Resource script for MySQL. May manage a standalone MySQL database, a clone set with externally managed replication, or a complete master/slave replication setup.
Location of the MySQL server binary
Location of the MySQL client binary
Configuration file
Directory containing databases
User running MySQL daemon
Group running MySQL daemon (for logfile and directory permissions)
The logfile to be used for mysqld.
The pidfile to be used for mysqld.
The socket to be used for mysqld.
Table to be tested in monitor statement (in database.table notation)
MySQL test user
MySQL test user password
If the MySQL database does not exist, it will be created
Additional parameters which are passed to the mysqld on startup. (e.g. --skip-external-locking or --skip-grant-tables)
MySQL replication user. This user is used for starting and stopping MySQL replication, for setting and resetting the master host, and for setting and unsetting read-only mode. Because of that, this user must have SUPER, REPLICATION SLAVE, REPLICATION CLIENT, and PROCESS privileges on all nodes within the cluster.
MySQL replication password. Used for replication client and slave.
The port on which the Master MySQL instance is listening.
The maximum number of seconds a replication slave is allowed to lag behind its master. Do not set this to zero. What the cluster manager does in case a slave exceeds this maximum lag is determined by the evict_outdated_slaves parameter.
If set to true, any slave which is more than max_slave_lag seconds behind the master has its MySQL instance shut down. If this parameter is set to false in a primitive or clone resource, it is simply ignored. If set to false in a master/slave resource, then exceeding the maximum slave lag will merely push down the master preference so the lagging slave is never promoted to the new master.