There is a nagios plugin available on the MMM's google-code page, but if you didn't find it yet, here it is:

http://code.google.com/p/check-mysql-all/wiki/check_mmm

You can call this plugin over nrpe. I'm already working on to fork a version which more useful with passive checks.

This plugin was developed by Ryan Lowe (Percona).

We got good responses to the “identify this query profile” question. Indeed it indicates an SQL injection attack. Obviously a code problem, but you must also think about “what can we do right now to stop this”. See the responses and my last note on it below the original post.

Got a new one for you!

You find a system with broken replication, could be a slave or one in a dual master setup. the IO thread is still running. but the SQL thread is not and the last error is (yes the error string is exactly this, very long – sorry I did not paste this string into the original post – updated later):

“Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you …

In Part 1 of this article, I took you through some of the reasons why a column-oriented database based on MySQL can be compelling. We also examined the architecture of InfiniDB, which is an open source analytic, reporting, and read-intensive database, and how its modular design helps you scale both up and out. Now let’s kick the tires of the database so you can see these things in action.

I have for the first time seen a client implement MySQL Resource Limits. I got the following error tying to connect to the database.

$ mysql -udba -p
ERROR 1226 (42000): User 'dba' has exceeded the 'max_user_connections' resource (current value: 10)

I see from the documentation the ability to see the limits in the mysql.user table. I see this is included in the SHOW GRANTS output.

SHOW GRANTS for 'dba'@'%';
+--------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for dba@%                                                                                                                         |
+--------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL …

So you're using explicit transactions. Everything appears to work (every query gives the expected result) until you get to COMMIT.

Then you get an exception thrown from COMMIT. What happened?

Usually this would be because the server has been shut down, or you've lost the connection.

The problem is, that you can't assume that the commit failed, but you also can't assume it succeeded.

A robust application must make NO ASSUMPTION about whether a failed commit did, indeed, commit the transaction or not. It can safely assume that either all or none of it was committed, but can't easily tell which.

So the only way to really know is to have your application somehow remember that the transaction MIGHT have failed, and check later.

Possible solutions:

• Ignore it and deal with any inconsistencies manually, or decide that you don't care :)
  …

We know all too well that most companies face database scalability and administration problems. We're working hard to make RethinkDB as fast, scalable, and flexible as possible. We use a little bit of magic and a lot of engineering for today's hardware and access patterns. You can help by telling us what your infrastructure and workloads look like. We want you to tell us about your database problems, and in exchange we'll send a RethinkDB sweatshirt to the best responses.

You can find the survey at http://www.rethinkdb.com/survey/. If you'd like us to follow up with you, make sure to check off the last checkbox. If you're in the Bay Area, we'll be happy to …

In this installment of my Drizzle Replication blog series, I'll be talking about the Transaction Log. Before reading this entry, you may want to first read up on the Transaction Message, which is a central concept to this blog entry.

The transaction log is just one component of Drizzle's default replication services, but it also serves as a generalized log of atomic data changes to a particular server. In this way, it is only partially related to replication. The transaction log is used by components of the replication services to store changes made to a server's data. However, there is nothing that mandates that this particular transaction log be a required feature for Drizzle replication systems. For instance, Eric Lambert is currently working on a Gearman-based replication service which, …

If you want a quick overview of the InfiniDB architecture and feature set, check out Part 1 of an article I wrote for the MySQL Dev Zone.

Part 2 of the article should post tomorrow and will have examples of bulk load operations and queries so you can see how InfiniDB works.  Let me know what you think. And be sure to download InfiniDB and kick the tires yourself.