Tungsten Replicator has offered shard-based
parallel replication to slaves since late 2010. The initial
implementation uses in-memory queues. Working purely in
memory keeps latency low and throughput high. On the other
hand, working in memory consumes valuable RAM. It also
forces us to buffer all in-flight transactions and therefore
greatly limits the span of time permissible between the slowest
and fastest shard.
Hence our newest improvement: on-disk parallel queues.
In this article I will cover how parallel replication works
in general, how on-disk queues help with parallel replication,
and then show how to set up from the latest builds.
First, let's review the basic mechanics. Parallel …
The latest from the MySQL community
Ideas, releases, practical guides, and perspectives from the people building with MySQL.
| After the public home for Tungsten Replicator, we needed another place where to host complementary tools. We discussed the pros and cons of hosting these tools in the same place where we publish Tungsten, but in the end we decided that it's more practical to have a separate project, where we can publish tools related to database replication, no matter if they are dedicated to Tungsten or if they can work with other replication systems.So, here it is. We have now Tungsten Toolbox, a site where we will collect our tools and accept contributions from others. |
We have already a few tools that, after being cleaned up, will …
[Read more]| We have been busy, at Continuent. In addition to our usual work with high performance replication, we have addressed usability issues, since we know that a hard-to-use problem, no matter how powerful, has low adoption. Thus, is with some personal satisfaction that I can announce the release of Tungsten Replicator 2.0.3, which comes with several huge improvements in matter of user friendliness. The new installation procedure is so user friendly, in fact, that I was able to build a sophisticated tungsten-sandbox with a 150-line shell script. (The corresponding features … |
MySQL Replication is something that is used by many, many MySQL
users, and here at Recorded Future we are no exception. In our case,
the slaves are used for different purposes, and as we develop our
system so much and so fast, so sometimes things happen which
could have been avoided. Like something getting executed in the
master that really should not end up in a slave at all, and which
would cause all sorts of problems on the slave.
Also, some things that work fine on the master can sometimes
cause things to break on the slave, a typical such issue is a big
operation on the master that when executed on the slave would
cause a lock timeout. And you could argue that the lock timeout
should be increased, but the question is how much, and frankly,
do you really want those locks hanging around? And in some cases,
it's the replication thread that has a lock timeout.
…
Version 2 of the PBMS daemon is now ready.
Here are the major changes introduced with this version:
-
PBMS is fully integrated with MySQL 5.5:
PBMS is now provided as a patch for MySQL 5.5 which simplifies installation and provides numerous benefits.
-
All engines are "PBMS enabled":
PBMS no longer requires that you have a "PBMS enabled" storage engine to be able to use PBMS.
-
The MySQL client lib provides the PBMS client
API:
You no longer need to link your application to a separate PBMS lib to use the PBMS 'C' API.
-
mysqldump understands PBMS BLOB URLS:
When dumping tables or databases containing PBMS BLOB URLs mysqldump will dump the referenced BLOBs as binary data to a …
-
All engines are "PBMS enabled":
Some time ago I wrote about MySQL 5.5 semi-synchronous replication. Since then, I have wanted to benchmark the overhead of semi-synchronous replication with a decent server. Now the occasion presented itself, thanks to some related business that I had to benchmark, and thus I did a few simple runs with and without semi-synchronous replication enabled, to see the impact of this feature on performance. If you haven't read the article on semi-synchronous replication, the bottom line is that, with this feature enabled, the master waits until at least one slave has acknowledged receipt for the data before returning a positive result to the client. This means that for each commit there are two network calls between master and slave. My gut feeling was that this feature would be costly in terms of query response time, although I was not prepared to …
[Read more]
The last article on this blog described our planned MySQL to MongoDB replication hackathon at the
recent Open DB Camp in Sardinia. Well, it
worked, and the code is now checked into the Tungsten Replicator project. This article
describes exactly what we did to write the code and set up
replication. You can view it as a kind of cookbook both for
implementing new database types in Tungsten as well as setting up
replication to MongoDB.
The Team
MySQL to MongoDB replication was a group effort with three
people: Flavio Percoco, Stephane Giron, and me.
Flavio has worked on …
This is another article in a series of articles titled "A few notes ..." in which I will be posting some important information about locking concepts, different types of locks and what locks table engines support. Just like the previous article, the purpose of this article is to highlight important aspects that you should have in the back of your mind when developing applications.
Version 1.3 of Slave read-Ahead is available for download. If you don't know what this tool is
about, it is a tool that runs in the background, reads the
incoming replication log on a slave and converts INSERT, UPDATE
and INSERT ... SELECT statements into SELECT statements and
executes these before the statement in question is executed on
the server, the idea being that this will "prewarm" the MySQL
caches for this date, for example the rows that an UPDATE is
affecting will already be in the cache when the UPDATE arrives on
the slave. Because of the way replication data is read, this tool
only works with MySQL5.5 and up.
Version 1.3 introduces the auto-reconnect feature. This will
reconnect to the MySQL server if the connection fails. To be sure
that we restart, all existing connectings are released before a
reconnect attempt is made. This version also has …
Listening to the OurSQL podcast: Repli-cans and Repli-can’ts got me thinking,
what are the issues with MySQL replication that Sarah
and Sheeri didn’t have the time to include in their
episode. Here’s my list:
Replication Capacity Index This is a concept introduced by
Percona in last year’s post: Estimating Replication Capacity which I
revisited briefly during my presentation at this year’s MySQL Users
Conference. Why is this important? Very …