I am about to give a talk at MySQL Connect about what you need to know before upgrading to MySQL 5.6.

The PDF slides are online at http://bit.ly/upgrade56. I will be posting a video in the next few weeks!

On the new milestone release MySQL 5.7.2, we did some optimizations  on binlog lock and dump thread. Major dump thread code was re-written: Some code never reached was removed; Complex
logic was simplified; Code became more readable. But I don't want to introduce the refactoring here. Today, I would like to introduce you the optimization on binlog lock which improved master throughput.
Background binlog lock(LOCK_log) is a mutex which is used to protect binlog read and write operations. With this mutex, binlog read and write operations are safe. But it has limited concurrency. Not only can dump threads and user sessions not read and write binlog simultaneously but even the dump threads themselves cannot read the binlog simultaneously.  All other sessions have to wait whenever one session …

Semi-synchronous replication is used by many users who want improved data integrity. Today I would like to introduce a semi-synchronous new feature  on MySQL 5.7.2 milestone release which enhances the data integrity between master and slave. 
Wait Slave Acknowledgement before Engine Commit As you know, with semi-synchronous replication enabled, user sessions will wait for acknowledgement from a slave before committing the transaction. To enhance data integrity, this feature makes transaction sessions wait a little bit earlier than MySQL 5.5 and MySQL 5.6. The wait happens just before the server commits to storage engine.

With this feature, semi-synchronous replication is able to guarantee:

• All committed transaction are already replicated to at least …

As Tomas announced in his keynote at MySQL Connect 2013, we are working on a brand new product called MySQL Fabric. Along with this release of MySQL Fabric, we are releasing Connector/J 5.1.26 with Fabric support on labs.mysql.com. This is an alpha-quality release that adds support for scalability features in MySQL Fabric. Sharding and read/write splitting are the initial features supported by Connector/J.
In a setup involving read/write splitting or customized sharding, we generally have to duplicate knowledge of this configuration in the client applications. This is done in connection strings specified in configuration files or directly in code. With MySQL Fabric, we can express our system-wide configuration of database servers in a way that it can be accessed by client applications. In cases where this needs to change (and it always does..), the configurations affecting client applications no longer need to be changed. The connector will …

MySQL-5.6 was our best release ever and we are happy to see people praising it. This motivates us to work even harder for our next release. MySQL-5.7.2 DMR is out and we have already got a number of MySQL replication features. Below is a list of these features:

    - mysqlbinlog idempotent mode
    - mysqlbinlog --rewrite-db option
    - Dump thread does not take binary log lock
    - …

Introduction Enterprises often start with a single server setup.

As the enterprise grows, so does the data and the number of requests for the data. Using a single server setup makes it difficult to manage the increasing load. This creates the requirement to scale out.
One solution would be to replicate to read servers. The writes go to the master and the reads go to the slaves.
  Although this setup handles the increased read load, it still cannot handle the increasing write load. Trying to handle this by adding another master just compounds the problem. The write load must be repeated on every master (more work for the application and each master is just as busy as if …

As you saw on the keynote, we are introducing an integrated framework for managing farms of MySQL servers with support for both high-availability and sharding. It should be noted that this is a very early alpha and that it at this point is not ready for production use.

MySQL Fabric is an integrated system for managing a collection of MySQL servers and is the framework on which high-availability and sharding is built. MySQL Fabric is open-source and is intended to be extensible, easy to use, and support procedure execution even in the presence of failure, an execution model we call resilient execution.

To ensure high-availability, it is necessary to have redundancy in the system. For database systems, the redundancy traditionally takes the form of having a primary server acting as a master and using replication to keep secondaries available to take over in case the primary fails. This means that the "server" …

With today’s announcement of the second MySQL 5.7 Development Milestone Release and a new labs release it’s a very exciting time for MySQL Replication. MySQL 5.6 contained a lot of new content to make replication faster, easier to use and more reliable (Global Transaction Identifiers, Multi-Threaded Slaves, Binary Log Group Commit, Optimized Row Based Replication, Crash Safe Replication, Replication Event Checksums, Time Delayed Replication & Informational Logs) and now we want to improve things even further.

The new DMR has something for everyone.

With the improvements to Semi-Synchronous Replication, the application developer can be confident that when a transaction has been …

MySQL Replication is based on a master-slave architecture, where updates on the master are propagated to the slave through binary log events via a communication channel (aka a network connection). A slave would have been able to connect to only a single master at a time. If a slave wanted to receive updates from several masters, there were a few choices possible:

1. Time sharing replication, where a slave would connect to a master for a particular time slice.   (See, Mats blog here )
2. Have a hierarchical replication, where a slave that is to receive updates from the several masters is at the end of replication hierarchy. ( Like, M1->M2->M3->Slave)
3. Using several instances of mysqlbinlog + GTIDs. (See Luis blog   …

Yes, we've done it! ;-)

Tomas just announced we've reached 500K QPS performance level in OLTP_RO Point-Selects 8-tables benchmark, and I may only confirm it and say you little bit more:

This is the best-to-best comparison between the all listed engines obtained on the same 32cores-HT server that I've used in my previously published benchmark results. Same workload, same conditions, updated players. All details about this and other tests results I'll provide during my tomorrow's talk at MySQL Connect conference (11:30AM), and then later publish them within another blog post..

Well, what else to say.. - MySQL 5.7 is preparing to become the next …