MYSQLFAILOVER(1)                MySQL Utilities               MYSQLFAILOVER(1)



NAME
       mysqlfailover - Automatic replication failover

SYNOPSIS
       mysqlfailover [options]

DESCRIPTION
       This utility permits users to perform replication health monitoring and
       automatic failover on a replication topology consisting of a master and
       its slaves. The utility is designed to run interactively or
       continuously refreshing the health information at periodic intervals.
       Its primary mission is to monitor the master for failure and when a
       failure occurs, execute failover to the best slave available. The
       utility accepts a list of slaves to be considered the candidate slave.

       This utility is designed to work exclusively for servers that support
       global transaction identifiers (GTIDs) and have gtid_mode=ON. MySQL
       server versions 5.6.5 and higher support GTIDs. See Replication with
       Global Transaction Identifiers[1] for more information.

       The user can specify the interval in seconds to use for detecting the
       master status and generating the health report using the --interval
       option. At each interval, the utility will check to see if the server
       is alive via a ping operation followed by a check of the connector to
       detect if the server is still reachable. The ping operation can be
       controlled with the --ping option (see below).

       If the master is found to be offline or unreachable, the utility will
       execute one of the following actions based on the --failover-mode
       option value. The available values are:

       o   auto (default): Execute automatic failover to the list of
           candidates first and if no slaves are viable, continue to locate a
           viable candidate from the list of slaves. If no slaves are found to
           be a viable candidate, the utility will generate and error and
           exit.

           Once a candidate is found, the utility will conduct failover to the
           best slave. The command will test each candidate slave listed for
           the prerequisites. Once a candidate slave is elected, it is made a
           slave of each of the other slaves thereby collecting any
           transactions executed on other slaves but not the candidate. In
           this way, the candidate becomes the most up-to-date slave.

       o   elect: This mode is the same as auto, except if no candidates
           specified in the list of candidate slaves are viable, then it does
           not check the remaining slaves, and instead generates an error and
           then exits.

       o   fail: This mode produces an error and does not failover when the
           master is downed. This mode is used to provide periodic health
           monitoring without the failover action taken.

       For all options that permit specifying multiple servers, the options
       require a comma-separated list of connection parameters in the
       following form (where the password, port, and socket are optional).:

           <*user*>[:<*passwd*>]@<*host*>[:<*port*>][:<*socket*>] or
           <*login-path*>[:<*port*>][:<*socket*>]

       The utility permits users to discover slaves connected to the master.
       In order to use the discover slaves feature, all slaves must use the
       --report-host and --report-port startup variables to specify the
       correct hostname and port of the slave. If these are missing or report
       the incorrect information, the slave's health may not be reported
       correctly or the slave may not be listed at all. The discover slaves
       feature ignores any slaves to which it cannot connect.

       The discover slaves feature is run automatically on each interval.

       The utility permits the user to specify an external script to execute
       before and after the switchover and failover commands. The user can
       specify these with the --exec-before and --exec-after options. The
       return code of the script is used to determine success thus each script
       must report 0 (success) to be considered successful. If a script
       returns a value other than 0, the result code is presented in an error
       message.

       The utility also permits the user to specify a script to be used for
       detecting a downed master or an application-level event to trigger
       failover. This can be specified using the --exec-fail-check option. The
       return code for the script is used to invoke failover. A return code of
       0 indicates failover should not take place. A return code other than 0
       indicates failover should take place. This is checked at the start of
       each interval if a script is supplied. The timeout option is not used
       in this case and the script is run once at the start of each interval.

       The utility permits the user to log all actions taken during the
       commands. The --log option requires a valid path and file name of the
       file to use for logging operations. The log is active only when this
       option is specified. The option --log-age specifies the age in days
       that log entries are kept. The default is seven (7) days. Older entries
       are automatically deleted from the log file (but only if the --log
       option is specified).

       The format of the log file includes the date and time of the event, the
       level of the event (informational - INFO, warning - WARN, error -
       ERROR, critical failure - CRITICAL), and the message reported by the
       utility.

       The interface provides a number of options for displaying additional
       information. You can choose to view the replication health report
       (default), or choose to view the list of GTIDs in use, the UUIDs in
       use, or view the log file contents if logging is enabled. Each of these
       reports is described below.

       o   health Display the replication health of the topology. This report
           is the default view for the interface. By default, this includes
           the host name, port, role (MASTER or SLAVE) of the server, state of
           the server (UP = is connected, WARN = not connected but can ping,
           DOWN = not connected and cannot ping), the GTID_MODE, and health
           state.

           The master health state is based on the following: if GTID_MODE=ON,
           the server must have the binary log enabled, and a user must exist
           with the REPLICATE SLAVE privilege.

           The --seconds-behind option is used to detect when a slave is
           behind the master. It allows users to set a threshold for reporting
           purposes only. It does not apply to slave candidacy or selection
           during failover.

           The slave health state is based on the following: the IO_THREAD and
           SQL_THREADS must be running, it must be connected to the master,
           there are no errors, the slave delay for non-GTID enabled scenarios
           is not more than the threshold provided by the --max-position and
           the slave is reading the correct master log file, and slave delay
           is not more than the --seconds-behind threshold option.

           At each interval, if the discover slaves option was specified at
           startup and new slaves are discovered, the health report is
           refreshed.

       o   gtid: Display the master's list of executed GTIDs, contents of the
           GTID variables; @@GLOBAL.GTID_EXECUTED, @@GLOBAL.GTID_PURGED, and
           @@GLOBAL.GTID_OWNED. Thus, you can toggle through the four screens
           by pressing the 'G' key.

       o   UUID: Display universally unique identifiers (UUIDs) for all
           servers.

       o   Log: This option displays the contents of the log file, which only
           visible if the --log option is specified. This can be helpful to
           see when failover occurred, and which actions or messages were
           recorded at the time.

       The user interface is designed to match the size of the terminal window
       in which it is run. A refresh option is provided to permit users to
       resize their terminal windows or refresh the display at any time.
       However, the interface will automatically resize to the terminal window
       on each interval.

       The interface will display the name of the utility, the master's status
       including binary log file, position, and filters as well as the date
       and time of the next interval event.

       The interface will also permit the user to scroll up or down through a
       list longer than what the terminal window permits. When a long list is
       presented, the scroll options become enabled. The user can scroll the
       list up with the up arrow key and down with the down arrow key.

       Use the --verbose option to see additional information in the health
       report and additional messages during failover.

       The utility supports two modes of operation. The default mode, running
       as a console, works as described above. An additional mode that permits
       you to run the utility as a daemon is provided for POSIX platforms.

       When run as a daemon, the utility does not have interactivity. However,
       all events are written to the log file. You can control what is written
       to the log by using the --report-values option.

       To run the utility as a daemon, use the --daemon option. There are four
       commands that can be used in --daemon option. These include:

       o   start

           Starts the daemon. The --log option is required.

       o   stop

           Stops the daemon. If you used the option --pidfile, the value must
           be the same when starting the daemon.

       o   restart

           Restarts the daemon. If you used the option --pidfile, the value
           must be the same when starting the daemon.

       o   nodetach

           Starts the daemon, but it will not detach the process from the
           console. The --log option is required.
       OPTIONS.PP mysqlfailover accepts the following command-line options:

       o   --help

           Display a help message and exit.

       o   --license

           Display license information and exit.

       o   --candidates=<candidate slave connections>

           Connection information for candidate slave servers. Valid only with
           failover command. List multiple slaves in comma-separated list.

           To connect to a server, it is necessary to specify connection
           parameters such as user name, host name, password, and either a
           port or socket. MySQL Utilities provides a number of ways to
           provide this information. All of the methods require specifying
           your choice via a command-line option such as --server, --master,
           --slave, etc. The methods include the following in order of most
           secure to least secure.

           o   Use login-paths from your .mylogin.cnf file (encrypted, not
               visible). Example : <login-path>[:<port>][:<socket>]

           o   Use a configuration file (unencrypted, not visible) Note:
               available in release-1.5.0. Example :
               <configuration-file-path>[:<section>]

           o   Specify the data on the command-line (unencrypted, visible).
               Example : <user>[:<passwd>]@<host>[:<port>][:<socket>]


       o   --daemon=<command>

           Run as a daemon. The command can be start (start daemon), stop
           (stop daemon), restart (stop then start the daemon) or nodetach
           (start but do not detach the process). This option is only
           available for POSIX systems.

       o   --discover-slaves-login=<user:password>

           At startup, query master for all registered slaves and use the user
           name and password specified to connect. Supply the user and
           password in the form <user>[:<passwd>] or <login-path>. For
           example, --discover=joe:secret will use 'joe' as the user and
           'secret' as the password for each discovered slave.

       o   --exec-after=<script>

           Name of script to execute after failover or switchover. Script name
           may include the path.

       o   --exec-before=<script>

           Name of script to execute before failover or switchover. Script
           name may include the path.

       o   --exec-fail-check=<script>

           Name of script to execute on each interval to invoke failover.

       o   --exec-post-failover=<script>

           Name of script to execute after failover is complete and the
           utility has refreshed the health report.

       o   --failover-mode=<mode>, -f <mode>

           Action to take when the master fails. 'auto' = automatically fail
           to best slave, 'elect' = fail to candidate list or if no candidate
           meets criteria fail, 'fail' = take no action and stop when master
           fails. Default = 'auto'.

       o   --force

           Override the registration check on master for multiple instances of
           the console monitoring the same master. See notes.

       o   --interval=<seconds>, -i <seconds>

           Interval in seconds for polling the master for failure and
           reporting health. Default = 15 seconds. Minimum is 5 seconds.

       o   --log=<log_file>

           Specify a log file to use for logging messages

       o   --log-age=<days>

           Specify maximum age of log entries in days. Entries older than this
           will be purged on startup. Default = 7 days.

       o   --master=<connection>

           Connection information for the master server.

           To connect to a server, it is necessary to specify connection
           parameters such as user name, host name, password, and either a
           port or socket. MySQL Utilities provides a number of ways to
           provide this information. All of the methods require specifying
           your choice via a command-line option such as --server, --master,
           --slave, etc. The methods include the following in order of most
           secure to least secure.

           o   Use login-paths from your .mylogin.cnf file (encrypted, not
               visible). Example : <login-path>[:<port>][:<socket>]

           o   Use a configuration file (unencrypted, not visible) Note:
               available in release-1.5.0. Example :
               <configuration-file-path>[:<section>]

           o   Specify the data on the command-line (unencrypted, visible).
               Example : <user>[:<passwd>]@<host>[:<port>][:<socket>]


       o   --max-position=<position>

           Used to detect slave delay. The maximum difference between the
           master's log position and the slave's reported read position of the
           master. A value greater than this means the slave is too far behind
           the master. Default = 0.

       o   --pedantic, -p

           Used to stop failover if some inconsistencies are found, such as
           errant transactions on slaves or SQL thread errors, during server
           checks. By default, the utility only generates warnings if issues
           are found when checking a slave's status during failover, and it
           will continue its execution unless this option is specified.

       o   --pidfile=<pidfile>

           Pidfile for running mysqlfailover as a daemon. This file contains
           the PID (process identifier), that uniquely identifies a process.
           It is needed to identify and control the process forked by
           mysqlfailover.

       o   --ping=<number>

           Number of ping attempts for detecting a downed server. Default is 3
           seconds.

               Note
               On some platforms, this is the same as number of seconds to
               wait for ping to return.

       o   --report-values=<report_values>

           Report values used in mysqlfailover running as a daemon. It can be
           health, gtid or uuid. Multiple values can be used separated by
           commas.

           o   health

               Display the replication health of the topology.

           o   gtid

               Display the master's list of executed GTIDs, contents of the
               GTID variables; @@GLOBAL.GTID_EXECUTED, @@GLOBAL.GTID_PURGED
               and @@GLOBAL.GTID_OWNED.

           o   uuid

               Display universally unique identifiers (UUIDs) for all servers.

           Default = health.

       o   --rpl-user=:<replication_user>

           The user and password for the replication user requirement, in the
           form: <user>[:<password>] or <login-path>. E.g. rpl:passwd

           Default = None.

       o   --script-threshold=<return_code>

           Value for external scripts to trigger aborting the operation if
           result is greater than or equal to the threshold.

           Default = None (no threshold checking).

       o   --seconds-behind=<seconds>

           Used to detect slave delay (only for health reporting purposes).
           The maximum number of seconds behind the master permitted before
           slave is considered behind the master in the health report state.
           Default = 0.

       o   --slaves=<slave connections>

           Connection information for slave servers. List multiple slaves in
           comma-separated list. The list will be evaluated literally whereby
           each server is considered a slave to the master listed regardless
           if they are a slave of the master.

           To connect to a server, it is necessary to specify connection
           parameters such as user name, host name, password, and either a
           port or socket. MySQL Utilities provides a number of ways to
           provide this information. All of the methods require specifying
           your choice via a command-line option such as --server, --master,
           --slave, etc. The methods include the following in order of most
           secure to least secure.

           o   Use login-paths from your .mylogin.cnf file (encrypted, not
               visible). Example : <login-path>[:<port>][:<socket>]

           o   Use a configuration file (unencrypted, not visible) Note:
               available in release-1.5.0. Example :
               <configuration-file-path>[:<section>]

           o   Specify the data on the command-line (unencrypted, visible).
               Example : <user>[:<passwd>]@<host>[:<port>][:<socket>]


       o   --ssl-ca

           The path to a file that contains a list of trusted SSL CAs.

       o   --ssl-cert

           The name of the SSL certificate file to use for establishing a
           secure connection.

       o   --ssl-key

           The name of the SSL key file to use for establishing a secure
           connection.

       o   --ssl

           Specifies if the server connection requires use of SSL. If an
           encrypted connection cannot be established, the connection attempt
           fails. Default setting is 0 (SSL not required).

       o   --timeout=<seconds>

           Maximum timeout in seconds to wait for each replication command to
           complete. For example, timeout for slave waiting to catch up to
           master.

           Default = 3.

       o   --verbose, -v

           Specify how much information to display. Use this option multiple
           times to increase the amount of information. For example, -v =
           verbose, -vv = more verbose, -vvv = debug.

       o   --version

           Display version information and exit.
       NOTES.PP The login user must have the appropriate permissions for the
       utility to check servers and monitor their status (e.g., SHOW SLAVE
       STATUS, SHOW MASTER STATUS). The user must also have permissions to
       execute the failover procedure (e.g., STOP SLAVE, START SLAVE,
       WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS, CHANGE MASTER TO ...). Lastly, the
       user must have the REPLICATE SLAVE privilege for slaves to connect to
       their master. The same permissions are required by the failover utility
       for master and slaves in order to run successfully. In particular,
       users connected to slaves, candidates and master require SUPER, GRANT
       OPTION, REPLICATION SLAVE, RELOAD, DROP, CREATE, INSERT and SELECT
       privileges.

       The DROP, CREATE, INSERT and SELECT privileges are required to register
       the failover instance on the initial master or the new master (after a
       successful failover). Therefore, since any slave can become the new
       master, slaves and candidates also require those privileges. The
       utility checks permissions for the master, slaves, and candidates at
       startup.

       At startup, the console will attempt to register itself with the
       master. If another console is already registered, and the failover mode
       is auto or elect, the console will be blocked from running failover.
       When a console quits, it unregisters itself from the master. If this
       process is broken, the user may override the registration check by
       using the --force option.

       Mixing IP and hostnames is not recommended. The replication-specific
       utilities will attempt to compare hostnames and IP addresses as aliases
       for checking slave connectivity to the master. However, if your
       installation does not support reverse name lookup, the comparison could
       fail. Without the ability to do a reverse name lookup, the replication
       utilities could report a false negative that the slave is (not)
       connected to the master.

       For example, if you setup replication using MASTER_HOST=ubuntu.net on
       the slave and later connect to the slave with mysqlrplcheck and have
       the master specified as --master=192.168.0.6 using the valid IP address
       for ubuntu.net, you must have the ability to do a reverse name lookup
       to compare the IP (192.168.0.6) and the hostname (ubuntu.net) to
       determine if they are the same machine.

       Similarly, in order to avoid issues mixing local IP '127.0.0.1' with
       'localhost', all the addresses '127.0.0.1' will be internally converted
       to 'localhost' by the utility. Nevertheless, It is best to use the
       actual hostname of the master when connecting or setting up
       replication.

       The utility will check to see if the slaves are using the option
       --master-info-repository=TABLE. If they are not, the utility will stop
       with an error.

       The path to the MySQL client tools should be included in the PATH
       environment variable in order to use the authentication mechanism with
       login-paths. This will allow the utility to use the my_print_defaults
       tools which is required to read the login-path values from the login
       configuration file (.mylogin.cnf).

       The console creates a special table in the mysql database that is used
       to keep track of which instance is communicating with the master. If
       you use the --force option, the console will remove the rows in this
       table. The table is constructed with:

           CREATE TABLE IF NOT EXISTS mysql.failover_console (host char(30), port char(10))

       When the console starts, a row is inserted containing the hostname and
       port of the master. On startup, if a row matches these values, the
       console will not start. If you use the --force option, the row is
       deleted.

       When running the utility using the --daemon=nodetach option, the
       --pidfile option can be omitted. It will be ignored if used.

       When using the external scripts, the following parameters are passed in
       the order shown.

       For example, suppose you have a script named 'run_before.sh' and you
       specify that you want it executing before the failover is performed
       (using the --exec-before option). Further, let us assume the master
       MySQL Server is using port 3306 on the host `host1' and the MySQL
       Server that will become the new master is using port 3308 on host
       'can_host2'. The script would therefore be invoked in the following
       manner.

           % run_before.sh host1 3306 can_host2 3308

       Table 5.2. External Script Parameters
       +-------------------------+---------------------------+
       |MySQL Failover Option    | Parameters Passed to      |
       |                         | External Script           |
       +-------------------------+---------------------------+
       |--exec-before            | master host, master port, |
       |                         | candidate host, candidate |
       |                         | port                      |
       +-------------------------+---------------------------+
       |--exec-after             | new master host, new      |
       |                         | master port               |
       +-------------------------+---------------------------+
       |--exec-fail-check        | master host, master port  |
       +-------------------------+---------------------------+
       |--exec-post-failover (no | old master host, old      |
       |errors                   | master port, new master   |
       |              during     | host, new master port     |
       |failover)                |                           |
       +-------------------------+---------------------------+
       |--exec-post-failover     | old master host, old      |
       |(errors                  | master port               |
       |              during     |                           |
       |failover)                |                           |
       +-------------------------+---------------------------+
       EXAMPLES.PP To launch the utility, you must specify at a minimum the
       --master option and either the --discover-slaves-login option or the
       --slaves option. The --discover-slaves-login option can be used in
       conjunction with the --slaves option to specify a list of known slaves
       (or slaves that do not report their host and IP) and to discover any
       other slaves connected to the master.

       An example of the user interface and some of the report views are shown
       in the following examples.

           Note
           The "GTID Executed Set" will display the first GTID listed in the
           SHOW MASTER STATUS view. If there are multiple GTIDs listed, the
           utility shall display [...]  to indicate there are additional GTIDs
           to view. You can view the complete list of GTIDs on the GTID
           display screens.

       The default interface will display the replication health report like
       the following. In this example the log file is enabled. A sample
       startup command is shown below:

           shell> mysqlfailover --master=root@localhost:3331 --discover-slaves-login=root --log=log.txt
           MySQL Replication Monitor and Failover Utility
           Failover Mode = auto     Next Interval = Mon Mar 19 15:56:03 2012
           Master Information
           ------------------
           Binary Log File   Position  Binlog_Do_DB  Binlog_Ignore_DB
           mysql-bin.000001  571
           GTID Executed Set
           2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]
           Replication Health Status
           +------------+-------+---------+--------+------------+---------+
           | host       | port  | role    | state  | gtid_mode  | health  |
           +------------+-------+---------+--------+------------+---------+
           | localhost  | 3331  | MASTER  | UP     | ON         | OK      |
           | localhost  | 3332  | SLAVE   | UP     | ON         | OK      |
           | localhost  | 3333  | SLAVE   | UP     | ON         | OK      |
           | localhost  | 3334  | SLAVE   | UP     | ON         | OK      |
           +------------+-------+---------+--------+------------+---------+
           Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries

       Press Q to exit the utility, R to refresh the current display, and H
       returns to the replication health report.

       Press G key to show a GTID report similar to the following. The first
       page shown is the master's executed GTID set:

           MySQL Replication Monitor and Failover Utility
           Failover Mode = auto     Next Interval = Mon Mar 19 15:59:33 2012
           Master Information
           ------------------
           Binary Log File   Position  Binlog_Do_DB  Binlog_Ignore_DB
           mysql-bin.000001  571
           GTID Executed Set
           2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]
           Master GTID Executed Set
           +-------------------------------------------+
           | gtid                                      |
           +-------------------------------------------+
           | 2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7  |
           | 5503D37E-2DB2-11E2-A781-8077D4C14B33:1-3  |
           +-------------------------------------------+
           Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries Up|Down-scroll

       Continuing to press G key cycles through the three GTID lists.

       If the list is longer than the screen permits as shown in the example
       above, the scroll up and down help is also shown. In this case, press
       the down arrow key to scroll down.

       Press U to view the list of UUIDs used in the topology, for example:

           MySQL Replication Monitor and Failover Utility
           Failover Mode = auto     Next Interval = Mon Mar 19 16:02:34 2012
           Master Information
           ------------------
           Binary Log File   Position  Binlog_Do_DB  Binlog_Ignore_DB
           mysql-bin.000001  571
           GTID Executed Set
           2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]
           UUIDs
           +------------+-------+---------+---------------------------------------+
           | host       | port  | role    | uuid                                  |
           +------------+-------+---------+---------------------------------------+
           | localhost  | 3331  | MASTER  | 55c65a00-71fd-11e1-9f80-ac64ef85c961  |
           | localhost  | 3332  | SLAVE   | 5dd30888-71fd-11e1-9f80-dc242138b7ec  |
           | localhost  | 3333  | SLAVE   | 65ccbb38-71fd-11e1-9f80-bda8146bdb0a  |
           | localhost  | 3334  | SLAVE   | 6dd6abf4-71fd-11e1-9f80-d406a0117519  |
           +------------+-------+---------+---------------------------------------+
           Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries

       If, once the master is detected as down and failover mode is auto or
       elect and there are viable candidate slaves, the failover feature will
       engage automatically and the user will see the failover messages
       appear. When failover is complete, the interface returns to monitoring
       replication health after 5 seconds. The following shows an example of
       failover occurring.:

           Failover starting...
           # Candidate slave localhost:3332 will become the new master.
           # Preparing candidate for failover.
           # Creating replication user if it does not exist.
           # Stopping slaves.
           # Performing STOP on all slaves.
           # Switching slaves to new master.
           # Starting slaves.
           # Performing START on all slaves.
           # Checking slaves for errors.
           # Failover complete.
           # Discovering slaves for master at localhost:3332
           Failover console will restart in 5 seconds.

       After the failover event, the new topology is shown in the replication
       health report.:

           MySQL Replication Monitor and Failover Utility
           Failover Mode = auto     Next Interval = Mon Mar 19 16:05:12 2012
           Master Information
           ------------------
           Binary Log File   Position  Binlog_Do_DB  Binlog_Ignore_DB
           mysql-bin.000001  1117
           GTID Executed Set
           2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]
           UUIDs
           +------------+-------+---------+--------+------------+---------+
           | host       | port  | role    | state  | gtid_mode  | health  |
           +------------+-------+---------+--------+------------+---------+
           | localhost  | 3332  | MASTER  | UP     | ON         | OK      |
           | localhost  | 3333  | SLAVE   | UP     | ON         | OK      |
           | localhost  | 3334  | SLAVE   | UP     | ON         | OK      |
           +------------+-------+---------+--------+------------+---------+
           Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries

       Pressing L with the --log option specified causes the interface to show
       the entries in the log file, such as:

           MySQL Replication Monitor and Failover Utility
           Failover Mode = auto     Next Interval = Mon Mar 19 16:06:13 2012
           Master Information
           ------------------
           Binary Log File   Position  Binlog_Do_DB  Binlog_Ignore_DB
           mysql-bin.000001  1117
           GTID Executed Set
           2A67DE00-2DA1-11E2-A711-00764F2BE90F:1-7 [...]
           Log File
           +-------------------------+----------------------------------------- ... --+
           | Date                    | Entry                                    ...   |
           +-------------------------+----------------------------------------- ... --+
           | 2012-03-19 15:55:33 PM  | INFO Failover console started.           ...   |
           | 2012-03-19 15:55:33 PM  | INFO Failover mode = auto.               ...   |
           | 2012-03-19 15:55:33 PM  | INFO Getting health for master: localhos ...   |
           | 2012-03-19 15:55:33 PM  | INFO Master status: binlog: mysql-bin.00 ...   |
           +-------------------------+----------------------------------------- ... --+
           Q-quit R-refresh H-health G-GTID Lists U-UUIDs L-log entries Up|Down-scroll\

       PERMISSIONS REQUIRED.PP The user must have permissions to monitor the
       servers on the topology and configure replication to successfully
       perform the failover operation. Additional permissions are also
       required to register and unregister the running mysqlfailover instance
       on the master and slaves. Specifically, the login user must have the
       following privileges: SUPER, GRANT OPTION, REPLICATION SLAVE, RELOAD,
       DROP, CREATE, INSERT, and SELECT.

       The referred permissions are required for the login users used for all
       servers (master, slaves and candidates).

COPYRIGHT
       Copyright (C) 2006, 2015, Oracle and/or its affiliates. All rights
       reserved.

       This documentation is free software; you can redistribute it and/or
       modify it only under the terms of the GNU General Public License as
       published by the Free Software Foundation; version 2 of the License.

       This documentation is distributed in the hope that it will be useful,
       but WITHOUT ANY WARRANTY; without even the implied warranty of
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
       General Public License for more details.

       You should have received a copy of the GNU General Public License along
       with the program; if not, write to the Free Software Foundation, Inc.,
       51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA or see
       http://www.gnu.org/licenses/.


NOTES
        1. Replication with Global Transaction Identifiers
           http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html

SEE ALSO
       For more information, please refer to the MySQL Utilities and Fabric
       documentation, which is available online at
       http://dev.mysql.com/doc/index-utils-fabric.html

AUTHOR
       Oracle Corporation (http://dev.mysql.com/).



MySQL 1.5.6                       09/15/2015                  MYSQLFAILOVER(1)
