Introduction
Having written an application to work with an unsharded MySQL setup, how do we migrate the application to a sharded setup ?

The above problem can be divided into two parts

• Migrating the MySQL Store (with minimum disruption to ongoing transactions)
• Migrating the Application.

This blog deals with the first problem of migrating the MySQL Store. The second problem of migrating the application will be handled in a separate blog post, and we shall assume for now that we just replace the old unsharded non-Fabric aware application with the new Fabric aware application.


  Most enterprises start with a single server setup to develop a prototype and later realize that they need to scale. This …

Day one of MySQL Connect day 1 was a great day of technical information.

Hands-On Lab

Tomas gave another stunning keynote that covered 5.6, 5.7 and covered new innovations like the Fabric sharding software.

I sat in on a hands-on session to learn the tricks of how to run explain on another process.

Davi from Linkedin gave an amazing talk on InnoDB internals that I missed due to being in a great session on Fabric.

The evening reception was a great chance to see old friends, make new ones, and enjoy the MySQL Community.

…

In the previous post, we had a look at the Performance Schema tables to monitor MySQL replication. We discussed why these were needed, what advantages they have to offer and what each table stands for. We also did a small exercise to see how one can select a particular table given the data that is needed. We will now dive deeper and look at the individual tables to understand what fields they are made of. We will also go through different scenarios to see how the different pieces of data can be used.

Note that these tables report the status/configuration of a replication slave. So, these are empty at the master server or at a standalone server. All the SELECTs we will talk of, are done at the slave. Lets take the tables one by one and go through them.

…

MySQL Fabric was officially introduced during Tomas his keynote at MySQL Connect 2013. MySQL Fabric will help you managing lots of MySQL server supporting both high-availability and sharding. Just like Connector/J, MySQL Connector/Python v1.1.1 Alpha has support for MySQL Fabric on MySQL Labs. Note that the MySQL Fabric as well as support for it in Connector/Python is Alpha.

When you download MySQL Connector/Python from MySQL Labs, you will also see a ZIP archive containing the MySQL Utilities documentation …

Yet another MySQL DMR (5.7.2) is out and here is a short update on the testing improvements in this release.

• Test suite migration
  • Default storage engine in mysql-test-run.pl (MTR) changed from MyISAM to innodb.
  • Migrated parts, sys_vars, perfschema, funcs_1, funcs_2 and opt_trace  suites to run with innodb. 
  •   MyISAM variants retained for engine dependent tests.
  • Suites that are not yet migrated continue to run with MyISAM using include file force_myisam_default.inc.
• All new features qualified as per the process described at http://anithagopi.blogspot.in/2013/05/new-feature-qualification.html
•  Around 150 new MTR tests added already to 5.7
• Code Coverage at …

In this article we discuss a use case for starting with a single server (single shard setup) and scaling gradually as the application and its data grows. We also describe here the different aspects of creating shards using MySQL Fabric and what each of it means.

Note: Unlike the previous example the present example is not working with data that already exists.

Note: The example also covers how to modify the python application code to work with Fabric.
Prototyping the Application on a Single MySQL Shard Setup
The figure below depicts the difference in the initial setup between using and not using MySQL Fabric.
  Note: For the initial setup the Global Group can contain just another MySQL Server running on the same machine.


…

A quick overview of the InnoDB performance improvements for both read-only and read-write loads.

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 …