Clustered computing brings with it many benefits: high performance, high availability, scalable infrastructure, etc. But it also brings with it more complexity.

Why?

Well, by its very nature, there are more “moving parts” to monitor and manage (from physical, virtual and logical hosts) to clustering software to redundant networking components – the list goes on. And a cluster that isn’t effectively provisioned and managed will cause more downtime than the standalone systems it is designed to improve upon.

When it comes to the database industry, analysts already estimate that 50% of a typical database’s Total Cost of Ownership is attributable to staffing and downtime costs. These costs will only increase if a database cluster is not effectively monitored and managed.

Monitoring and management has been a major focus in the development of the …

Until now, MariaDB 5.2 was lacking a yum repository for easy installs and upgrades. It is now available, thanks to OurDelta.

Just follow our very simple installation instructions.

While looking at partitioning I recently made a mistake which I guess can happen to others. Often this is due to not fully reading the documentation or scanning it too quickly and misunderstanding what’s being said.

So this post is to complain about the MySQL partitioning syntax and to warn others who may easily make the same mistake without realising.

First we probably need to ask why we are partitioning a table in the first place. The main reasons for this are I think:

• to improve query performance
• to reduce individual .ibd file sizes for large tables (if using innodb_file_per_table)

In my case I wanted to do both. I had a several tables which store a large number of rows (batches of data) based on an incremental batch number. One of these tables was around 40 GB and had about 500,000,000 rows in it.  When processing data in this table often all the data from a particular batch …

We interviewed Alexander "Bar" Barkov to discuss the recent improvements in MySQL globalization that enable MySQL users around the world to use the database system more easily and naturally.

Mark Callaghan blogged this: http://www.facebook.com/note.php?note_id=10150236650815933

He refers a bug report that has now  been marked as private for some reason. I have been subscribed to it from the beginning (and thus have all details in my inbox) and I think Mark misses the point raised by the bug reporter here.  Mark has another and equally important point.  What they have in common is that there are situations where a statement longer than max_allowed_packet is written to the binlog.  If the host where it happens is a replication master there are scenarios where this will break replication where it should not.

The ‘how to repeat’ section of the original report (that was verified by inspection of the binlog) reads:

1) Make sure the max_allowed_packet variable is set to 16777216 in MySQL.
2) Make …

I hope everyone is enjoying summertime, at least in the northern hemisphere. I’m about to head out to the pool, but before I go, here is a summary of this week’s blog posts.

1. Introduction to Perl interface for Monitis API
Monitis announces a simple way to access its API through Perl, a high-level, general-purpose, interpreted, dynamic programming language. This post demonstrates some examples for using the API with Perl and describes some of the benefits of the programming language. The source can be found on our Github page.

2. 101 Tips to MySQL Tuning and Optimization …

Hello everyone, here we go for a new blog post and now treating about InnoDB inside MySQL 5.5 and as you should now, this new version uses InnoDB Plugin version 1.1 which one has a lot of new adjustable resources. What most caught my attention was the impressed way that users could adjust it to have [...]

So it's a good complement.

So it's a good complement.

I'm glad to see this. I'm adding it to my Google Listen subscription.