I swear, my intention was to go for a break. A year taking pictures, sharing them over the web, writing texts, running, kayaking, just being social. Honestly, ask my family and friends!

But this was not to be, in spite of what I said when I announced my resignation just days ago. Instead, I am joining SkySQL Ab, the startup that aims to become a new centre for the MySQL universe. My role will span Marketing and Engineering, and is like the title “EVP Products” inspired by Zack Urlocker’s role at MySQL AB.

I would have preferred the company to have been called KajSQL, but have come to terms with the company having an extra phonetic “s” in the beginning. Quite a while ago, having eaten my favourite fish “ …

For more than nine years, I worked for MySQL AB and its successors, Sun Microsystems and Oracle. I handed in my resignation late June, two days before Sun’s German legal entity ceased to exist. Germany isn’t a country where you quit HP one day and join Oracle the next, so I had a long summer with plenty of so-called Garden Leave. Last Thursday was my last day, and I’m now outside MySQL AB, outside Sun Microsystems, outside Oracle.

Like all the many former colleagues who resigned before me, I did so with mixed feelings. Leaving the colleagues, finding freedom, I think you follow. The topmost feeling I have, the one I want to highlight right now, is gratitude. I’m very grateful for what MySQL AB has meant for my career, my personal development, my life experiences, my social life. Let me mention a small subset of the people that made my life at MySQL AB, and later Sun Microsystems, a truly memorable …

There are a few things to note RIGHT NOW for those of us in the world of open databases.

The MySQL User Conference has opened their call for proposals and the IOUG Collaborate11 call for proposals closes tomorrow 10/1!  Get your proposals in.

OpenSQLCamp is 10/15 -> 17 and BG is sending Patrick as I mentioned earlier this week.  If you’re in the area, I can’t urge you strongly enough to go listen, present what you’re working on, learn and get help from some amazing people doing really cool things on and in open databases.  It’s an un-conference format that has always had incredibly informative sessions.  I’ve attended the conference a few times, and came away with new ideas and solution each time.  …

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!

“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!

A few SQL queries are worth a thousands words:

mysql> SELECT VERSION();
+----------------+
| VERSION()      |
+----------------+
| 5.5.6-rc-debug |
+----------------+

mysql> SELECT @@global.storage_engine;
+-------------------------+
| @@global.storage_engine |
+-------------------------+
| InnoDB                  |
+-------------------------+

(Note: the above is without using the default storage engine option)

Scary! Excitement! MySQL!

MySQL has a well-earned reputation for being easy-to-use and delivering performance and scalability. In previous versions, MyISAM was the default storage engine. In our experience, most users never changed the default settings. With MySQL 5.5, InnoDB becomes the default storage engine. Again, we expect most users will not change the default settings. But, because of InnoDB, the default settings deliver the benefits users expect from their RDBMS — ACID Transactions, Referential Integrity, and Crash Recovery. Lets explore how using InnoDB tables improves your life as a MySQL user, DBA, or developer.

Background

In the first years of MySQL growth, early web-based applications didn’t push the limits of concurrency and availability. In 2010, hard drive and memory capacity and the performance/price ratio have all gone through the roof. Users pushing the performance boundaries of MySQL care a lot about reliability and …

At MySQL, we know our users want Performance, Scalability, Reliability, and Availability, regardless of the platform the choose to deploy. We have always had excellent benchmarks on Linux, and with MySQL 5.5, we are also working hard on improving performance on Windows.

The original patch of improving Windows performance was developed by MySQL senior developer Vladislav Vaintroub; benchmarks by QA engineer Jonathan Miller. We integrated the patch into MySQL 5.5 release.

The following two charts show the comparison of MySQL 5.5 vs. MySQL 5.1 (plugin) vs. MySQL 5.1 (builtin) using sysbench:

…

Write-heavy workloads can reach a situation where InnoDB runs out of usable space in its redo log files. When that happens, InnoDB does a lot of disk writes to create space and you can see a drop in server throughput for a few seconds. From InnoDB plugin 1.0.4 we have introduced the ‘innodb_adaptive_flushing’ method that uses a heurstic to try to flush enough pages in the background so that it is rare for the very active writing to happen. In this note I’ll try to explain how the heuristic works i.e.: what factors are taken into account when deciding how many dirty pages to flush from the buffer pool in the background. I’ll skip some details for the sake of clarity.

You may find InnoDB glossary useful to understand the terminology used in this note. adaptive_flushing is of consequence to you if your workload involves significant write activity. …