Peter and Arjen will be at DrupalCon SF 2010. Peter specifically for the event, Arjen staying around the SF area after the MySQL Conference last week.

Specifically, we’ll be talking with people about using the OQGRAPH engine to help with social graphs and other similar problems, easily inside Drupal. You may recall that Peter already created the friendlist_graph extension for the friendlist Drupal module.

From the MySQL Conf and other earlier feedback, OQGRAPH is proving to be a real enabler. And since it’s free/GPLv2 and integrated in MariaDB 5.2, there’s generally no hindrance in starting to use it.

Oracle outlines MySQL plans. Datameer launches with Series A funding. And more.

Follow 451 CAOS Links live @caostheory on Twitter and Identi.ca
“Tracking the open source news wires, so you don’t have to.”

# Oracle confirmed InnoDB as the default MySQL storage engine, Hot Backup to become part of MySQL Enterprise and announced MySQL Cluster 7.1.

# Datameer launched Analytics Solution, which combines Hadoop with a spreadsheet interface, and also closed a $2.5m Series A round of funding from Redpoint Ventures.

# Infobright announced that it grew its customers base from 50 to …

Walter and I are giving a tutorial on Monday morning, MySQL (and MariaDB) Dual Master Setups with MMM, I believe there are still some seats available – tutorials are a bit extra when you register for the conference, so you do need to sign up if you want to be there! It’s a hands-on tutorial/workshop, we’ll be setting up multiple clusters with dual master and the whole rest of the MMM fun, using VMs on your laptops and a separate wired network. Nothing beats messing with something live, breaking it, and seeing what happens!

Then on Tuesday afternoon (5:15pm, Ballroom F), Antony and I will do a session on the OQGRAPH engine: hierarchies/graphs inside the …

In our March DBJ article we talked about some of the storage engines to choose from with MySQL.  With it’s plugin storage engine architecture, you have a range of options.  In our April article we continue to discuss a further selection of storage engines, and what features they offer to the DBA and database architect.

Database Journal – Exotic Storage Engines

On this big trip, I made particular effort to finally visit Monty at his home near Helsinki. Somehow, in all my years at MySQL AB, this never happened – a sad omission. So, I spent the Easter days with Monty, Anna and now 5yo Maria.

I’m not a fan of most meetings, and in many cases in-person meetings are not actually necessary to get things organised or done, but I think this was both most enjoyable as well as productive for our respective businesses and joint interests. Good company, discussion, food, drink, sauna… fabulous.

It’s a great pity we live on opposite sides of the planet, as we do get along very well together. We definitely don’t agree on everything, but we’re always absolutely direct with each other, and try to provide good arguments whenever we disagree, to explore things further.

Gentoo
It started with Brian Evans’ github repository, some good instructions on the mailing list for Building MariaDB on Gentoo, to a request for packaging, and guess what? Its now officially in Gentoo! Thanks Brian, and Robin Johnson!

SPARC builds – Debian, Solaris
Mark has now got a MariaDB category on his blog and the interesting things for you to grab are: …

Dear MariaDB users,

MariaDB 5.1.44, a new branch of the MySQL database which includes all major open source storage engines, myriad bug fixes, and many community patches, has been released.

This release is based on MySQL 5.1.44. In includes performance improvements with Maria temporary tables, removal of mutexes and the aim of removing compiler errors is being achieved quite well! For an overview of what’s new in MariaDB 5.1.44, please check out the release notes.

For information on installing MariaDB 5.1.44 on new servers or upgrading to MariaDB 5.1.44 from previous releases, please see the installation guide.

MariaDB is available in source and binary form for a variety of platforms and is available from the …

Earlier this month, I was at the OpenSourceDays 2010 conference, giving a talk on MariaDB (the slides from the talk are available).

The talk went quite well I think (though I probably talked way too fast as I usually do; at least that means that I finished on time with plenty room for questions..)

There was quite a bit of interest after the talk from many of the people who heard it. It was even reported on by the Danish IT media version2.dk (article in Danish).

Especially interesting to me was to discuss with three people from Danish site komogvind.dk, who told me fascinating details about their work …

What’s the difference between INT(2) and INT(20) ? Not a lot. It’s about output formatting, which you’ll never encounter when talking with the server through an API (like you do from most app languages).

The confusion stems from the fact that with CHAR(n) and VARCHAR(n), the (n) signifies the length or maximum length of that field. But for INT, the range and storage size is specified using different data types: TINYINT, SMALLINT, MEDIUMINT, INT (aka INTEGER), BIGINT.

At Open Query we tend to pick on things like INT(2) when reviewing a client’s schema, because chances are that the developers/DBAs are working under a mistaken assumption and this could cause trouble somewhere – even if not in the exact spot where we pick on it. So it’s a case of pattern recognition.

A very practical example of this comes from a client I worked with last week. I first spotted some harmless ones, we talked about it, and then we hit …

We don’t often see this option configured (default: unlimited) but it might be a good idea to set it. What it does is limit the amount of disk space the combined relay logs are allowed to take up.

A slave’s IO_Thread reads from the master and puts the events into the relay log; the slave’s SQL_Thread reads from the relay log and executes the query. If/when replication “breaks”, unless it’s connection related it tends to be during execution of a query. In that case the IO_Thread will keep running (receiving master events and storing in the relay log). Beyond some point, that doesn’t make sense.

The reason for having two separate replication threads (introduced in MySQL 4.0) is that long-running queries don’t delay receiving more data. That’s good. But receiving data is generally pretty fast, so as long as that basic issue is handled, it’s not necessary (for performance) to have the IO_Thread run ahead that far. …