I manage several mysql servers and often on these servers for security reasons the SUPER account is not allowed external network access, so access is made to localhost. When connecting to several hosts at the same time, for example from different ssh sessions, this can be inconvenient as the \h prompt only ever shows localhost and not the hostname of the server to which I’m connected.

The following small patch against 5.1.36 which can also be found here adds a new \H option which behaves the same as \h except in this case the hostname is shown.

diff --git a/Docs/mysql.info b/Docs/mysql.info
index 7747201..dffacfd 100644
--- a/Docs/mysql.info
+++ b/Docs/mysql.info
@@ -20512,6 +20512,8 @@ sequences.
 `\D'        The full current date
 `\d'        The default database
 `\h'        The server host
+`\H'        Same as `\h' except that if the server host is …

There was small delay in our releases, part of this time we worked on features I mentioned before:
- Moving InnoDB tables between servers
- Improve InnoDB recovery time
and rest time we played with performance trying to align XtraDB performance with MySQL 5.4 ® and also port all performance fixes to 5.0 tree.

So basically we made: new split-buffer-mutex patch, which separate global buffer pool mutex into several small mutexes, and ported some Google IO fixes.
Here are results what we have so far. As usually for benchmarks I used our workhorse Dell PowerEdge R900 with 16 cores and 32GB of RAM and RAID 10 on 8 SAS disks. And again as usually our tpcc-mysql scripts with 100W …

As you see MySQL is doing great in InnoDB performance improvements, so we decided to concentrate more on additional InnoDB features, which will make difference.

Beside ideas I put before http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/ (and one of them - moving InnoDB tables between servers are currently under development), we have few mores:

- Stick some InnoDB tables / indexes in buffer pool, or set priority for InnoDB tables. That means tables with bigger priority will be have more chances to stay in buffer pool then tables with lower priority. Link to blueprint https://blueprints.launchpad.net/percona-patches/+spec/lru-priority-patch

- Separate LRU list into several …

The current release of MySQL Cluster 7.0 is based on MySQL Server 5.1.34, normally we update the MySQL Server version as soon as a new one has been released. That is an almost automated process since it's just another branch in bazaar - ie "bzr pull", resolve any conflicts and commit.

The cluster team mainly work with the files in storage/ndb/ where the source for ndbd, ndb_mgmd and all the ndb_* tools for working with MySQL Cluster is kept. We have also produced improvements to the MySQL Server itself. While most of them have been merged back up - either to 5.1 or 6.0 - some hasn't. This means that when someone touch an are that has been improved we get a few conflicts when merging down the latest MySQL Server version. Fortunately that is quite rare now when 5.1 is GA.

Some of the improvements are generic and simply improves MySQL Server's portability, while some are specific and useful only for ha_ndbcluster(the MySQL …

I do not know if you noticed it, but Google (Mark Callaghan, Justin Tolmer and their internal mysql-team) made a great contribution to MySQL. Patches global transaction IDs, binlog event checksums and crash-safe replication state are separated and published on Launchpad (https://code.launchpad.net/~jtolmer/mysql-server/global-trx-ids).

For me it was a big wall in using these patches that they were part of one big patch, which you can apply only to 5.0.37, and now there is no barrier to include patches into our builds or MySQL releases.

If you do not know what is Global Transactional ID is - it is worth to look …

Last year, Erik Ljungstrom (sensei in the #ourdelta IRC channel on Freenode) created patch for a bug Arjen identified with the handling of (among others) the open-files-limit option; the patch was first included in the OurDelta build of MySQL 5.0.67.

Now, Sun engineer Guilhem Bichot has committed the (modified) patch into the 6.0-maria tree, so it should appear in 6.0 and potentially 5.4. That’s good.

See http://bugs.mysql.com/40368 for details and history.

Percona presented two talks at PHP Quebec last week - one on A Tour of MySQL High Availability, and another on Performance Tuning MySQL. There was a great reaction to showcasing some of the quick-wins that can be found by using the Percona patches. Unfortunately, the one thing that I forgot to mention in the slides is that the patches are Open Source and free to use.

Entry posted by morgan | 4 comments

Add to: | …

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 …

One of InnoDB's features is that memory allocated for internal tables definitions is not limited and may grow indefinitely. You may not notice it if you have an usual application with say 100-1000 tables. But for hosting providers and for user oriented applications ( each user has dedicated database / table) it is disaster. For 100.000+ tables InnoDB is consuming gigabytes of memory, keeping definition in memory all time after table was once opened. Only way to cleanup memory is to drop table or restart mysqld - I can't say this is good solution, so we made patch which allows to restrict memory dedicated for data dictionary.

Patch was made by request of our customer Vertical Response and released under GPL, so you can download it there …

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 …