Users of the ARCHIVE or NDB storage engines in MySQL may be aware of a MySQL feature known as “table discovery”. For ARCHIVE, you can copy the archive data file around between servers and it magically works (you don’t need to copy the FRM). For MySQL Cluster (NDB) it works so that when you CREATE TABLE on another MySQL server,  other MySQL servers can get the FRM for these tables from the cluster.

With my work to replace the FRM with a protobuf structure in Drizzle and clean up parts of the API around it, this feature didn’t really survive in any working state.

Instead, I’m now doing things closer to the right way: pluggable metadata stores. The idea being that the whole “table proto on disk” (in MySQL it’s the FRM, but in Drizzle we’re now using a protobuf structure) code is pluggable and could be replaced by an implementation specific to an engine (e.g. the innodb or ndb data dictionaries) or a different …

One of the cool things about talking about MySQL performance with ZFS is that there is not much tuning to be done Tuning with ZFS is considered evil, but a necessity at times. In this blog I will describe some of the tunings that you can apply to get better performance with ZFS as well as point out performance bugs which when fixed will nullify the need for some of these tunings.

For the impatient, here is the summary. See below for the reasoning behind these recommendations and some gotchas.

1. Match ZFS recordsize with Innodb page size (16KB for Innodb Datafiles, and 128KB for Innodb log files).
2. If you have a write heavy workload, use a Seperate ZFS Intent Log.
3. If your database working set size does not fit in memory, …

One of the cool things about talking about MySQL performance with ZFS is that there is not much tuning to be done Tuning with ZFS is considered evil, but a necessity at times. In this blog I will describe some of the tunings that you can apply to get better performance with ZFS as well as point out performance bugs which when fixed will nullify the need for some of these tunings.

For the impatient, here is the summary. See below for the reasoning behind these recommendations and some gotchas.

1. Match ZFS recordsize with Innodb page size (16KB for Innodb Datafiles, and 128KB for Innodb log files).
2. If you have a write heavy workload, use a Seperate ZFS Intent Log.
3. If your database working set size does not fit in memory, …

Solaris Cluster comes bundled with rich support for numerous software applications.

Follow the link to see a list of all the Solaris Cluster Agents available in the latest release of  Solaris Cluster  - SC 3.2 01/09.
For most of these applications the latest versions are supported.  In this blog I specifically want to highlight the latest support
for the SAP NetWeaver stack and highlight some key features provided by Solaris Cluster to make SAP highly available on
Solaris.

Solaris Cluster 3.2 HA SAP Web Application Server agents now support SAP 7.1 on S10 SPARC and X64. You will need
patch# 126062-06 or later for S10 SPARC or patch# 126063-07 or later for S10 X64. This patch is required for the following
Resource Types (RTs) - SUNW.sapenq, SUNW.saprepl, SUNW.sapscs, …

Solaris Cluster comes bundled with rich support for numerous software applications.

Follow the link to see a list of all the Solaris Cluster Agents available in the latest release of  Solaris Cluster  - SC 3.2 01/09.
For most of these applications the latest versions are supported.  In this blog I specifically want to highlight the latest support
for the SAP NetWeaver stack and highlight some key features provided by Solaris Cluster to make SAP highly available on
Solaris.

Solaris Cluster 3.2 HA SAP Web Application Server agents now support SAP 7.1 on S10 SPARC and X64. You will need
patch# 126062-06 or later for S10 SPARC or patch# 126063-07 or later for S10 X64. This patch is required for the following
Resource Types (RTs) - SUNW.sapenq, SUNW.saprepl, SUNW.sapscs, …

To all people, interested to see a presentation/live demo of MySQL Workbench 5.1 and 5.2 - you’re welcome to join the MySQL Workbench Web-Seminar, held tomorrow, May 27th at 15:00 CET. Important side-note: it’s held in German!
For about 45 minutes I will walk you through various parts of the application and show many features live from my screen:

• Overview of the interface
• How to create tables and other objects
• Layouting objects on the canvas
• Show how to get your model to the database (and back)
• Take a quick look into the scripting interface
• See the database querying of upcoming 5.2 in action

Every participant will be able to ask questions via chat during the presentation and subsequently there will be a Q&A for about 15 mins. The session is free to attend, all you need to do is head over to the Registration-page and enter your …

So I spent the weekend looking at places where we may have missed something in the code for waffle. You can actually see some of the stuff I tried in the bug on launchpad about this, but the weird thing is the very last thing I tried. As I took a step back and looked at the problem ( secondary index corruption ) and our assumption that we “missed” something, I decided to find the place where pages are written to disk and to push to memcached from here as well as from the LRU. With the double write buffer enabled that place should be buf_flush_buffered_writes. By pushing to memcached here we should eliminate the page that falls through the cracks of the LRU. Basically this should help ensure memcached has an exact copy of the data that exists on disk. The result? It failed with the same secondary index failure. This means:

a.) maybe we have a problem in the …

Last week I blogged about a patch for Sphinx 0.9.8.1 that allowed Drizzle to be used as a data source (this works much like the MySQL and PostgreSQL options). This past weekend I made a new patch that would work with the latest version, 0.9.9-rc2. It can be found here:

sphinx-0.9.9-rc2-drizzle.patch

The instructions are pretty much the same:

Download sphinx-0.9.9-rc2.tar.gz and sphinx-0.9.9-rc2-drizzle.patch
tar xzf sphinx-0.9.9-rc2.tar.gz
cd sphinx-0.9.9-rc2
patch -p1 < ../sphinx-0.9.9-rc2-drizzle.patch
./buildconf.sh
./configure --with-drizzle
make
make install

See my previous blog post for configuration changes to make Sphinx index from Drizzle. …

The beginning of this story is coming from the first weeks of the last year - seeking for the most optimal MySQL config parameters I've discovered a strange thing:

• my dirty pages percentage setting 15 was completely ignored by InnoDB during my tests!...
• once the test workload was finished it still took 30 minutes yet to flush dirty pages!...

I've told about a lot of people on that time, but everybody were just surprised and did not really believe such case is possible... Agree, it's hard to believe ;-)

So, to refresh the story, let me first to show you the following picture:

As you may see here the dirty pages percentage is higher than 15% for sure :-) As well you may see the 30 minutes of dirty pages flushing once the workload is finished (too much according to me on the idle server! - and probably recovery process will take even more time if my server will crash?...)

…

Our lastest Alpha2 release of MySQL Workbench 5.2 made it pretty clear that one of our main goals for WB 5.2 is to replace the old MySQL Query Browser (QB) tool.

Even this Alpha2 release already covers most of the essential QB functionality, while at the same time removes some of the biggest limitations that the old QB tool suffers from. Here is a short list of the most important features.

MySQL Workbench 5.2 Features replacing QB

• Database Connection management
• SQL statement editor with syntax highlighting
• Edit multiple statements at the same time (scripts)
• Editable result sets for table data
• Database Schema browsing

New MySQL Workbench 5.2 Features

• Intuitive Database Connection listing on Home page and direct access to SQL Editor
• Ability to open SQL Editors for many different connections at the same time
…