Starting with MySQL 5.5 it is possible to configure semi-synchronous replication. As you probably know, by default, MySQL replication is asynchronous. Asynchronous replication means that events/transactions applied on one server are not immediately applied on the other one. In the specific context of MySQL such behavior means that the MySQL Master writes transactions/events to the local binary logs, however it has no idea when the slave(s) will get and process them. Of course such configuration can lead, in case of failover, to some transaction loss since there is no guaranty that the transactions have been transmitted on the standby server(s).
The MySQL DevRoom at FOSDEM is ready. The schedule has been voted. Thanks to all who have participated. Now, let's make sure that the event is successful. The schedule is juicy, and not only because I have three talks in it!
Sunday 2012-02-05 | |||
Event | Speaker | Room | When |
---|---|---|---|
All you need to know about migrations and you never dared to ask | … |
It is my pleasure to announce that I will be presenting
on Tungsten Replicator next Wednesday, January
11th at the Los Angeles MySQL Meetup. The presentation title
is Fast, Flexible, and Fun--The Tungsten Replicator
Magical Mystery Tour. This talk is going to be fun for two
reasons.
First, it's a great opportunity to meet people in the LA MySQL
community and talk about my favorite replication software.
Tungsten is like a Swiss Army Knife for data replication.
It solves a wide range of problems involving HA, scaling,
and data movement. The presentation gives a quick intro to
the replicator, then surveys how to use the most interesting
features, including parallel slave apply, multi-master
replication, …
As promised, this is the final post in a series looking at
eventual consistency with MySQL Cluster asynchronous replication.
This time I'll describe the transaction dependency tracking used
with NDB$EPOCH_TRANS and review some of the implementation
properties.
Transaction based conflict handling with NDB$EPOCH_TRANS
NDB$EPOCH_TRANS is almost exactly the same as NDB$EPOCH, except
that when a conflict is detected on a row, the whole user
transaction which made the conflicting row change is marked as
conflicting, along with any dependent transactions. All of these
rejected row operations are then handled using inserts to an
exceptions table and realignment …
I am pleased to announce that the MySQL Database 5.6.4
development milestone release ("DMR") is now available for
download (select the Development Release
tab). MySQL 5.6.4 includes all 5.5 production-ready features and
provides an aggreation of all of the new features that have been
released in earlier 5.6 DMRs. 5.6.4 adds many bug fixes
and more new "early and often" enhancements that are development
and system QA complete and ready for Community evaluation and
feedback. You can get the complete rundown of all the new
5.6.4 specific features here.
For those following the progression of the 5.6 DMRs as the trains
leave the station, you should bookmark these MySQL …
I am pleased to announce that the MySQL Database 5.6.4
development milestone release ("DMR") is now available for
download (select the Development Release
tab). MySQL 5.6.4 includes all 5.5 production-ready features and
provides an aggreation of all of the new features that have been
released in earlier 5.6 DMRs. 5.6.4 adds many bug fixes
and more new "early and often" enhancements that are development
and system QA complete and ready for Community evaluation and
feedback. You can get the complete rundown of all the new
5.6.4 specific features here.
For those following the progression of the 5.6 DMRs as the trains
leave the station, you should bookmark these MySQL …
MySQL::Sandbox 3.0.24 was released yesterday, with many new features. More than vanilla MySQLIf you have missed my previous announcement, here's the gist of it. MySQL Sandbox can now deal with tarballs from either Percona Server or MariaDB. The main difference after this change is that you can now create a directory called <PREFIX>5.5.16 and make_sandbox will recognize it as well as the plain 5.5.16.
$ make_sandbox --export_binaries --add_prefix=ps \[Read more]
Percona-Server-5.5.11-rel20.2-114.Darwin.i386.tar.gz \
-- --sandbox_directory=msb_ps5_5_11
unpacking Percona-Server-5.5.11-rel20.2-114.Darwin.i386.tar.gz
[…]
installing with the following …
In previous posts I described how row conflicts are detected
using epochs. In this post I describe how they are handled.
Row based conflict handling with NDB$EPOCH
Once a row conflict is detected, as well as rejecting the row
change, row based conflict handling in the Slave will :
- Increment conflict counters
- Optionally insert a row into an exceptions table
For NDB$EPOCH, conflict detection and handling operates on one Cluster in an Active-Active pair designated as the Primary. When a Slave MySQLD attached to the Primary Cluster detects a conflict between data stored in the Primary and a replicated event …
[Read more]When an open source project becomes popular, bug reports start flocking in. This is both good and bad news for the project developers. The good news is that someone is using the product, and they are finding ways of breaking it that we didn't think of. The bad news is that most of the times the reporters assume that the developers have super human powers, and that they will find what's wrong by the simple mentioning that a given feature is not working as expected. Unfortunately, it doesn't work that way. An effective bug report should have enough information that the ones in charge will be able to reproduce it and examine in lab conditions to find the problem. When dealing with databases and database tools, there are several cases, from simple to complex. Let's cover them in order. Installation issuesThis is often a straightforward case of lack of functionality. When a tool does not install what it is supposed to, it is a show stopper, and a solution …
[Read more]
The last post described MySQL Cluster epochs and why
they provide a good basis for conflict detection, with a few
enhancements required. This post describes the
enhancements.
The following four mechanisms are required to implement conflict
detection via epochs :
- Slaves should 'reflect' information about replicated epochs
they have applied
Applied epoch numbers should be included in the Slave Binlog events returning to the originating cluster, in a Binlog position corresponding to the commit time of the replicated epoch …