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

This sounds like it would be great, doesn’t it? We’ve considered doing this, and even partially implemented it. But during our pre-release testing, we found a lot of potentially serious problems with the idea. It turns out to be very subtle — perhaps too subtle to be done with any computer program, no matter how smart, because there might be a lot of assumptions it’s forced to make, which could turn out to be dangerous. Every approach we considered carried a high risk of de-optimizing a server so it performs worse than before.

So in the end, although our tool is excellent for creating a starting my.cnf, my old blog post about the ultimate my.cnf tuner tool, which claims that an expert human is the only safe way to do this, might be an evergreen truth.

PS: my favorite user feedback so far is this one:

Great job, very good results! Now please take it offline before I am rendered obsolete.

View full post on MySQL Performance Blog

When: Friday, April 13th 2012 from 9:30 am

Where: Cypress room, Mezzanine Level, Hyatt Regency Santa Clara (5101 Great America Parkway)

What: Drizzle Day is a day to learn about Drizzle, how to use Drizzle, migrating to Drizzle and contributing to Drizzle. If you’re interested in a database for modern web applications, relational databases being deployed in the cloud, advanced replication techniques (such as crash safe replication, multi-sourced replication and being able to consume the replication stream in your application), AlsoSQL (a HTTP interface to a relational database), testing and performance – then Drizzle day is for you!

Price: Admission is free, however the Drizzle team would love you to consider making a voluntary donation between 50 – 150 USD to our SPI account to cover for the costs of this conference: click here to donate. Note that if you are expensing your travel and Percona Live attendance with your employer anyway, you can also expense this payment as a conference fee.

Lunch: There are various options with different prices for lunch inside and outside of the Hyatt. We will provide coffee, tea, beverages and snacks inside the Cypress room both for morning and afternoon breaks. Please let us know of diet or allergy restrictions in your RSVP.

Registrations: Space is limited, so please RSVP right away to ensure you get a spot. RSVP at henrik@drizzle.org so we can plan the space and refreshments.

A draft schedule is on the Drizzle Day website.

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

Let’s take a table with data as example, column c1 on table t2 references column c1 on table t1 – both columns have identical set of rows for simplicity.

CREATE TABLE `t1` (
`t1_c1` int(10) unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`t1_c1`)
) ENGINE=InnoDB;

CREATE TABLE `t2` (
`t2_c1` int(10) unsigned NOT NULL,
PRIMARY KEY (`t2_c1`),
CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`t2_c1`) REFERENCES `t1` (`t1_c1`) ON UPDATE CASCADE
) ENGINE=InnoDB;

[revin@forge rsandbox_5_5_17]$ for int in {1..2000}; do ./master/use test -e "insert into t1 values($int)"; done
[revin@forge rsandbox_5_5_17]$ ./master/use test -e "insert into t2 select * from t1"

master [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
| 2000 |
+----------+
1 row in set (0.00 sec)

master [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t2;
+----------+
| COUNT(*) |
+----------+
| 2000 |
+----------+
1 row in set (0.00 sec)

An expected behavior for DELETE IGNORE is that if the statement fails to delete all rows, none should be deleted at all, after all this is InnoDB right? Wrong, take a look at bug 44987. As stated on the bug, only 5.0 exhibits the above mentioned behavior on 5.1 and 5.5, MySQL will stop deleting rows if it encounters constraint errors.

To demonstrate on 5.5.17:

I delete some rows from t2 so some rows on t1 does not have a constraint.

master [localhost] {msandbox} (test) > DELETE FROM t2 WHERE t2_c1 BETWEEN 201 AND 400;
Query OK, 200 rows affected (0.00 sec)

Now I try to DELETE IGNORE rows 301 to 500 on t1, note rows 301 to 400 does not have any existing constraints from t2 as we deleted them from above.

master [localhost] {msandbox} (test) > DELETE IGNORE FROM t1 WHERE t1_c1 BETWEEN 301 AND 500;
Query OK, 100 rows affected, 1 warning (0.00 sec)

master [localhost] {msandbox} (test) > SHOW WARNINGS \G
*************************** 1. row ***************************
  Level: Error
   Code: 1451
Message: Cannot delete or update a parent row: a foreign key constraint fails (`test`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`t2_c1`) REFERENCES `t1` (`t1_c1`) ON UPDATE CASCADE)
1 row in set (0.00 sec)

As expected a warning is generated because rows 201 to 300 on t1 still has referencing foreign keys from t2. However, 100 has been deleted! Let’s see.

master [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|     1900 |
+----------+
1 row in set (0.00 sec)

Now let’s check the slave.

[revin@forge rsandbox_5_5_17]$ ./node1/use test
...
slave1 [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|     2000 |
+----------+
1 row in set (0.00 sec)

Uh oh, now the slave is out of sync, because the statement failed to delete all intended rows it was not written to the binary log and consequently not reaching the slave.

So how can you workaround this? Simple, 1) do not use IGNORE, be critical about your data 2) use ROW* based replication. When using the latter, MySQL will log separate statements for each row that is deleted – so if the first 100 rows was successfully deleted then those 100 events are logged and eventually replicated.

[revin@forge rsandbox_5_5_170]$ ./master/use test
...
master [localhost] {msandbox} (test) > SELECT @@binlog_format;
+-----------------+
| @@binlog_format |
+-----------------+
| ROW             |
+-----------------+
1 row in set (0.00 sec)

master [localhost] {msandbox} (test) > DELETE FROM t2 WHERE t2_c1 BETWEEN 201 AND 400;
Query OK, 200 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > DELETE IGNORE FROM t1 WHERE t1_c1 BETWEEN 301 AND 500;
Query OK, 100 rows affected, 1 warning (0.01 sec)

master [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|     1900 |
+----------+
1 row in set (0.00 sec)

[revin@forge rsandbox_5_5_170]$ ./node1/use test
...
slave1 [localhost] {msandbox} (test) > SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|     1900 |
+----------+
1 row in set (0.00 sec)

* MIXED mode will not work since the query in this example will be considered STATEMENT (http://dev.mysql.com/doc/refman/5.1/en/binary-log-mixed.html) thus failure to execute the query successfully means it will not get logged.

View full post on MySQL Performance Blog