One of the ways I try to contribute to the MySQL community is by answering questions on Stack Overflow. Based on the votes my answers get, I can tell that some of them are helpful only to the person who asked the question (if that), but a few of my answers continue to get upvotes for months and even years.

For example, here's my most popular answer. If you don't want to follow the link, the question is essentially "How do I optimize all tables in a MySQL instance with a single command?" and my answer is "mysqlcheck -o".

Apparently that is a common problem, and lots of people find my solution useful, which is nice. But would I ever actually run mysqlcheck -o? Probably not. At least, not on a production database.

I wouldn't run it on an active …

Register today, SPETEMBER 7th, to save $200 on the registration for the MySQL Connect Conference. This will be the biggest technical conference on MySQL. There will be tracks on Application Development, Architecture and Design, Cloud Computing, Database Administration, High Availability, and Performance and Scalability. Please check out the content catalog and register today!

…

If you’re anything like me,  your initial reaction upon hearing about transportable tablespaces for InnoDB in 5.6 was to imagine it like MyISAM, where you can copy the .frm, .myi and .myd files around to your heart’s content, and everything will be great.  You might have read Sunny’s excellent blog, and realized that there’s a bit more to it than that – you have to explicitly prepare the tablespace for copying using FLUSH TABLES FOR EXPORT.  That’s perfectly acceptable for the bulk of use cases, such as single-table InnoDB backups, and opens up exciting new possibilities for moving or copying InnoDB data at the filesystem level.

But for situations where the need is a little different, you might really dug into it and start to wonder about the .cfg files produced during the FLUSH TABLES FOR EXPORT operation.  …

I continue my benchmarks of Intel SSD 910, the raw IO results are available in my previous experiment. Now I want to test this card under MySQL workload to see if the card is suitable to use with MySQL.

• Server: Dell PowerEdge R710
• CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
• Memory: 192GB
• Storage: Fusion-io ioDrive 640GB, Intel SSD 910 (software RAID over 2x200GB devices)
• Filesystem: ext4

• OS: Ubuntu 12.04.1
• MySQL Version: Percona Server 5.5.27-28.1

• Benchmark name: tpcc-mysql
• Scale factor: 2500W (~250GB of data)
• Benchmark …

Percona is glad to announce the release of Percona XtraDB Cluster on September 7th, 2012. Binaries are available from downloads area or from our software repositories.

Features:

• Percona XtraDB Cluster supports tunable buffer size for fast index creation in InnoDB. This value was calculated based on the merge block size (which was hardcoded to 1 MB) and the minimum index record size. By adding the session variable innodb_merge_sort_block_size, block size that is used in the merge sort can now be adjusted for better …

Next week Michael and I (Bradley) will be travelling to Silicon Valley to present a tutorial on Data Structures and Algorithms for Big Databases at the 6th XLDB Conference.

The tutorial, which is 4 hours on Monday afternoon, aims to cover the following topics (but it’s looking like we’ll have to drop several items for lack of time.)

This tutorial will explore data structures and algorithms for big databases. The topics include:

• Data structures including B-trees, Log Structured Merge Trees, and Streaming B-trees.
• Approximate Query Membership data structures including Bloom filters and cascade filters.
• Algorithms for join including hash joins and Graefe’s generalized join.
• Index design, including covering indexes. …

One of the ways I try to contribute to the MySQL community is by answering questions on Stack Overflow. Based on the votes my answers get, I can tell that some of them are helpful only to the person who asked the question (if that), but a few of my answers continue to get upvotes for months and even years.

For example, here's my most popular answer. If you don't want to follow the link, the question is essentially "How do I optimize all tables in a MySQL instance with a single command?" and my answer is "mysqlcheck -o".

Apparently that is a common problem, and lots of people find my solution useful, which is nice. But would I ever actually run mysqlcheck -o? Probably not. At least, not on a production database.

I wouldn't run it on an active …

With innodb_file_per_table=1, InnoDB places every table’s data and indexes in a separate .ibd file, but there is still a “global” system tablespace, stored by default in a file named ibdata1. This contains some of each table’s data, such as the undo log and insert buffer. If it is fixed-size, you can fill it up and crash the server, as I’ve mentioned in a few recent blog posts.

In older versions of MySQL, the SHOW TABLE STATUS command showed the amount of space free in the tablespace as an entry in the Comment column. If you weren’t using innodb_file_per_table, you could use this to see how full your tablespace was.

The servers I’m managing use innodb_file_per_table=1, so I thought perhaps I can find out how full the system tablespace is by disabling innodb_file_per_table, creating a table, and enabling it again. …

You surely have heard about Percona Live,NY taking place October 1-2 in New York, you however might have been wondering what kind of talks you would see on this event and why would should you attend.

The day one of this event is Tutorial day, which is long (half to a full day) presentations which go deep into details and often feature hands on experience. We expect you to attend tutorial on the topic which is highly relevant for your job to significantly increase mastery of the topic. If you work with benchmarking, performance analyses load testing you might want to attend “Understanding Performance through Measurement, Benchmarking and Profiling” . If you’re using Innodb my tutorial on …

Producing a podcast takes a lot of time. The first 26 episodes of OurSQL: The MySQL Database Community Podcast were produced solely by me, but the podcasts were not regularly recurring. Those 26 episodes occurred over a period of 2 years and 3 months, which is less than one episode per month. Doing it all myself took a lot of time. I loved podcasting, and still do, but I could not do it all myself.

I thought long and hard during a 22-month hiatus. For almost 2 years, I reconciled my love for podcasting with the insane amount of work that doing a podcast solo took. I realized that what I wanted was:

- a co-host to keep me accountable. Too often I would set out with good intentions of “today I will podcast” that produced nothing because I did not prioritize doing the podcast.

- an audio engineer to do the post-processing. Post-processing was, for me, a very nitpicky …