Boost Your Replication Throughput with Parallel Apply, Prefetch, and Batching

------------------------------------------------------

Slave lag is the bane master/slave replication. This talk will explain why slave lag occurs and show you three important ways that Tungsten Replicator can banish it for MySQL slaves. Parallel apply uses multiple threads to execute slave transactions. Prefetch uses parallel threads to read ahead of the slave position and fetch pages that will be needed by the slave. Batching uses CSV files to load row updates in extremely large transactions that bypass SQL completely. We will explain each technique, show you how to use it, and provide performance numbers that illustrate the gain you can expect. We will round the talk out with a discussion of non-Tungsten tools that offer similar benefits. With these techniques in hand, you'll be well-prepared to attack any replication performance …

Percona you know I love you.  You have the largest brains working with MySQL. Your toolkit (formerly Maatkit and Aspersa) is a real gift to the MySQL community. But stop teasing us with webinars about what it can do and show us how to use it.

The Percona ToolKit needs a cookbook. The documentation is reference only, very thin and total void of useful examples. You’re beginning to frustrate the masses.

Here is what’s happening.  My MySQL server crashes or stalls ever few months.  I searched the Goog and find PT-Stalk :

“watches for a trigger condition to become true, and then collects data to help in diagnosing problems. It is designed to run as a daemon with root privileges, so that you can diagnose intermittent problems that you cannot observe directly. You can also use it to execute a custom command, or to gather the data on demand without …

Some time ago, I wrote a rather popular post The MySQL “swap insanity” problem and the effects of the NUMA architecture (if you haven’t read it, stop now and do that!), which described using numactl --interleave=all to balance memory allocation across nodes in a NUMA system.

I should’ve titled it differently

In reality, the problem posed by uneven allocation across nodes under NUMA is not entirely a swapping problem. I titled the previous post as it was and explained it in the way it was explained largely to address a specific problem seen in the MySQL community. However, the problem described actually has very little to do with swap itself. The problem is really related to Linux’s behavior under memory pressure, and specifically the pressure imposed by running a single NUMA node (and especially node 0) …

The SkySQL booth ready for the stampede of visitors that stopped by each day.

We hope it was as productive and fun for all of you as it was for us at SkySQL! We started out the week at Percona Live, which was an excellent conference. Thanks to the Percona folks for making this a great get-together for the MySQL community. Excellent job, guys!

We welcomed two new partners, hastexo and PalominoDB, which means our customers will see even better MySQL service and support with SkySQL. And many of our current …

Using and benchmarking Galera in different architectures

=============================================

What I was interested most during the second day was again, synchronous replication and Replication solutions provide from Continuent.

The first I attend in the day was the Galera one, done Henrik and Alexey.

The presentation was going to talk about:

"We will present results from benchmarking a MySQL Galera cluster under various workloads and also compare them to how other MySQL high-availability approaches perform. We will also go through the different ways you can setup Galera, some of its architectures are unique among MySQL clustering solutions.

* MySQL Galera

** Synchronous multi-master clustering, what does it mean?

** Load balancing and other options

** WAN replication

** How split brain is handled

** How split brain is handled in WAN …

  Plug-in to Vegas The program focuses on key topics such as high availability, virtualization, security, business intelligence, Exadata, Cloud Computing and internals.  Recently added, we switched around the schedule to include the Thursday Deep Dive, Avoiding Downtime through the Maximum … Continue reading →

Note: this article was originally published on http://blogs.innodb.com on April 16, 2012 by Yasufumi Kinoshita.

The performance of flush_list flushing of InnoDB decides the basic performance for modifying workloads. So, it is important to optimize the flush behavior. In this post we’ll consider how to optimize the neighbor-flushing behavior.

Factor 1: Characteristics of storage

Depending on the characteristics of your storage’s throughput for write IO, you can term your storage as either “write amount bound” or “write times bound”. The minimum unit of the InnoDB datafile is page size (16KB or less). And InnoDB attempts to combines them in a single IO up to 1 extent (1MB) maximum, if they are contiguous.

<one HDD>:  Almost “write times bound”. Because head-seek time is the most …

The performance of flush_list flushing of InnoDB decides the basic performance for modifying workloads. So, it is important to optimize the flush behavior. In this post we’ll consider how to optimize the neighbor-flushing behavior.

Factor 1: Characteristics of storage

Depending on the characteristics of your storage’s throughput for write IO, you can term your storage as either “write amount bound” or “write times bound”. The minimum unit of the InnoDB datafile is page size (16KB or less). And InnoDB attempts to combines them in a single IO up to 1 extent (1MB) maximum, if they are contiguous.

<one HDD>:  Almost “write times bound”. Because head-seek time is the most effective factor for access time of HDD. And around 1MB size can be treated by the 1 head-seek.

…

Provided I manage to get a visa, I should speak about Tarantool at nosql-matters.org conference, in Cologne, this May.
Judging by the invited speaker crowd this is going to be more a technology (lots of authors of NoSQL databases), rather than a community event. Interesting none the less!

MySQL Connect will take place in San Francisco September 29 and 30; you can read the Press Release here.

The call for papers is open until May 6, submit your sessions now!

This is your chance to present your real-world experience and share your expertise and best practices with the MySQL community.

The conference includes six tracks: Performance and Scalability, High Availability, Cloud Computing, Architecture and Design, Database Administration, and Application Development.

You can submit conference sessions as well as BOF (Birds-of-a-Feather) sessions. We look forward to hearing from you!

Interested …