This describes the tables in the Facebook patch for MySQL for table and user monitoring. I frequently refer to them as table_stats and user_stats. These tables are in the INFORMATION_SCHEMA and started in the Google patch many years ago (2007 or 2008). They have been significantly enhanced since then with more columns and more efficient implementations. The feature started before the INFORMATION_SCHEMA, so SHOW TABLE_STATISTICS and SHOW USER_STATISTICS can be used to get their data in addition to SELECT statements. It is important for frequently used monitoring commands to be easy to type and the SHOW commands are easy to type when you need all of the data.Some of the metrics below are only implemented for InnoDB but should be implemented for all storage engines in a general purpose product. Other metrics are specific to InnoDB, like the ones for compressed tables. Some of the disk IO metrics are implemented for InnoDB as per-tablespace metrics. This …

Lately we’ve had many reports of the RPM packages for CentOS 5 (mostly) and CentOS 6 having issues when installing different combinations of our products, particularly with Percona Toolkit. Examples of bugs related to these issues are lp:1031427 and lp:1051874.

These problems arise when trying to install a package from the distribution that is linked against the version of libmysqlclient.so shipped by the distribution (libmysqlclient.so.15 for CentOS 5/libmysqlclient.so.16 for CentOS 6) and a version of Percona Server that depends on another version of libmysqlclient.so, usually more recent. Bug lp:1031427 is an example of this, and shows how the packages would conflict when trying to …

Note: I was recently asked by a large financial firm to write some thoughts about write scaling strategies around Postgres. While it’s not code, I thought I would “open source” that work by posting it here. What follows is the first in a 5 part series of posts.

Introduction

Horizontal partitioning, often referred to as sharding, has become a common pattern for scaling large database loads, especially within the webops community. This is not something particular to Postgres, if you look on the web, you’ll see many articles about sharding with other database, most prominently MySQL. The main drivers behind these techniques (IMHO) are a combination of the inability of OSS databases to scale vertically on high-end hardware (though they are making improvements in this area), and the desire to spend hardware dollars on easily replaceable and interchangeable, smaller servers running on commodity hardware, rather than investing in …

Latest training events calendar & class schedule now available

read more

In my last few posts, I wrote about “How to install MySQL replication using GTID’s” (Part One, Part Two). In this post, I will show you how to install MySQL 5.6 and set up replication between two MySQL servers the “old fashioned way” using the binary log and binary log position.

I am going to create some virtual machines instead of using individual servers. But, you can also use these instructions to create a MySQL replication (master/slave) setup with real servers.

Here is …

MySQL 5.6 has introduced a new unit test framework beside the existing ones. The googletest test framework is now part of the MySQL test framework for 5.6. GoogleTest is a C++ Testing Framework that helps  write better C++ tests.

I realized that it was used when i tried to buid a MySQL release from sources [...]

MySQL 5.6 is probably the version of MySQL with the biggest bundle of new features. You may want to try it soon, since it's now released as GA, and I would like to offer some practical experience on how to use some of the advanced features.

Since replication is my main interest, I will focus on some of the new features in this field, and I will compare what's available in MySQL 5.6 with Tungsten Replicator.

The focus of the comparison is usability, manageability, and some hidden functionality. Parallel replication has been available with Tungsten Replicator for almost two years, and Global Transaction Identifiers for much longer than that. With MySQL 5.6, it seems that the MySQL team wants to close the gap. While the main feature (parallel execution threads) is available and performing well, there are some shocking differences in terms of ease of use, administration …

Based on a lot of surprising comments about my MySQL 5.5 vs 5.6 performance post I decided to perform deeper investigation to see where my results could go possibly wrong. I had set up everything to be as simple as possible to get maximally repeatable results. I did Read Only ran which is typically a lot more repeatable (though also less relevant for production like workload). I had done number of iterations for benchmark run and I used dedicated physical hardware box so external environment impact often causing problems in Virtualized environments can be eliminated. Still I found there could be large variance between the runs.

I set up the benchmarks run to go over night in the loop, doing the benchmark run for 5 runs when restarting MySQL server and repeating the run. I did it on 2 identical boxes to eliminate faulty hardware as …

We are pleased to announce that MySQL Enterprise Monitor 2.3.13 is now available for download on the My Oracle Support (MOS) web site. It will also be available via the Oracle Software Delivery Cloud with the March update in about 3 weeks. This is a maintenance release that contains several new features and fixes a number of bugs. There are 13 new rules and 6 new graphs focused mainly on new features in MySQL Server 5.6. You can find more information on the contents of this release in the change log:

http://dev.mysql.com/doc/mysql-monitor/2.3/en/mem-news-2-3-13.html

You will find binaries for the new release on My Oracle Support:

https://support.oracle.com

Choose the "Patches & Updates" tab, and then use the "Product or Family …

I’ve said it before, and, as is the nature of these things, I’ll almost certainly say it again: your database performance is only as good as your indexes.

That’s the grand thesis, so what does that mean? In any DB system — SQL, NoSQL, NewSQL, PostSQL, … — data gets ingested and organized. And the system answers queries. The pain point for most users is around the speed to answer queries. And the query speed (both latency and throughput, to be exact) depend on how the data is organized. In short: Good Indexes, Fast Queries; Poor Indexes, Slow Queries.

But building indexes is hard work, or at least it has been for the last several decades, because almost all indexing is done with B-trees. That’s true of commercial databases, of MySQL, and of most NoSQL solutions that do indexing. (The ones that don’t do …