Some of the utilities we were adding to Maatkit really did not belong there. Yes, this included some of the functionality in the now-retired mk-audit tool. We really learned a lesson about what it’s possible to support, design, spec, code, and test in a single tool.

I’ve moved those tools to a new project, Aspersa. Some folks are revolting and calling it Asparagus, because apparently that’s easier to say. Aspersa is the name of the common garden snail, which turns out to be a fascinating creature. It is also slow. Draw your own conclusions.

This project is more of a home for simple scripts and snippets — a simple place I can grab all the little utilities I use to make my life easy. There is a “summary” tool that largely replaces mk-audit’s functionality outside the database, and I plan to add a …

The DECIMAL datatype is a datatype in MySQL that provides additional precision over FLOATs or DOUBLEs at the expense of arithmetic. You specify the precision by using
datatype-name DECIMAL
or
datatype-name DECIMAL(8)
or
datatype-name DECIMAL(10,4)

MySQL uses roughly 4 bytes for every 9 digits either side of the decimal.

The english definition (http://www.thefreedictionary.com/decimal) would assume that when you specify the DECIMAL datatype you would want to insert numbers with fractions.

This however is not the case. Lets show this:

mysql> create database decimal_madness;
Query OK, 1 row affected (0.00 sec)

mysql> use decimal_madness;
Database changed
mysql> create table test1 ( tmp decimal);
Query OK, 0 rows affected (0.10 sec)

mysql> insert into test1 values(1.1);
Query OK, 1 …

Working on a production/test servers would always need you to be ready with your rescue tools, be it third party tools or commands and scripts to help you troubleshoot and monitor the database servers. Usage of the third party tools will be pretty easy to manage or monitor your databases through a GUI. However how many of us DBA’s would monitor the databases from command line very often?

Here are few scripts that I found online which I would like to post for your quick reference. Please find attached the scripts and follow the usage instructions.

allschemas.sql

or copy the following to a notepad and save it as allschemas.sql

**************************************

Purpose: List a summary of all Instance Schemas including disk size

**************************************

SELECT NOW(), VERSION();

(this probably applies exactly the same for MySQL and Drizzle… but I’m just speaking about current Drizzle here)

In my current merge request for the embedded-innodb-create-select-transaction-arrgh branch (also see this specific revision), you’ll notice an odd hoop that we have to jump through to make CREATE SELECT statements work with an engine such as InnoDB.

Basically, this is what happens:

• start transaction
• start executing SELECT QUERY (well, …

MySQL replication support for the Pacemaker cluster manager (the stuff that we explained in this webinar) has made it into the Linux-HA resource agents default branch. If you are interested in testing — and you should! — please read the extended announcement. Feedback is extremely welcome on the linux-ha-dev mailing list.

We are expecting to release this as part of resource-agents 1.0.4, in late May/early June. …

Have you ever run into a problem where MySQL replication did 95% of what you needed but not the remaining 5% to solve a real problem?  Hacking the binlog is always a possibility, but it typically looks like this example.  Not a pretty sight.  Wouldn't it be easier if replication were a bunch of building blocks you could recombine to create custom replicator processes? 

Tungsten 1.3 has a new feature called pipelines that allows you to do exactly that.  A pipeline consists of one or more stages that tie together generic components to extract, filter, store, and apply events, which is Tungsten parlance for transactions.  Each stage has a processing thread, so multi-stage pipelines can process data independently and without blocking.  The stages also take care of important but tedious issues like remembering the transactional …

I’ve released version 1.1.7 of the Better Cacti Templates project. This release includes a bunch of bug fixes, some new graphs for MySQL, and two new sets of graphs, for Redis graphing and for JMX graphing.

There are upgrade instructions on the project wiki for this and all releases. There is also a comprehensive tutorial on how to create your own graphs and templates with this project. Use the project issue tracker to view and report issues, and use the project mailing list to discuss the …

As I said at the end of the Day 3 post, I did well enough at the Ignite session that I "won" the opportunity to give it again. There was some confusion about the right time to be seated, and some of the "winners" were not actually properly informed of what they had "won". Fortunately, IM conversations sorted most of it out, and Gerry, Sarah, Gillian, and myself reprised our talks.





I got the opportunity to take notes at the MySQL Ecosystem Summit, but instead spent the time taking in a few more sessions. It was a hard choice, and from what I learned later about the cool discussions at the summit, I think I may have made the wrong choice.

There were some sessions I was glad to have gone to, however. The best was Paul Vallee's "Worst Practices of Database Outsourcing Infrastructure Support", which was an excellent "peopleware" presentation on, well, exactly what it says on the tin, how …

Proofs of Concept Last week at the MySQL conference in Santa Clara, I presented some slides on our work towards group commit on the MySQL binlog. We examined the effects of not holding the prepare_commit_mutex across the binlog fsync, combining this with a timed wait on a condition variable to enable binlog group commits, and then we explored the effect of releasing row locks during the prepare step instead of in the commit step.

The proof-of-concept code I worked on up to that point made me very quite familiar with the parts of the MySQL codebase that these changes are in. Energized by the MySQL conference, I got to work on writing some production-quality patches that are taking Facebook's MySQL 5.1 towards the performance gains we discussed at the conference.

Patches for Production The first step was to set up some new performance monitoring so we could understand the effects of the changes as we made them. The first patch keeps …

Much has been made of certain limitations of MySQL’s query optimizer (“planner”). Subqueries, lack of sort-merge joins, and so on. This is not MySQL-bashing and no one should be offended. Some people have worked to make things better, and that code is in branches that were intended for future releases. But if that work were available right now, would you trust it? This question is important because the optimizer is complex and full of compromises and black magic.