Based on MySQL 5.1.61, including all the bug fixes in it, Percona Server 5.1.61-13.2 is now the current stable release in the 5.1 series. All of Percona ‘s software is open-source and free, all the details of the release can be found in the 5.1.61-13.2 milestone at Launchpad.

The full release notes can be found in our online documentation: http://www.percona.com/doc/percona-server/5.1/release-notes/Percona-Server-5.1.61-13.2.html

View full post on MySQL Performance Blog

This release is purely composed of bug fixes and is the current stable release of Percona XtraBackup.

There are some important bug fixes around incremental backups, parallel backups and backups on databases with the system tablespace being multiple files. The full release notes and details are available here: http://www.percona.com/doc/percona-xtrabackup/release-notes/1.6/1.6.5.html

View full post on MySQL Performance Blog

Since this is a beta release, you should not rely on it for production workloads – use the stable 1.6 series of Percona XtraBackup instead.

In this beta we’re proud to add:

• support for Galera replication and the Percona XtraDB Cluster Alpha.
• the Documentation is now bundled with the source tree and under a CC Attribution-ShareAlike 2.0 Generic license.
• support for building with debug InnoDB (only for very advanced users)

The full release notes are available in our online documentation.

Binaries and source tarballs can be downloaded from our download site: http://www.percona.com/downloads/XtraBackup/BETA/1.9.0/ . As this is a BETA release, we do not recommend it for production use. As always, all our work is done on the Percona XtraBackup launchpad site and the up-to-the-minute bzr trees can be pulled from Launchpad.

View full post on MySQL Performance Blog

Based on MySQL 5.5.20, including all the bug fixes in it, Percona Server 5.5.20-24.1 is now the current stable release in the 5.5 series. All of Percona ‘s software is open-source and free, all the details of the release can be found in the 5.5.20-24.1 milestone at Launchpad.

View full post on MySQL Performance Blog

For those of you who don’t know what this is, it’s another of the O’Reilly traditions we’re trying to continue. (We are trying very hard to make this event as close to a clone of O’Reilly’s as we can.) It’s a free table in the expo hall where people who participate in a non-commercial open source project can exhibit. I organized a Maatkit booth a few times in the past, and was always really grateful to O’Reilly for making the space available. Space in the expo hall is at a premium, but we think that these dot-org booths are even more valuable to the open-source projects and the conference attendees.

So, please tell your friends who care about open source, and ask them to tell their friends too. Let’s get some great open-source projects into the expo hall, alongside the commercial vendors!

View full post on MySQL Performance Blog

What’s new? You can read the changelog for the details, but here are the highlights:

Brand new pt-diskstats, thanks to Brian Fraser. This tool is completely rewritten, and it’s finally the iostat replacement I always wanted. Not only does it have the functionality I want (interactive, slice and dice, smart defaults) but it has the detailed statistics on I/O, so you can see whether your reads are slow versus your writes, and whether things are waiting on the disk or waiting on the queue scheduler (cfq, hint hint). Finally, it has transparency, so you can read the documentation and understand, really, what it’s doing at the low level and what that means for your server. We really need specific, precise information on exactly how the I/O is behaving so we can make good decisions when there are problems or when doing things like capacity planning.

Brand new pt-stalk, courtesy of Daniel Nichter. This tool is also completely rewritten. Instead of a Bash script that you have to configure with environment variables and run in a screen session, this is now a first-class fault detection daemon. Everyone needs post-mortem forensic data when there is a problem, and pt-stalk aims to be a core part of your infrastructure that fills this gap. It now supports things a “real” Percona Toolkit tool ought to have, such as command-line options and a configuration file. In addition, we merged pt-collect into it, so as of Percona Toolkit 2.0.3, there isn’t a separate pt-collect tool anymore.

There’s a lot more to this release, but those are the major points. Download it and let us know how it works, please! If you find bugs, file them on Launchpad, and if you need support, you know where to get it.

View full post on MySQL Performance Blog

View full post on MySQL Performance Blog

It is recommended you get familiar with general architecture of the cluster, described on the previous post.

By Multi-Master I mean the ability to write to any node in your cluster and do not worry that eventually you get out-of-sync situation, as it regularly happens with regular MySQL replication if you imprudently write to the wrong server.

This is long-waited feature, I’ve seen growing demand for it for last two years or even more.
Percona XtraDB Cluster provides it, and let’s see how it works.

With our Cluster you can write to any node, and the Cluster guarantees consistency of writes. That is the write is either committed on all nodes or not committed at all.

Let me draw some diagram there. For the simplicity I will use a two-nodes example, but the same logic is applied when you have N nodes.

As you see all queries are executed locally on the node, and only on COMMIT there is special handling.
When you issue COMMIT, your transaction has to pass certification on all nodes. If it does not pass, you
will receive “ERROR” as response on your query. After that transaction is applied on the local node.

That is response time of COMMIT consist of several parts:

• Network roundtrip
• Certification time
• Local applying

