Ubuntu Manpage: mysqlfailover - Automatic replication master failover

Provided by: mysql-utilities_1.6.4-1build1_all

NAME

       mysqlfailover - Automatic replication master failover

SYNOPSIS

       mysqlfailover [options]

DESCRIPTION

This utility permits users to perform replication health monitoring and automatic failover
on a replication topology consisting of a single master and its slaves. The utility is
designed to run interactively or continuously refreshing the health information and
checking the master status at periodic intervals. Its primary mission is to monitor the
master for failure and when a failure occurs, execute failover to one of the slaves that
is in a valid state. The utility accepts an optional list of slaves to be considered for
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. Thus,
this utility will not work with anonymous replication servers (binary log + position).

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:

· auto (default): Execute automatic failover to the list of candidates first and if no
slaves are viable, continue to search the remaining slaves for a viable candidate. 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. If no slave is found to be a viable
candidate, the utility will generate an error and exit.

· 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. Use this option to force failover to one or more
specific slaves using the --candidates option.

· fail: This mode produces an error and does not failover when the master is detected as
down or unreachable. 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 for the slave 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 found and thus not listed in the health report. The
discover slaves feature ignores any slaves to which it cannot connect.

Note
If you have one or more slaves which do not report their hostname and port and should
a failover event occur, those slaves will not be included in the resulting topology.
That is, they will not become a slave of the new master. Be sure to check that all of
your slaves are accounted for in the health report before relying on the utility for
complete automatic failover.

The discover slaves feature is run automatically on each interval.

Furthermore, it is required that slaves use the --master-info-repository=TABLE startup
setting.

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. 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 filename 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.

· 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.

· 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.

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

· 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. MODES OF OPERATION.PP 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:

· start

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

· stop

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

· restart

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

· 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:

· --help

Display a help message and exit.

· --license

Display license information and exit.

· --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 the
user name, host name, password, and either a port or socket. MySQL Utilities provides
a number of ways to supply 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.

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

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

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

· --connection-timeout=<seconds>

Set the connection timeout for TCP and Unix socket connections for all master, slaves,
and candidate slaves specified. This changes the connection timeout for the
Connector/Python connection to the server. The default is 10 seconds as defined in the
Connector/Python library. This setting may be helpful for installations with low
network and server reliability.

· --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.

· --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.

· --exec-after=<script>

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

· --exec-before=<script>

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

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

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

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

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

· --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'.

· --force

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

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

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

· --log=<log_file>

Specify a log file to use for logging messages

· --log-age=<days>

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

· --master=<connection>

Connection information for the master server.

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

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

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

· --master-fail-retry=<seconds>

Time in seconds to wait to determine if the master is down. The failover check will be
run again when the retry delay expires. Can be used to introduce a longer period
between when master is detected as unavailable to declaring it down. This option is
not used with --exec-fail-check option.

Note
This option was added in MySQL Utilities 1.6.4.

· --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.

· --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.

· --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.

· --ping=<number>

Number of seconds between ping attempts. Exactly 3 ping operations are attempted, one
every --ping seconds. The default --ping value is 3.

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

· --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.

· health

Display the replication health of the topology.

· gtid

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

· uuid

Display universally unique identifiers (UUIDs) for all servers.

Default = health.

· --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.

· --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).

· --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.

· --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.

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

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

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

· --ssl-ca

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

· --ssl-cert

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

· --ssl-key

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

· --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).

· --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.

· --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.

· --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.

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).

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.

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.3. 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 errors │ old master host, old master │
│ during failover) │ port, new master host, new │
│ │ master port │
├────────────────────────────────┼──────────────────────────────────┤
│--exec-post-failover (errors │ old master host, old 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:

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\

LIMITATIONS.PP When the --master-fail-retry option is used, and the value specified
exceeds the value of the --interval option, it is possible for an interval event to be
delayed if the master retry check is still processing. In this case, should the master not
be down, the next interval will occur immediately after the check of the master is
complete. 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 © 2006, 2016, 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.7/en/replication-gtids.html

AUTHOR

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

NAME

SYNOPSIS

DESCRIPTION

COPYRIGHT

NOTES

SEE ALSO

AUTHOR