Details of Re-execution and Empty Transactions << Previous post: Failover and Flexible Replication Topologies in MySQL 5.6
Next post: Flexible Fail-over Policies Using MySQL and Global Transaction Identifiers >>
This post was kindly translated to Japanese by Ryusuke Kajiyama.

In my previous post, we saw how GTIDs are generated and propagated, we described the new replication protocol, and we saw how these simple elements fit together to …

In a previous post I showed how to implement multi-source round-robin replication in pure SQL using the tables that are needed for crash-safe replication. I also outlined a revised version of this approach in the Replication Tips & Tricks presentation I gave at MySQL Connect. This was, however, before the GTID (Global Transaction ID) implementation was done. Now that they are introduced, multi-source replication is even easier since you no longer have to keep track of the positions.

Figure 1. Tables for storing information about masters

CREATE TABLE my_masters (
    idx INT AUTO_INCREMENT,
    host CHAR(50) NOT NULL,
    port INT NOT NULL DEFAULT …

La haute disponibilité, c’est garantir aux applications un accès permanent aux données, même en cas de panne. Permanent ? Même lorsque vous mettez à jour le schéma de vos bases ? Que vous ajoutez de la RAM sur un serveur ? Que vous reconfigurez ou redémarrez MySQL ?   

Comment lire les données depuis un nœud esclave avec une garantie que les données sont à jour, sans changement applicatif ?

Data is the currency of today’s web, mobile, social, enterprise and cloud applications. Ensuring data is always available is a top priority for any organization – minutes of downtime will result in significant loss of revenue and reputation.

There is not a “one size fits all” approach to delivering High Availability (HA). Unique application attributes, business requirements, operational capabilities and legacy infrastructure can all influence HA technology selection. And then technology is only one element in delivering HA – “People and Processes” are just as critical as the technology itself.

For this reason, MySQL Enterprise Edition is available supporting a range of HA solutions, fully certified and supported by Oracle. MySQL Enterprise HA is …

Not much to add really to the bug I’ve filed here: bug#67099.

I personally can think of some very nasty consequences of applying this on the slaves I manage, and the reason I’m posting the bug is that while I guess this is too late to fix in 5.6 as it’s effectively a new feature, I’m sure many sites may bump into this and be somewhat disappointed if they want to use the new GTID feature and have several slaves.  Hence, if the fix/feature has to go into MySQL 5.7 then I hope it goes in sooner rather than later. We will see.

Updated: 2013-09-19

I probably should have updated this earlier but it does seem that Oracle have taken these comments on board. See: WL6559.  It looks like they plan to do this for 5.7 which is good news. I’m really hoping …

Cross-site databases are the next challenge facing today's MySQL-based businesses. Continuent Tungsten provides multiple options for spreading data across sites, including primary/DR, multi-master, and system-of-record approaches. Join us to learn how Continuent Tungsten enables replication, failover, and routing of transactions between sites.

We cover the following topics:

Introduction to

So we tested the 5.6.7-RC. And ran into a strange problem:

Because of a test, a preexisting configuration with GTID enabled existed, and suddenly we did not have properly initialized grants in mysql.* created for a new installation. Turns out: GTID and non-transactional tables are no friends, and that is even documented.

When using GTIDs, updates to tables using nontransactional storage engines such as MyISAM are not supported. This is because updates to such tables mixed with updates to tables that use a transactional storage engine such as InnoDB can result in multiple GTIDs being assigned to the same transaction.

Also, this is supposed to work with GRANT and REVOKE, but not with INSERT and DELETE. Now guess what mysql-install-db and friends are using?

server:~ # less …

Global Transaction Identifiers – why, what, and how Next post: Advanced use of Global Transaction Identifiers
This post was kindly translated to Japanese by Ryusuke Kajiyama.

In MySQL 5.6 we introduced a new replication feature called Global Transaction Identifiers, or GTIDs. While there are many use cases, our primary motivation for introducing GTIDs is that it allows for seamless failover. By this, we mean promoting one of the slaves to be come a master, if the master crashes, with minimal manual intervention and service disruption.

This is the first in a series of several blog posts. We will go through several use cases and show how easy it is to do a failover. We explain …

My colleague at Booking.com, Dennis Kaarsemaker, just blogged an interesting article about the Replication Load Monitor we are using at work. This is based on work from Mark Leith, but presents a much more detailed view.

May it be useful.

GenieDB is building a database with global distribution as its core thesis. It is no secret customers demand near-instantaneous and highly reliable service, and that they are becoming more globally dispersed than ever before. We believe that data custodianship must ultimately be moved to the “edge of the web” where it can be dynamically managed in order to improve user experience, optimize network/hardware utilization and reduce TCO. A single datacenter hosted database and application stack runs afoul of this fundamental thesis in a number of ways. In this article we will focus on the issue of improving response time for users even when they are globally distributed. This is simply a matter of physics and how long it takes to transmit a packet between the two locations. No amount of application tuning can overcome this obstacle.

The obvious solution is to have multiple copies of the …