OurDelta build for MySQL 5.0.77 with patchset d8 is now available, in source and packaged binaries for RHEL/CentOS 4 and 5, Debian 4.0 (Etch) and 5.0 (Lenny), Ubuntu 8.04 LTS (Hardy) and 8.10 (Intrepid).

If you already installed the OurDelta repository information, yum update or apt-get upgrade will install the updated packages for you. Please do review the notes below.

Fixes, Changes & Additions:

• With Percona moving the patches it maintains to using bzr/Launchpad, we now simply pull those in as a subdirectory percona_maintained. The old separate patch dirs are …

Quite often fast databases, super-duper backend caching layers and other fancy stuff doesn’t help if you don’t serve your customer right. Take, for example, Twitter. This service has lots and lots of clicks, people following each other, in endless loops, trees, and probably serving occasional page-views.

I noticed that every click seemed to be somewhat sluggish, and started looking at it (sometimes this gets me free lunch or so ;-)

Indeed, every click seemed to reload quite a bit of static content (like CSS and JavaScript from their ‘assets’ service). Every pageview carrying information took 2s to serve, but static content slowed down the actual page presentation for three-six additional seconds.

Now, I can’t say Twitter didn’t try to optimize this. Their images are loaded from S3 and have decent caching (even though datacenter is far away from Europe), …

Ran into something I hadn't seen before with MySQL replication this morning (details obscured).

We use the MySQL replication slave option replicate-wild-ignore-table to prevent tables generated for short-term use like calculated data, projections, and reports from being duplicated on our hot spare machines.

So if you've told MySQL that no tables containing the phrase "projection_temp" should be replicated, why would you see the following in show slave status on the slave?

...
Replicate_Wild_Ignore_Table: db_%.projection_temp\_%
Last_Errno: 1146
Last_Error: Error 'Table 'db_12345.projection_temp_gdoivxtt' doesn't exist'
...


I looked at the message for a long time, trying to figure out how that database or table name violates the ignore table rule. The statement to create the table wasn't applied to the slave, as evidenced by the 'table …

One little bit of wisdom I would like to pass on:

If a program runs fast with 20 threads, that does not mean it will run fast with 50. And if it runs fast with 50, it does not mean that it will run fast with 100, and if it runs fast with 100 ... don't bet on it running fast with 200 :)

In my last blog I discussed some improvement to the performance of PBXT running the DBT2 benchmark. Despite the overall significant increase in performance I noted a drop off at 32 threads that indicated a scaling problem. For the last couple of weeks I have been working on this problem and I have managed to fix it:

As before, this test was done using MySQL 5.1.30 on an 8 core, 64-bit, Linux machine with an SSD drive and a 5 warehouse DBT2 …

Continuing my series of in depth looks at flash appliances, sans, and drives I spent a few weeks test driving the Violin Memory flash ( and DDR based ) solutions. Just from the specs the Violin Memory 1010 is impressive. According to the site the v1010 does 300K random reads per second and 200K random writes and has latency of less then 300 microseconds! That is pretty impressive!  But as I have stated before its difficult to test these limits with our current set of benchmarks.   For my test’s I did run this through the  ysbench fileio tests and dbt2 to get a feel for performance, but I was really eager to test the new juice db benchmark to really drive IO.  For the test Violin generously made available a 4 core (3.4Ghz ) server with 8GB of memory with access to a 360GB DDR based v1010 and then a 320GB DDR based v1010. Unlike the Ramsan I tested a …

As folks are making their plans to go to the MySQL User Conference, I just wanted to remind folks of the schedule of MySQL Camp.

One feature I put together for MySQL Camp but anyone can use is a restaurant list for the hotel area. There’s very little within walking distance, but many people will be local or will rent a car, so finding someone to drive with should not be a problem. The restaurant list is on the MySQL Forge Wiki at http://forge.mysql.com/wiki/SantaClaraRestaurants — updates are welcome!

About MySQL Camp: MySQL Camp is completely free, just walk on in and enjoy the sessions. All sessions are in the Bayshore room off the Mezzanine, and there will be signs directing you to the MySQL Camp room. I describe it as being like “an additional room for the MySQL Conference, but it’s …

MySQL is continuing to grow at a rapid pace in the market place. Continued high growth areas for MySQL continue to include the web application, gaming and embedded systems space. For small and medium sized OLTP environments MySQL continues to increase in popularity. MySQL can have incredible scalability as long as it scales horizontally. However with today's hardware adding more CPU and

So, I'm about to embark on this mad tour to bring MySQL to campuses from here to San Francisco. I'm looking forward to each campus, and especially to having Giuseppe, Sheeri and Colin join me in California.

We now have a mascot courtesy of our wonderful cartoonist based out of the UK and that's pretty much what I look like: a backpack, a sign but hopefully not stuck somewhere along the way. In most universities, I'll give an introduction to MySQL, but I'll be happy to chat about anything technical as well. We will see how it goes.

Again, if you are in any of the places I am about to visit, I would love to meet/chat with you!

But first, what does a dolphin pack into a backpack for two months of MySQL-related touring?

Essential gear:

- …

Signup now. You know you want to.

It’ll be awesome - we’re all gathering to change the future of databases (okay, well maybe just one database, but it’s the world to us…. and i should get out more).

Here’s a quick productivity tip: when optimizing queries by rewriting them to different forms that should return the same results, you can verify that you get the same results by taking a checksum of them.

Just set your pager to md5sum:

mysql> pager md5sum -
PAGER set to 'md5sum -'
mysql> select * from test;
a09bc56ac9aa0cbcc659c3d566c2c7e4  -
4096 rows in set (0.00 sec)