I’ll be giving my new “Advanced CouchDB” talk at the Dutch PHP Conference (DPC) in June. I’m looking forward to go to Amsterdam again after ApacheCon EU a few weeks back.

The talk will be about different data modelling patterns, making the most of views, building distributed applications with replication and share some hints on high-performance.

DPC’s line up looks pretty sweet. I like that it focusses on advanced topics. This is something I see missing from other conferences and I hope to see some interesting talks and I hope that mine is worthwhile and interesting enough for you :)

PS: The Early Bird registration ends April 30th

#dpcthursday

I’ll be giving my new “Advanced CouchDB” talk at the Dutch PHP Conference (DPC) in June. I’m looking forward to go to Amsterdam again after ApacheCon EU a few weeks back.

The talk will be about different data modelling patterns, making the most of views, building distributed applications with replication and share some hints on high-performance.

DPC’s line up looks pretty sweet. I like that it focusses on advanced topics. This is something I see missing from other conferences and I hope to see some interesting talks and I hope that mine is worthwhile and interesting enough for you :)

PS: The Early Bird registration ends April 30th

#dpcthursday

One question that I discovered the answer to a while back that I want to share is how to switch from using InnoDB tablespace files to using file-per-table– without having to dump and then reload data. Using file-per-table might give you some performance gain because of the fact that it allows de-fragmentation of the table’s data file using OPTIMIZE TABLE vs a single (or double) tablespace file.

If you change your my.cnf to using file-per-table as the example below shows:

innodb_file_per_table

Then of course, restart MySQL.

Then all subsequent tables created using the InnoDB storage engine will be created having their own separate tablespace file. The issue here then is, what about existing InnoDB tables? They still exist in the main tablespace files.

root@hanuman:/var/lib/mysql# ls -l ibdata*
-rw-rw---- 1 mysql mysql 60817408 2009-04-09 12:21 ibdata1
root@hanuman:/var/lib/mysql# ls -l webapp
total …

In my last blog, I introduced my investigation of the "Pool-of-Threads" scheduler in MySQL 6.0. Read on to see where I went next.

I now want to take a different approach to comparing the two schedulers. It is one thing to compare how the schedulers work "flat out" - with a transaction request rate that is limited only by the maximum throughput of the system under test. I would like to instead look at how the two schedulers compare when I drive mysqld at a consistent transaction rate, then vary only the number of connections over which the transaction requests are arriving. I will aim to come up with a transaction rate that sees CPU utilization somewhere in the 40-60% range.

This is more like how real businesses use MySQL every day, as opposed to the type of benchmarking that computer companies …

In my last blog, I introduced my investigation of the "Pool-of-Threads" scheduler in MySQL 6.0. Read on to see where I went next.

I now want to take a different approach to comparing the two schedulers. It is one thing to compare how the schedulers work "flat out" - with a transaction request rate that is limited only by the maximum throughput of the system under test. I would like to instead look at how the two schedulers compare when I drive mysqld at a consistent transaction rate, then vary only the number of connections over which the transaction requests are arriving. I will aim to come up with a transaction rate that sees CPU utilization somewhere in the 40-60% range.

This is more like how real businesses use MySQL every day, as opposed to the type of benchmarking that computer companies …

Reducing Administration Costs and Down TimeDBAs are always going to be challenged with growth, scalability and performance as long as databases get bigger and more users access them. Reducing administration and down time are always key issues in our 24 x 7 environments. The new InnoDB Plugin has some very important features that DBAs are going to want to take a serious look at. So I thought I

I’ll be giving my new “Advanced CouchDB” talk at the Dutch PHP Conference (DPC) in June. I’m looking forward to go to Amsterdam again after ApacheCon EU a few weeks back.

The talk will be about different data modelling patterns, making the most of views, building distributed applications with replication and share some hints on high-performance.

DPC’s line up looks pretty sweet. I like that it focusses on advanced topics. This is something I see missing from other conferences and I hope to see some interesting talks and I hope that mine is worthwhile and interesting enough for you :)

PS: The Early Bird registration ends April 30th

#dpcthursday

For the last couple of days I’ve been working on removing drizzleadmin (formerly mysqladmin) from Drizzle‘s source tree and I’m happy to announce that the code is now merged to the trunk.

So why did we decide to throw out a program that’s been around for a long time? Well, the tool wasn’t really useful to drizzle since mysqladmin is designed for MySQL and we wanted to factor out these old command line tools in the tree (explained later). With that in mind, I’ve been gradually removing code from drizzleadmin and by the end of it’s lifetime, only two commands remained: “shutdown” and “ping”. These commands are now moved to the drizzle command line tool.

Here’s the new standard way to shutdown drizzled:

$ drizzle --shutdown --verbose
shutting down drizzled... …

Yes, it's been a long time. Week after week, I had ideas I wanted to share, but no time at all to blog. Priorities are clear: family and work come first, and it's very difficult to keep a balance between the two.

So I left a lot behind. The major project I worked on last summer, MySQL in a virtualised environment and with multiple instances on larger boxes, was part of the material we presented at the MySQL Customer Conference back in October. The results were pretty good and we showed a good level of scalability for real life applications, well beyond the typical sysbench results you can find by googling a bit here and there. I will blog about it at some point, it's just that it takes a lot of time to reorganise all the material to publish and make it understandable.

This week the topic is slightly different. We did it again, we dug into the art of building MySQL binaries and we did it on Solaris 10 for SPARC …