Group commit has an interesting history in MySQL. Peter opened bug 13669 for this many years ago. That bug has been closed and InnoDB announced that the plugin uses group commit. That is only true when the binlog is disabled. Things are more complicated when the binlog is enabled and I am not certain this is clear from the documentation.

There are three log writes during commit when the binlog is enabled. I have written about this before and am repeating myself to help the reader understand how group commit has been fixed in the Facebook patch. The log writes are:

1. Prepare InnoDB by forcing changes from the transaction to the InnoDB transaction log. This does an fsync on the transaction log file and that fsync can be shared by …

MySQL replication uses the term 'master' and 'slave' to refer to the machine which is be replicated from, and the machine that is being replicated to, respectively.  These terms are highly offensive to some people, given the history of slavery.  While the terms master/slave make sense for replication, given their offensive nature, perhaps MySQL should consider changing the terminology.

I suggest changing:
SHOW MASTER LOGS -> SHOW REPLICATOR LOGS;
SHOW MASTER STATUS -> SHOW REPLICATOR STATUS;

SHOW SLAVE STATUS -> SHOW REPLICATION STATUS;
START|STOP SLAVE [IO_THREAD|APPLY_THREAD] -> START|STOP REPLICATION [IO_THREAD|APPLY_THREAD]

The old commands can still work for backwards compatibility, but they should be deprecated.

MySQL replication uses the term 'master' and 'slave' to refer to the machine which is be replicated from, and the machine that is being replicated to, respectively.  These terms are highly offensive to some people, given the history of slavery.  While the terms master/slave make sense for replication, given their offensive nature, perhaps MySQL should consider changing the terminology.

I suggest changing:
SHOW MASTER LOGS -> SHOW REPLICATOR LOGS;
SHOW MASTER STATUS -> SHOW REPLICATOR STATUS;

SHOW SLAVE STATUS -> SHOW REPLICATION STATUS;
START|STOP SLAVE [IO_THREAD|APPLY_THREAD] -> START|STOP REPLICATION [IO_THREAD|APPLY_THREAD]

The old commands can still work for backwards compatibility, but they should be deprecated.

I’ve written a tool to profile a process’s IO usage. It works by gathering lsof and strace from a process, and then figuring out how the file descriptors, function calls, and filenames are all related to each other. The manual page has examples. I’m curious to see how it works for you. Note that it might be a good idea to run this on your development or staging system before you go running it against your production MySQL server – there are rumors of strace misbehaving on some kernels.

I have 4 connections created from a class as objects. Every connection open a database. My problem is the fact that I lost connection to one server for some reason, which I have no idea what it is. It could be working fine for days and then I had a lot of problems for the lost connection. I read in some pages about it and I found it was the error 1466. I read that I can test the connection so I used:

oException = SQLGETPROP(lnHandleGeneral, “Asynchronous”)
oException = SQLSETPROP(lnHandleGeneral, “Datasource”)

But I that creates me more errors and I can’t force the connection again… What should I do?

MySQL Replication is incredibly simple to get up and running and this (short) post steps you through it.

Simple Master -> Slave Replication

MySQL allows you to build up complex replication hierarchies, such as multi-master, chains of read slaves, backup databases at a remote site or any combination of these. This post focuses on a simple single master to single slave topology – the more complex solutions are built from this basic building block.

This post also makes the assumption that the 2 MySQL Servers have been installed but that there is no existing data in the master that needs to be copied to the slave – it’s not complex to add that extra requirement and it will be covered in a future post.

Server “black” (192.168.0.31) is to be our master and “blue” (192.168.0.34) the slave.

I know that MERGE isn’t everyone’s favourite storage engine but we use them quite extensively and ran into a problem the other day that I thought I’d share.

A common usage pattern is to CREATE TEMPORARY TABLE LIKE an existing MyISAM table and then ALTER TABLE to turn it into a MERGE table and specify it’s UNION. Like this:

CREATE TABLE tmpMerge LIKE a;
ALTER TABLE tmpMerge ENGINE=MERGE, UNION=(a,b);

It’s a pattern we’ve been using for ages and seems to work well in most cases.

In one application we keep aggregated data in daily tables (inspired by this article). Within the application we work out which of the daily tables we need and build them into a temporary merge table before querying it. There’s more to it than that (there’s a pyramid of …

My colleague Aleksandr Kuzminsky will be speaking at WebConf Riga 2010 next month on XtraBackup: Hot Backups and More and Recovery of Lost or Corrupted InnoDB Tables.

WebConf is the first big conference of its kind in the Baltic states (Estonia, Latvia, Lithuania) and we are very happy to be participating.

In addition to Aleksandr's talks, we will also be offering our training courses. You can find out more from the conference website (they will be publishing more information in the next two days).

Entry posted by Morgan Tocker | No comment

Add to: …

As I previously noted, I’m in the midst of converting some data (roughly 2 billion records) into documents that will live in a MongoDB cluster. And any time you move data into a new data store, you have to be mindful of any limitations or bottlenecks you might encounter (since all systems have had to make compromises of some sort or another).

In MySQL one of the biggest compromises we make is deciding what indexes really need to be created. It’s great to have data all indexed when you’re searching it, but not so great when you’re adding and deleting many rows.

In MongoDB, the thing that gets me is the document size limit. Currently an object stored in MongoDB cannot be larger than 4MB (though that’s likely to be raised soon). Now, you can build your own MongoDB binaries and tweak that parameter, but I’ve been …

There are more sites out there that have their backends running MariaDB. In fact, as we work to get it recommended alongside its upstream provider, it seemed time to have “Powered by MariaDB” logos. Check out the badges that Daniel created. Feel free to copy the images or hotlink them from the server.

As an aside, would any readers be interested in purchasing t-shirts or other MariaDB merchandise? What merchandise should we make, besides just stickers?