Stephane Combaudon

Replication is used everywhere with MySQL. But applying writes in a single thread is often a bottleneck: replicas have a hard time keeping up with the master that can execute writes in parallel. Enter MySQL 5.6 and you can use several threads to apply writes on replicas as long as you have several schemas. MySQL 5.7 goes even further: by introducing a logical clock and by changing the scheduling logic, you can apply writes in parallel in a single schema.

Come to this session to learn all you need to be comfortable with multi-threaded replication.

Replication is used everywhere with MySQL. But applying writes in a single thread is often a bottleneck: replicas have a hard time keeping up with the master that can execute writes in parallel. Enter MySQL 5.6 and you can use several threads to apply writes on replicas as long as you have several schemas. MySQL 5.7 goes even further: by introducing a logical clock and by changing the scheduling logic, you can apply writes in parallel in a single schema.

The result is of course a much better replication throughput, but this feature also raises a lot of questions: - How does it work internally? - Does it play well with GTIDs? - How can you monitor replication status? - How do you recover from a replication error? - If you want to take a backup from a replica, how can you make sure you will get a consistent snapshot?

Come to this session to learn all you need to be comfortable with multi-threaded replication.

MySQL 5.6 introduced Global Transaction IDs to make the reconfiguration of replication straightforward. The key benefit is that you can instantly and reliably change your replication topology if a node goes down or if the current topology no longer fits your needs. But of course operating a GTID-based cluster brings new challenges: old habits no longer work, tools have changed, and new issues have appeared.

MySQL 5.6 introduced Global Transaction IDs to make the reconfiguration of replication straightforward. The key benefit is that you can instantly and reliably change your replication topology if a node goes down or if the current topology no longer fits your needs. But of course operating a GTID-based cluster brings new challenges: old habits no longer work, tools have changed, and new issues have appeared.

In this session, you will learn about using GTIDs in production, including: - How to execute the daily DBA tasks related to GTID-based replication, such as monitoring replication status or recovering from replication errors - The new options for high availability and the tools that can help you - What can go wrong when using GTIDs

Global Transaction IDs (GTIDs) are a new feature of MySQL 5.6 that can ease failover. Discover the benefits and challenges of GTIDs.

Replication has been used for a long time to provide high availability. However the traditional position-based replication has a serious drawback: a same transaction will never have the same position on two different servers. Reconfiguring replication is then difficult and error-prone, which is bad when you want to make failovers as graceful and reliable as possible.

Enter MySQL 5.6 and Global Transaction IDs (GTIDs): a transaction is guaranteed to have the same identifiers across all servers of a given replication topology. This opens up new ways to handle failover, for instance when used in combination with Oracle's MySQL Utilities.

But are GTIDs ready for production usage? How do you set up GTIDs and the MySQL Utilities to provide high availability and automatic failover to your replication cluster? What are the limitations of the MySQL Utilities? How do they compare to existing tools, for instance with MHA which is a robust and widely used tool?

Come to this session to get a sense of the benefits and challenges of the high-availability solutions available with MySQL 5.6.