PowerPoint-Prsentation

Ulf Wendel, Oracle

MySQL 5.6, PECL/mysqlnd_ms 1.3

MySQL 5.6
Global Transaction Ids
Use case: Failover

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.

Primary copy (master/slave) for read-scale out

Writes/updates: master

Reads: slaves

MySQL Replication

MySQL MasterLog 7, Pos 34: UPDATE x=1Log 7, Pos 35: UPDATE x=9MySQL Slave 1MySQL Slave 2Log 8, Pos 1: UPDATE x=1

Log 2, Pos 1: UPDATE x=1Log 2, Pos 2: UPDATE x=9

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.

Slave to master promotion after master outage

Which slave is the most current?

How to copy transactions from S1 to S2?

Using GTIDs for master failover

MySQL MasterLog 7, Pos 34: UPDATE x=1Log 7, Pos 35: UPDATE x=9MySQL Slave 1MySQL Slave 2Log 8, Pos 1: UPDATE x=1

Log 2, Pos 1: UPDATE x=1Log 2, Pos 2: UPDATE x=9

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.

Combination of server id and sequence number

Emulation: PECL/mysqlnd_ms 1.2, MySQL Proxy

Built-in: MySQL 5.6

Global transaction identifier

MySQL MasterLog 7, Pos 34, GTID M:1: UPDATE x=1Log 7, Pos 35, GTID M:2: UPDATE x=9MySQL Slave 1MySQL Slave 2 , GTID M:1: UPDATE x=1

, GTID M:1: UPDATE x=1 , GTID M:2: UPDATE x=9

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.

Master failover improved!

Scriptable, unattended failover possible

No 3rd party solution required

Availability improved, solved?

MySQL MasterMySQL Master (was: Slave 1)MySQL Slave 2 , GTID M:1: UPDATE x=1 , GTID M:2: UPDATE x=9 , GTID S:1: UPDATE x=0 , GTID S:2: UPDATE x=9 , GTID M:1: UPDATE x=1 , GTID M:2: UPDATE x=9 , GTID S:1: UPDATE x=0

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?

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 failover

MySQL MasterMySQL Slave

MySQL Slave

PECL/mysqlnd_msFail... over

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?

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 deployment

MySQL MasterMySQL Slave

MySQL Slave

PECL/mysqlnd_msWhere to fail over?

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.

GTID Use case #2: consistency

Session consistency (read-your-writes)

PECL/mysqlnd_ms 1.2 and above

In the next slide set...

THE END

Contact: ulf.wendel@oracle.com