Please note that applying the transaction on remote nodes does not affect the response time of COMMIT,
as it happens in the background after the response on certification.

The two important consequences of this architecture.

• First: we can have several appliers working in parallel. This gives us true parallel replication. Slave can have many parallel threads, and you can tune it by variable wsrep_slave_threads
• Second: There might be a small period of time when the slave is out-of-sync from master. This happens because the master may apply event faster than a slave. And if you do read from the slave, you may read data, that has not changes yet. You can see that from diagram. However you can change this behavior by using variable wsrep_causal_reads=ON. In this case the read on the slave will wait until event is applied (this however will increase the response time of the read. This gap between slave and master is the reason why this replication named “virtually synchronous replication”, not real “synchronous replication”

The described behavior of COMMIT also has the second serious implication.
If you run write transactions to two different nodes, the cluster will use an optimistic locking model.
That means a transaction will not check on possible locking conflicts during individual queries, but rather on the COMMIT stage. And you may get ERROR response on COMMIT. I am highlighting this, as this is one of incompatibilities with regular InnoDB, that you may experience. In InnoDB usually DEADLOCK and LOCK TIMEOUT errors happen in response on particular query, but not on COMMIT. Well, if you follow a good practice, you still check errors code after “COMMIT” query, but I saw many applications that do not do that.

So, if you plan to use Multi-Master capabilities of XtraDB Cluster, and run write transactions on several nodes, you may need to make sure you handle response on “COMMIT” query.

View full post on MySQL Performance Blog

But before jumping to HA, let’s review general architecture of the Percona XtraDB Cluster.

1. The Cluster consists of Nodes. Recommended configuration is to have at least 3 nodes, but you can make it running with 2 nodes too.
2. Each Node is regular MySQL / Percona Server setup. The point is that you can convert your existing MySQL / Percona Server into Node and roll Cluster using it as base. Or otherwise – you can detach Node from Cluster and use it as just a regular server.
3. Each Node contains the full copy of data. That defines XtraDB Cluster behavior in many ways. And obviously there are benefits and drawbacks.

Benefits of such approach:

• When you execute a query, it is executed locally on the node. All data is available locally, no need for remote access.
• No central management. You can loose any node at any point of time, and the cluster will continue to function
• Good solution for scaling a read workload. You can put read queries to any of the nodes

Drawbacks:

• Overhead of joining new node. The new node has to copy full dataset from one of existing node. If it is 100GB, it copies 100GB.
• This can’t be used as an effective write scaling solution. There might be some improvements in write throughput when you run write traffic to 2 nodes vs all traffic to 1 node, but you can’t expect a lot. All writes still have to go on all nodes.
• You have several duplicates of data. For 3 nodes – 3 duplicates

This basically defines how Percona XtraDB Cluster can be used for High Availability.

Basic setup: you run 3-nodes setup.
The Percona XtraDB Cluster will continue to function when you take any of nodes down.
At any point of time you can shutdown any Node to perform maintenance or make configuration changes.
Or Node may crash or become network unavailable. The Cluster will continue to work, you can continue to run queries on working nodes.

The biggest question there, what will happen when the Node joins the cluster back, and there were changes to data while the node
was down.

Let’s focus on this with details.
There is two ways that Node may use when it joins the cluster: State Snapshot Transfer (SST) and Incremental State Transfer (IST).

• SST is the full copy if data from one node to another. SST is used when new node joins the cluster, it has to transfer data from existing node.
  There is three methods of SST available in Percona XtraDB Cluster: mysqldump, rsync and xtrabackup ( Percona XtraBackup with support of XtraDB Cluster will be released soon, so far you need to use our source code repository).
  The downside of mysqldump and rsync is that your cluster becomes READ-ONLY for time that takes to copy data from one node to another (SST applies FLUSH TABLES WITH READ LOCK command).
  Xtrabackup SST does not require READ LOCK for full time, only for syncing .frm files (the same as with regular backup).
• Even with that, SST may be intrusive, that’s why there is IST mechanism. If down your node for short period of time, and then start it, the node is able to fetch only changes made during period it was down.
  This is done using caching mechanism on nodes. Each node contains a cache, ring-buffer, (the size is configurable) of last N changes, and the node is able to transfer part of this cache. Obviously IST can be done only if amount of changes needed to transfer is less than N. If it exceeds N, then the joining node has to perform SST.

You can monitor current state of Node by using
SHOW STATUS LIKE 'wsrep_local_state_comment', when it is ‘Synced (6)’, the node is ready to handle traffic.

View full post on MySQL Performance Blog

Based on MySQL 5.5.19, including all the bug fixes in it, Percona Server 5.5.19-24.0 is now the current stable release in the 5.5 series. All of Percona ‘s software is open-source and free, all the details of the release can be found in the 5.5.19-24.0 milestone at Launchpad.

For this release we also provide EXPERIMENTAL binaries for Mac OS X platform, and you can download tar.gz or dmg there

View full post on MySQL Performance Blog