The document discusses how global transaction IDs (GTIDs) and PECL/mysqlnd_ms can improve MySQL replication and failover capabilities. GTIDs allow for easier identification of the most up-to-date transactions during failover. PECL/mysqlnd_ms can fail over client connections transparently when errors occur. While GTIDs and PECL/mysqlnd_ms improve availability, changes to the replication topology still require deploying updates to client configurations.
MySQL 5.6 Global Transaction Identifier - Use case: Failover
1. Ulf Wendel, Oracle
MySQL 5.6
Global Transaction Ids
Use case: Failover
MySQL 5.6, PECL/mysqlnd_ms 1.3
2. The speaker says...
It is all about MySQL Replication. MySQL Replication is the
database scale-out solution of the LAMP stack. MySQL
Replication is using lazy primary copy (master/slave).
Built-in global transaction identifier of MySQL 5.6
make server failover semi-automatic.
PECL/mysqlnd_ms features connection failover since
1.0, comes with a client-side emulation of global
transaction identifier since 1.2, supports the use of
the MySQL 5.6 built-in global transaction identifier
since 1.3 (under development) but goes beyond the
failover aspect. In this slide set – use case #1 failover.
3. MySQL Replication
Primary copy (master/slave) for read-scale out
Writes/updates: master
Reads: slaves
MySQL Master
Log 7, Pos 34: UPDATE x=1
Log 7, Pos 35: UPDATE x=9
MySQL Slave 1 MySQL Slave 2
Log 2, Pos 1: UPDATE x=1 Log 8, Pos 1: UPDATE x=1
Log 2, Pos 2: UPDATE x=9
4. The speaker says...
Use case #1: Master failover.
In a MySQL Replication setup all writes/updates must be
executed at the master. PECL/mysqlnd_ms, a transparent
plugin for the PHP mysqlnd library, does the necessary R/W
split for you.
The master logs all updates. Slaves read the updates
and replay them. Slaves copy updates from the
primary, thus the name primary copy. The copy
process is asynchronous. Replicas may lag behind. There is
one master – it is a single point of failure.
5. Using GTIDs for master failover
Slave to master promotion after master outage
Which slave is the most current?
How to copy transactions from S1 to S2?
MySQL Master
Log 7, Pos 34: UPDATE x=1
Log 7, Pos 35: UPDATE x=9
MySQL Slave 1 MySQL Slave 2
Log 2, Pos 1: UPDATE x=1 Log 8, Pos 1: UPDATE x=1
Log 2, Pos 2: UPDATE x=9
6. The speaker says...
The master fails, it becomes unavailable alltogether. A slave
must be promoted to become the new master.
It is hard to tell which slave has the latest
transactions. Transactions are referenced by log file
offsets. The highest log position does not necessarily
the refer to the latest transaction.
Identification of transactions is hard. Log positions cannot
be compared among replicas because different log
file settings may result in different offsets. For
example, two replicas may use different setting for log
rotation.
7. Global transaction identifier
Combination of server id and sequence number
Emulation: PECL/mysqlnd_ms 1.2, MySQL Proxy
Built-in: MySQL 5.6
MySQL Master
Log 7, Pos 34, GTID M:1: UPDATE x=1
Log 7, Pos 35, GTID M:2: UPDATE x=9
MySQL Slave 1 MySQL Slave 2
… , GTID M:1: UPDATE x=1 … , GTID M:1: UPDATE x=1
… , GTID M:2: UPDATE x=9
8. The speaker says...
A global transaction identifier is a cluster-wide
unique transaction identifier. MySQL 5.6 can generate it
automatically. MySQL Proxy and PECL/mysqlnd_ms 1.2
feature client-side emulations for use with any MySQL
version.
The sequence number makes it easy to identify the
latest transactions for a given master. This helps to
identify the most current slave. Because it is now easy
to uniquely identify a transaction it is clear Slave 1 should
be the new master. Slave 2 becomes a slave of Slave 1.
Slave 2 continues replication with transaction M:2.
10. The speaker says...
The introduction of GTIDs is a milestone towards improving
the availability of a MySQL Replication cluster. The MySQL
5.6 Reference manual will give details, including some
limitations of GTIDs.
The client side has not been considered yet. How to
handle connection failures, how to handle permanent
server failures?
11. PECL/mysqlnd_ms failover
Slave connection failover is easy...
Catch error, rerun statement, plugin picks next server
Connection handle remains useable
Automatic (no error) mode exists (not recommended)
PECL/mysqlnd_ms
Fail... … over
MySQL Master MySQL Slave MySQL Slave
12. The speaker says...
Failing over a read-only client connection to a slave
is easy. In case of an error PECL/mysqlnd_ms can either
silently failover to the next slave or master or, the plugin
returns an error. Automatic and silent failover is not
recommended as connection state is lost. Instead,
applications should catch the error, handle the failed
transaction and rerun their transaction. Upon execution of
the next statement, PECL/mysqlnd_ms fails over to another
server. The connection handle remains valid and useable.
Failover in a single master primary copy cluster is
impossible: where to sent the write?
13. PECL/mysqlnd_ms deployment
Cluster topology change requires deployment
Client configuration lists servers and roles
Slave to master promotion requires deployment
Addition or removal of slave requires deployment
PECL/mysqlnd_ms
Where to fail over?
MySQL Master MySQL Slave MySQL Slave
14. The speaker says...
Load balancers, including those load balancers that are part
of the driver, must be reconfigured after cluster topology
has changed (membership, roles).
Deploy the PECL/mysqlnd_ms configuration as part
of your slave to master promotion! The load balancer
configuration update should be done after the cluster has
been reconfigured and the new master is in place.
15. In the next slide set...
GTID Use case #2: consistency
Session consistency (read-your-writes)
PECL/mysqlnd_ms 1.2 and above
