Ad
More Related Content
What's hot (20)
Similar to MySQL 5.6 Global Transaction Identifier - Use case: Failover (20)
Ad
More from Ulf Wendel (7)
Ad
Recently uploaded (20)
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.
- 9. Availability improved, solved? Master failover improved! Scriptable, unattended failover possible No 3rd party solution required MySQL Master (was: Slave 1) MySQL Master … , GTID M:1: UPDATE x=1 … , GTID M:2: UPDATE x=9 … , GTID S:1: UPDATE x=0 MySQL Slave 2 … , GTID S:2: UPDATE x=9 … , GTID M:1: UPDATE x=1 … , GTID M:2: UPDATE x=9 … , GTID S:1: UPDATE x=0
- 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