During the last month, MySQL code has been migrated from BitKeeper to Bazaar. Bazaar is a distributed, free revision control system sponsored and supported by Canonical, the company behind the fast-growing Linux distribution Ubuntu.

We have migrated all MySQL code trees that were available in BitKeeper. This means not just current GA and development versions of MySQL Server and MySQL Cluster, but also the history all the way back to MySQL 3.23.22 released about eight years ago. And we’ve also migrated non-MySQL-server FOSS applications to Bazaar, such as MySQL Workbench (formerly not in BitKeeper but in Subversion, also known as svn) and our internal QA suites.

…

I have put up a new version of the Dimensioning Toolkit.
Now, there is a particular version for MySQL Cluster 6.2 and MySQL Cluster 6.3.

The reason for this split is that the libraries and include files are in different locations (include/ and lib/ in 6.2, but lib/mysql and include/mysql in 6.3).
I don't know why the build team changes this between versions (even builds) and so often... very annoying.

Anyways, follow the links to download:

Dimensioning Toolkit for MySQL Cluster 6.2
Dimensioning Toolkit for MySQL Cluster 6.3

This blog posting has little to do with MySQL or Sun. It’s about experiences gathered while shuttling around the world as MySQL’s Ambassador to Sun, but it’s not about databases, it’s not about operating systems, nor computer languages: it’s about human languages, and how going beyond English provides a business advantage.

Let me try to grab your attention by first sharing my perhaps somewhat controversial conclusion:

English as a language of communication is much overrated. In an international setting, English may be sufficient for conveying meaning, but it has severe deficiencies when it comes to establishing a social relationship, to showing respect, to building trust, and to having fun.

For many years, I have attempted at learning how to say “thank you” and “please don’t smoke” and “where is …

I got a few questions about how to configure the cluster for disk data.
The new version of the Dimensioning Toolkit does a better job calculating:

• UNDO LOG file size
• TABLESPACE size
• UNDO Buffer size

What I write about below is taken into account in the Dimensioning Toolkit. Moreover, the things below only applies to disk data tables (read about the generic stuff about them in the reference manual).

UNDO LOG and UNDO BUFFER
Disk data tables make use of an UNDO log and an UNDO buffer.
The size of the undo log and the undo buffer is specified when you create the logfile group.

I recommend setting:

• UNDO log size = 4 to 6 times the DataMemory, thus the same size as for the REDO log.
  
• UNDO buffer size= …

To coincide with EURO 2008, I’m embarking on a virtual European tour, taking a quick look at open source policies and deployment projects in the 16 nations that are competing in the tournament.

Sweden crashed out of EURO 2008 last night a Russia qualified for the knockout stages with a well-deserved 2-0 win. As home to MySQL Sweden might be expected to be one of the more progressive adopters of open source but while there is significant interest, details of deployment projects are relatively hard to find.

Key policies:
The Swedish Agency for Public Management?s 2003 …

Not sure if the post title actually reflects the contents. 

This post describes how you can obtain the traces that MySQL server leaves behind for you if you ask it to. Once you have the traces, you can use it for:

• Debugging - It can help you to find out which source file is the server crashing, for eg.
• Learn- learn more about which functions/methods are called for a particular query by the client

Okay, so lets start.

Traceable Server

To be able to obtain traces, your server needs to be compiled with "debug" enabled. If the version information shows you something like this:

Ver 5.1.24-rc-debug for pc-linux-gnu on i686 (Source distribution)

with 'debug' appended to the version name, then you have a traceable server, else you will have to recompile it by enabling debug support:

./configure …

Not sure if the post title actually reflects the contents. 

This post describes how you can obtain the traces that MySQL server leaves behind for you if you ask it to. Once you have the traces, you can use it for:

• Debugging - It can help you to find out which source file is the server crashing, for eg.
• Learn- learn more about which functions/methods are called for a particular query by the client

Okay, so lets start.

Traceable Server

To be able to obtain traces, your server needs to be compiled with "debug" enabled. If the version information shows you something like this:

Ver 5.1.24-rc-debug for pc-linux-gnu on i686 (Source distribution)

with 'debug' appended to the version name, then you have a traceable server, else you will have to recompile it by enabling debug support:

./configure …

Few days back, one of my colleagues posted a good question. It sounds something like this;

"Temporary tables are session based that means under different sessions we can create temporary tables with similar names. Now since slave thread is singleton, how does it manage to keep them separate?"

He was very much right in asking this and the answer is not all that intuitive. Lets go through the binlog events to see why it is not that intuitive.

   1: mysql> SHOW BINLOG EVENTS IN 'log-bin.000016';

   2: . . .     

3: | log-bin.000016 |  389 | Query       | 2515922453 |         488 | use `test`; CREATE TEMPORARY TABLE test.t(a int)         |    

4: | log-bin.000016 |  488 | Query       | 2515922453 |         582 | use `test`; INSERT INTO test.t(a) VALUES(1)         |    

5: | log-bin.000016 |  582 | Query       | 2515922453 |         676 | use `test`; INSERT INTO test.t(a) VALUES(3) …

I work on the MySQL Enterprise Tools team, formerly of MySQL and now with Sun Microsystems. The 2.0 version of the Enterprise Monitor is well under way. As part of this, the Java server backend has been refactored to utilize Spring and Hibernate. Honestly, I didn't know either one of those technologies before starting this project. Oh, what a fun road it has been...

A big draw for using an off-the-shelf ORM was so that we didn't have to write our own (kind of bad and slightly wrong -- those darn transactions) caching implementations for the custom one-off ORM that existed previously. A lot of our internal meta-model is very static, so …

In MySQL, it's possible to comment out portions of code that you only want to work in specific MySQL versions:

i.e.
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `a` /*!40100 DEFAULT CHARACTER SET latin1 */;

The problem with this, is that the decimal point is omitted - and there's a real assumption that with something like 3.23.12 the "12" portion never exceeds 99.

When I look at 5.0, MySQL is currently at 5.0.60 - and there are still minor changes happening. 5.1 is at 5.1.25, and not even GA. Assuming that 5.1 does the same community/enterprise split and shuffles through releases in even numbers, how long will it take before we have 5.1.100?

If we do get there, the SQL commenting feature will need upgrading.