I wrote couple of weeks ago on dangers of bad cache design. Today I’ve been troubleshooting the production down case which had fair amount of issues related to how cache was used.

The deal was as following. The update to the codebase was performed and it caused performance issues, so it was rolled back but yet the problem remained. This is a very common case when you would see customer telling you everything is the same as it was yesterday… but it does not work today.

When I hear these words I like to tell people computers are state machines and they work in predictable way. If it does not work same today as it worked yesterday something was changed… it is just you may not recognize WHAT was changed. It may be something subtle as change in query plan or increase in search engine bot activity. It may be RAID writeback cache disabled …

The intention from the start was to make upgrades to newer MySQL versions trivial. We have done a lot of work to keep data formats compatible (both in the .frm files and in the storage engines); when you install a new version of MySQL things should “just work”.

For a long time this was true, until MySQL 5.0 where we had to do some data incompatible changes, like in the way some characters were sorted and how end-of-line blanks were stored in indexes.

To make the upgrade process easy, we created the ‘mysql_upgrade’ program which should detect possible incompatible tables and automatically convert data as needed.

The full upgrade process (for your data) should always be as simple as:

1. Install your new MariaDB / MySQL version.
2. Start the mysqld server.
3. Run mysql_upgrade.

Unfortunately, over time something has gone wrong. We found this out when a user recently …

There’s a new version of the dbbenchmark tool available. Now we’re creating the MySQL connection pool thread count based on automatic reporting of core quantity. There is still the same method to set the thread count manually if you are interested in finding your system’s thread limits. Download the MySQL benchmarking script now and add your server performance to the community database of results!

I attended the IT 360 conference in London today and I had a change to talk to the people who sell Violin Memory. We were already interested, but we had some technical questions for them. After chatting them for a bit it (looks likely that) we're getting one!
Mmmmmmmmmmm memory.....

We will be the first or one of the first people in the UK to own one, so that pretty exciting.

On a side note, the Violin sales paper were super nice. They were like: "Just take it for 30 days, give it a try. We'll help you with whatever you need for installing it and any other issues you have".
Very down to earth, …

If you’ve ever needed to know how the data and index percentages per table engine were laid out on your MySQL server, but didn’t have the time to write out a query… here it is!

select
(select (sum(DATA_LENGTH)+sum(INDEX_LENGTH))/(POW(1024,3)) as total_size from tables) as total_size_gb,
(select sum(INDEX_LENGTH)/(POW(1024,3)) as index_size from tables) as total_index_gb,
(select sum(DATA_LENGTH)/(POW(1024,3)) as data_size from tables) as total_data_gb, 

(select ((sum(INDEX_LENGTH) / ( sum(DATA_LENGTH) + sum(INDEX_LENGTH)))*100) as perc_index from tables) as perc_index,
(select ((sum(DATA_LENGTH) / ( sum(DATA_LENGTH) + sum(INDEX_LENGTH)))*100) as perc_data from tables) as perc_data,

(select ((sum(INDEX_LENGTH) / ( sum(DATA_LENGTH) + sum(INDEX_LENGTH)))*100) as perc_index from tables where ENGINE='innodb') as innodb_perc_index,
(select ((sum(DATA_LENGTH) / ( sum(DATA_LENGTH) + sum(INDEX_LENGTH)))*100) as perc_data from tables where ENGINE='innodb') as …

Openworld 2010, despite the supposedly lagging economy, had record attendance again this year.  No doubt this was the result of Oracle acquiring something like fourteen companies since last year, including Sun in 2009.  The crowds were thick, divided about evenly between geeks in badly-fitting vendor t-shirts and slick sales-side hustlers with dress pants and shiny shoes.  I landed somewhere in the middle of the two (badly-fitting dress shirt, comfortable jeans and loafers), proudly sporting a long dangling codpiece of ribbons from my attendee badge:

My OOW2010 Codpiece

Oracle made a number of important announcements this year at OpenWorld, including a the Exalogic machine, and support for Amazon EC2, which I blogged about …

SQL Antipatterns, by Bill Karwin
I remember that when I finished reading The Lord Of The Rings, I felt a pang of disappointment. "What? Already finished? What am I going to read now? What can give me the same pleasure and sense of accomplishment that these wonderful pages have given me?"
That's how I felt when I came to the last page of SQL Antipatterns. And, no, Bill Karwin doesn't tell imaginary tales from a fictitious world. This book is full of very real and very practical advice, but all the material is presented with such grace and verve that I could not put it down until the very end. I read it cover to cover in just a few hours, and I savored every page.

What is this Antipatterns, anyway? The title may deceive a casual bookshop browser into believing that it's about some philosophical database theory. Digging further, you realize …

“and go on till you come to the end of Oracle OpenWorld: then soak your feet and start sorting through the piles of material in your conference bag.”

Congratulations to everyone who made it through their first OOW event, as well as the returning champions!

If you’ve still got any strength in your legs, or if you did not have a chance to go, come join us for MySQL in the Windy City on September 28!

I’ve just pushed the last batch of changes into 5.2 tree. The most important change was renaming Maria engine to Aria (with old maria* compatibility variables). Other — smaller — changes included adding all plugins to the windows .zip distribution (sphinx and oqgraph too), building mysqld.exe with federatedx, not old federated engine, refactoring of mysql-test-run suite to support pluggable per-suite extensions, print the plugin configuration in the ./configure script, and other even smaller changes. Together with all bug fixes that 5.2 has accumulated over time it made the tree ready for the next release – 5.2.2!

Yesterday, I reached a happy milestone in HailDB development. All compiler warnings left in the api/ directory (the public interface to the database engine) are now either probable/possible bugs (that we need to look at closely) or are warnings due to unfinished code (that we should finish).

There’s still a bunch of compiler warnings that we’ve inherited (HailDB compiles with lots of warnings enabled) that we have to get through, but a lot will wait until after we update the core to be based on InnoDB 1.1.