Whether you’re working with MySQL, MySQL Cluster, or any other RDBMS, every database with a requirement for persistent data should always have a backup. As a Production DBA you’re the insurance policy to safeguard the data. Bad things do happen. Backups are your safety net to ensure you always have a way to recover should the worst happen and the database becomes irreparable.

There are many ways to produce a consistent backup of MySQL, I have listed a few of the options available below; Remember backups are your safety net, failing to retrieve a consistent backup when you need it most can be a very career limiting move, so no matter what backup method you choose always test your backups!

Logical Backups
The ever popular mysqldump is a backup and export utility provided with the MySQL binaries …

A couple of things:

1. There is now a Monty Program Group Blog. Its brand new, and in a company where most people spend time on writing tonnes of code, expect posts to be sporadic, but of great technical nature. We’ll also cover things like events, conferences, etc. i.e. where can you meet a Monty Program person. Do subscribe to our RSS or ATOM feed.
2. At the MySQL Conference recently, Monty announced the rename the Maria engine contest. The competition is still running, and the winner gets a System76 Meerkat NetTop. Some interesting names have already shown up. …

Percona wants to upgrade our documentation to improve its readability
and to make it more useful for you, our clients and partners. We are
so busy developing software and handling your needs that we have
trouble finishing all the documentation! We think you can help.

Helping us will give you a chance to interact closely with lead Perona
developers and learn more about Percona's products as well as our
development process.

Tasks include talking to developers, writing text, and interacting
with an editor. (Andy Oram, our O'Reilly editor on the book High
Performance MySQL, will take on the volunteer role.) You should have
some understanding of MySQL and Percona's extensions, and of way
XtraDB and XtraBackup work.

Documents we want to start with include:

* Product features (we made a …

It is with interest that I read Kristian's three blogs on the binary log group commit. In the article, he mentions InnoDB's prepare_commit_mutex as the main hindrance to accomplish group commits—which it indeed is—and proposes to remove it with the motivation that FLUSH TABLES WITH READ LOCK can be used to get a good binlog position instead. That is a solution—but not really a good solution—as Kristian points out in the last post.

The prepare_commit_mutex is used to ensure that the order of transactions in the binary log is the same as the order of transactions in the InnoDB log—and keeping the same order in the logs is critical for getting a true …

A now-famous quote that I probably don’t need to attribute: “First they ignore you, then they laugh at you, then they fight you, then you win.”

Where is Drizzle in this lifecycle? I’ve been hearing and reading some comments to the tune of “those Drizzle guys think it’s easy to rip MySQL stuff out and start over, wait till they see how hard it’s going to get when the real world sinks in.” Maybe, maybe. But maybe not, too. Maybe not.

I’ve seen more than one software project that was belittled as “never gonna amount to anything, save your time” and went on to do quite well. Never underestimate the power of a handful of passionate and talented people. I personally feel that Drizzle has a bright future.

Related posts:

1. Please re-license the MySQL documentation In the pas …

This is part two of an ongoing series about my experiences while writing the MySQL Admin Cookbook for Packt Publishing. All previous parts can be found under the mysql-admin-cookbook label.

While last time I focused on the initial contact with the publishing company (just referred to as "Packt" from now on), this issue is about the process of putting together an outline proposal and coming up with things to write about in the first place. As from this point on in the process Udo was involved with everything, I will be referring to "us" and write "we" most of the time from now on.

The Publisher's Expectations

The only thing we knew about the …

We then finally came to the topic that comes naturally to anyone familiar with the MySQL architecture. Could Hadoop, or Hive, or whichever, be plugged into MySQL as a storage engine? And why would you want to do that? And can Timour's work to push down JOIN conditions be of any help? (The last question was interesting since Ted and his team were inherently against talking about JOINs at all :-)

We ended up concluding that 2 things could be interesting and considered "low hanging fruit":

SQL to PIG compiler.

(Btw, it is not immediately obvious if this task needs MySQL at all.)

read more

Check out this SlideShare Presentation: I'd have to say that this is the coolest presentation on Indexing and how it relates to INNODB. I have written on this subject many times in the pass but this presentation covers all the bases and does a great job at explaining WHY you should do certain statements over others.More mastering the art of indexingView more presentations from Yoshinori Matsunobu.

So, we can have a look at this improvement, which I am sure will make DBAs quite happy. The new feature is an instantaneous exchange between a partition and a table with the same structure. Using this feature, you can transfer the contents of one partition to one table, and vice versa. Since the transition is done only in the attribution of the data, there is no copy involved. The data …

Sometimes you find yourself in a bad situation where your only hope of recovering your InnoDB data lies in a handful of .frm and .ibd data files that were heretofore part of a working MySQL installation. It could be the case that someone thought backing up InnoDB tables was simply a matter of of copying the .ibd and .frm files somewhere safe. That mostly works for MyISAM files right? Perhaps your system table space (ibdata1) became corrupted or was accidently deleted. Whatever the reason, you have a handful of .frm and .ibd files, and what you want is them imported into a functioning database.

The basics of how to do this are not too hard to understand, it’s the details that get tricky. The first part of this problem is how to extract the table definition from the .frm files. I’ll cover the second part of the problem in another post. You could write a program that reads and parses the .frm file and outputs the table definition, but …