With a lot of talks around 5.4 I decided to check how it works in our benchmarks. For first shoot I took tpcc-like IO-bound benchmark (100W, ~10GB of data, 3GB buffer_pool) and tested it on our Dell PowerEdge R900 box (16 cores, 32GB of RAM, RAID 10 on 8 SAS 2.5" 15K RPM disks). For comparison I took XtraDB-release5 and 5.0.77-highperf percona release.

For raw results you can check my Google Spreadsheet (it is also being update with my next CPU benchmarks, and benchmark on SSD & FusionIO), also I post graph there:

Results are in TPM (transactions per minute, more is better).

So I can confirm that MySQL team did great job with 5.4 and it shows the best results.
Some more results you can find on Dimitri's blog, one of Sun Performance Engineers.

…

MySQL 5.4 comes with Innodb engine which seems to have much better performance than MySQL 5.0 - this is due to locking and IO patches from Google integrated in this release (which are similar to appropriate Percona patches) as well as some unique fixes such as different innodb_thread_concurrency handling and other optimization.

Should we take Innodb from MySQL 5.4 and merry it with unique Percona patches (adaptive checkpoints, additional undo slots, profiling, etc) and integrate it with MySQL 5.0 ? How useful would you find it ?

Currently we see a lot of customers not quite ready to update to MySQL 5.1 in particular as there is little in this version which benefits their workload, which consists of the queries running just fine on 5.0.
5.4 especially introduces optimizer changes which besides positive impact for some queries may …

Today we glad to announce release 1.0.3-5 of our XtraDB storage engine.

Here is a list of enhancements in this release:

• move to MySQL 5.1.34
• removed rw_lock patch, so we now use Google's rw_locks
• fix crash after upgrade 5.1.31 -> 5.1.33
• fix mysql-test

Percona XtraDB 1.0.3-5 available in source and several binary packages.

XtraDB is compatible with existing InnoDB tables (unless you used innodb_extra_undoslots) and we are going to keep compatibility in further releases. We are open for features requests for new engine and …

Today we glad to announce release 1.0.3-4 of our XtraDB storage engine.

Here is a list of enhancements in this release:

• Move to MySQL 5.1.33
• Move to InnoDB plugin 1.0.3
• more reliable replication, innodb_overwrite_relay_log_info patch now included in the release
• fix assertions for …

Many InnoDB scalability problems seem fixed in InnoDB-plugin-1.0.3 and I expect InnoDB-plugin will run fine on 16-24 cores boxes for many workloads. And now it is time to look on systems with 32GB+ of RAM which are not rare nowadays. Working with real customer systems I have wish-list of features I would like to see soon:

• Fast recovery. Both recovery after crash and recovery from backup can take unacceptable long time, especially if you crashed with full 32GB buffer_pool. There is reported bug http://bugs.mysql.com/bug.php?id=29847, with ETA MySQL-6.0
• Preload table / index into buffer_pool. You can use custom queries by primary / secondary key to "warm up" part of table, but this solution is ugly and may be slow due to random logical I/O. Implementing preload of full .ibd file with sequential read would be much better solution. This is actually more …

Running MySQL slave is quite common and regular task which we do every day, taking backups from slave is often recommended solution. However the current state of MySQL replication makes restoring slave a bit tricky (if possible at all). The main problem is that InnoDB transaction state and replication state are not synchronized. If we speak about backup and you can execute SHOW SLAVE STATUS command you can get reliable information about current state, but some solutions does not allow that. Look for example Sun Storage 7410, which provides storage via NFS and where you can make ZFS snapshots without any info what kind of data you are storing there. What makes situation worse is that files with replication state (relay-log.info, master.info) are not synchronized on disk after each update, and even wrose - in case with NFS they are stored on client side OS/NFS cache for long time. As solution we can do patch to execute fsync() for these files after …

Today we announce release 1.0.2-3 of our XtraDB storage engine.

Here is a list of enhancements:

• Move to MySQL 5.1.31
• Scalability fix — ability to use several rollback segments

Increasing the number of rseg may be helpful for CPU scale of write-intentional workloads. See benchmark results.

For long time as main backup solution for MySQL on Linux we have been using LVM snapshots. Performance concerns from performance critical envinronment caused us to do LVM performance research which showed horrible results forcing us to look at more performing alternatives.

Innodb Hot Backup is a good working solution but it is not Open Source and so we can't ensure it will support all XtraDB features - extra undo slots, rollback segments etc.

After considering all alternatives we decided to develop Percona Xtrabackup tool, which will use same backup approach as InnoDB Hot Backup, that is taking online copy of InnoDB table files and transactional logs. This is going to be fully OpenSource, GPL licensed backup solution for MySQL (MyISAM and InnoDB for …

This is one of the largest issues so far.  In addition, it has some of the best content we have ever had. The articles are all in-depth with some exciting new information:

• Introduction to XtraDB: an overview of the new XtraDB storage engine along with benchmarks and information about planned future improvements
• Changes in the MySQL DBA and Developer Exams for Version 5.1: what’s coming in the new exams covering MySQL Server 5.1
• Covering Indexes in MySQL: how to create indexes that optimize query execution
• PBXT’s Coder’s Guide: going in-depth on how you can work with the code for the new PBXT storage engine
• Coding Corner: Peter’s regular column continues his look at transaction time validity

It is available for download, along with all …

The problem with broken group commit was discusses many times, bug report was reported 3.5 years ago and still not fixed in MySQL 5.0/5.1 (and most likely will not be in MySQL 5.1). Although the rough truth is this bug is very hard (if possible) to fix properly. In short words if you enable replication (log-bin) on server without BBU (battery backup unit) your InnoDB write performance in concurrent load drops down significantly.
We wrote also about it before, see "Group commit and real fsync" and "Group commit and XA".

The problem is the InnoDB tries to keep the same order of transactions in binary logs and in transaction logs and acquires mutex to …