I?ve recently done a quick scalability test with MySQL 5.0 and 5.1 to check the new auto-inc patch with InnoDB and to see how MySQL 5.1 scales with InnoDB:

New in MySQL 5.1: innodb_autoinc_lock_mode = 1 (?consecutive? lock mode)
With this lock mode, ?simple inserts? (only) use a new locking model where a light-weight mutex is used during the allocation of auto-increment values, and no AUTO-INC table-level lock is used, unless an AUTO-INC lock is held by another transaction. If another transaction does hold an AUTO-INC lock, a ?simple insert? waits for the AUTO-INC lock, as if it too were a ?bulk insert.?
http://dev.mysql.com/doc/refman/5.1/en/innodb-auto-increment-handling.html#innodb-auto-increment-configurable
This fixes the …

Today I attended to first MySQL AB conference in Milan (Italy). They have presented the new services and the new italian team.

It was also the occasion to meet some friend.

Well MySQL AB, enjoy your business in Italy.

The 1.5.2 release of innotop contained two bugs, one very minor. The other was a crash because of the new functionality that aggregates results across many connections. I fixed them and released version 1.6.0, which I consider stable and ready for everyone to use. (My version naming convention for innotop is that even-numbered minor versions are for production use; odd-numbered, such as 1.5.2, are the development branch. That’s why I release them under the innotop-devel package).

I created MySQL Table Checksum because I was certain replication slaves were slowly drifting out of sync with their masters, and there was no way to prove it. Once I could prove it, I was able to show that replication gets out of sync for lots of people, lots of times. (If you really want to hear war stories, you should probably talk to one of the MySQL support staff or consulting team members; I'm sure they see this a lot more than I do).

I finally figured out what was causing one of my most persistent and annoying out-of-sync scenarios. It turns out to be nothing earth-shaking; it's just an easy-to-overlook limitation of statement-based replication. You could call it a bug, but as far as I can see, there's no way to fix it with statement-based replication. (I'd love to be proven wrong). Read on for the details.

One of the biggest complaints I’ve had with HTML_QuickForm is not producing valid XHTML Strict code. Well there is a simple solution to removing the name attribute of the HTML form element tag using remoteAttribute().

Example
$form->removeAttribute(’name’);

ShareThis

Thinking I had something new, I wrote this article about recovering deleted files. However, it turns out Frits Hoogland had already blogged about recovery of deleted files on linux, as Frits pointed out in a comment on my blog, where he also mentioned a metalink note on this matter. The note ID is: 444749.1 “Retrieve deleted [...]

Seattle will soon be attacked by giant sea monsters with radiation
breath!

(... or was that Japan...)

Who is going to stop them?

Skykee the Spy Robot! (http://www.erectorusa.com/category_pages/spykee.html)





All those years spent during childhood learning how to build ferris wheels and big choppy machines with my erector set, those skills may finally be of use!

(...unlike my graduate degree...)

From the copy:

Build your spy robot and control Spykee from anywhere in the world via the internet through a wifi connection.

If this copy is right, I'll take three. Maybe four... One for each cat and dog in the house, and a final …

Could commercial open source become a victim of its own success? Is the industry putting too much pressure on its flag-bearers to get rich quick? I’ve been meaning for some time to mention this article by MySQL CEO, Marten Mickos entitled “How to be a disruptor”. One of Marten’s tips for success jumped out at me: “Get rich slow”.

“When I see the fantastic growth MySQL is experiencing now, I never forget that it took us 12 years to get here,” he writes. “For the first six years, the team focused exclusively on perfecting the product…. Startups wanting to copy our success need to be aware of the significant ramp-up we invested in.

“Because the MySQL database is an infrastructure product, that growth probably took longer than it would have for an application or consumer product. But the growth phase of the company really did not …

Incredible, but true.  It seems that MySQL AB will be exhibiting next week at Oracle Open World.  This of course isn’t the first time a competitor would advertise or exhibit on it’s rival’s home turf.  Still it certainly signals a changing landscape, and heats up the battle for market share.

Here’s a longer list of exhibitors at the conference.  I don’t see Enterprise DB there, but anything’s possible.  You will see RedHat as well as Suse, now owned by Novell, represented there as well.  Also if you make it to the conference, be sure to visit the Oracle pavilion section, where there are sure to be smaller booths for …

"I heard it is faster if I use server side prepared statements" - Many people
Possibly - but it's not necessarily the silver bullet it's described as.

A little bit of background:
A server side prepared statement allows you to first prepare a query on the server side, without actually specifying the values at all.

INSERT INTO users (username, email, password) VALUES (?, ?, ?);

This is step 1. From here, the application now only needs to send the individual values to the server next time, and not repeat the entire query (step 2).

The values will also be sent using the binary protocol so they do not need to be escaped in the same way they would in a regular query. There is no SQL parsing overhead, and certain steps of the execution plan have already been figured out.

Sounds great, why this doesn't always convert to being faster? …