The Audit API has more uses that you may think! When a statement is executed in the server, the notification function in this API will be called, and we can use that do some interesting things!

Like: Ever wanted to know what the most executed query in your running system is? I mean the information is in there somewhere, right, it's just q question of how to get at it? And frankly, I don't think the queries:
SELECT * FROM user_data WHERE user_id = 57;
and
SELECT * FROM user_data WHERE user_id = 113;
Should count as different queries? I mean, hey, the issue is that the application may be issuing the same query too many times, with different arguments mostly, but still the query:
SELECT * FROM user_data WHERE user_id = <somevalue>

Is executed too often? And if so, how can I figure it out? Well, using MySQL 5.5 with a combination of the Audit Plugin API and the INFORMATION_SCHEMA API, …

One year after the last stable release, v5.0 is now ready to use.

Changes between v5.0 beta and v5.0 stable:
* New feature: SSL options in session manager
* New feature: Startup script file in session manager
* New feature: Quick filter with "More values" auto fetches distinct cell values from table
* New feature: SQL export to clipboard
* New feature: Rewritten search and replace dialog, supporting regular expressions now
* Enhancement: Custom row height in result grids
* Enhancement: Implementing stuff for portable into main exe, so there is no need for a launcher any longer
* Many bugs (approximately 50) fixed

Changes between v4.0 and v5.0 beta:
* Completely rewritten, homebrown database communication layer, supporting Unicode from the very beginning
* Rewritten …

I ran several CPU-bound tests using sysbench and MySQL 5.1.45 with the Facebook patch for MySQL 5.1, PBXT 1.1, InnoDB plugin 1.0.6 and MyISAM. The server reports 16 x86 CPU cores. The Facebook patch has many useful changes and we are still trying to figure out whether they improve performance for sysbench.

All tests were run with a warm buffer cache for 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 threads. The data was cached by each storage engine with one exception. MyISAM does not cache data blocks.

The results are interesting. PBXT does great and is similar to InnoDB except on the oltp read-only test that uses HANDLER. In that case it is much faster at high concurrency. I am not ready to switch yet, but this is another positive step in my evaluation. I need to run a few …

At work we have been looking for tools to monitor MySQL and at the same time provide as much diagnosis information as possible upfront when an alarm is triggered. After looking around at different options, I decided to test MONyog from Webyog, the makers of the better known SQLyog. Before we go on, the customary disclaimer: This review reflects my own opinion and in no way represents any decision that my current employer may or may not make in regards of this product.
First ImpressionYou know what they say about the first impression, and in this where MONyog started with the right foot. Since it is an agent-less system, it only requires to install the RPM or untar the tarball in the server where you're going to run the monitor and launch the daemon to get started. How much faster or simpler can it be? But in order to start monitoring a server you need to do some …

Go read over on Baldy’s (my father and SmugMug’s co-founder) blog for the details.  Leave a comment there and who knows?  You might have an iPad headed your way.  :)

I'm pleased to announce the release of Spider storage engine version 2.17(beta).
Spider is a Storage Engine for database sharding.
http://spiderformysql.com/

The main changes in this version are following.
- Add table parameter "semi_split_read_limit".
- Add server parameter "spider_semi_split_read_limit".
  This parameters are for searching performance improvement.

Please see "99_change_logs.txt" in the download documents for checking other changes.

Enjoy!

I’ve decided to jump on the bandwagon and spill my thoughts on “NoSQL” since it’s been such a hot topic lately ([1], [2], [3], [4]). Since I work on the Drizzle project some folks would probably think I take the SQL side of the “debate,” but actually I’m pretty objective about the topic and find value in projects on both sides. Let me explain.

Last November at OpenSQL Camp I assembled a panel to debate “SQL vs NoSQL.” We had …

For the past couple of weeks I have been trouble shooting some Cassandra issues where data would not make it to Cassandra.




The image above graphs all the exceptions that are produced from Cassandra. The two big lines are

Transport Exceptions (te) - meaning that Cassandra could not answer the request think of this as MAX Connection errors in mySQL.


Unavailable Exceptions (ue) - meaning that Cassandra could answer the request but the "storage engine" cannot do anything with it because its busy doing something like communicating with other nodes or maintenance like a node cleanup.


So how did I get the graph to drop to 0? After looking at the error logs, I saw that Cassandra was getting flooded with SYN Requests and the kernel thought that it was a SYN Flood and did this …

I will write some more on this interface eventually, following up my previous MySQL Audit API post, and will show some ideas and hopefully push some interesting code (I have ideas!). But note that the API so far isn't well documented (only source so far), but there is work underway to fix this by the friendly MySQL docs team.
Already I have realized that Audit events are different than I thought. The source of the event is currentlyt either from inside the parser code or from the general log code. The events I got looked like general log events, so I just imaginged this was the source of what I saw, and I never relaized that there was another possible source, the parser. Actually, when the general log is not on, the parser events is all you get, but as I have shown, this is usually good enough. For the log events to be received, you still …

In XtraDB we have the table INNODB_BUFFER_POOL_PAGES_INDEX which shows which pages belong to which indexes in which tables. Using thing information and standard TABLES table we can see how well different tables fit in buffer pool.

PLAIN TEXT SQL:

1. mysql> SELECT d.*,round(100*cnt*16384/(data_length+index_length),2) fit FROM (SELECT schema_name,table_name,count(*) cnt,sum(dirty),sum(hashed)  FROM INNODB_BUFFER_POOL_PAGES_INDEX GROUP BY schema_name,table_name ORDER BY cnt DESC LIMIT 20) d JOIN TABLES ON (TABLES.table_schema=d.schema_name AND TABLES.table_name=d.table_name);
2. +-------------+---------------------+---------+------------+-------------+--------+
3. | schema_name | table_name          | cnt     | sum(dirty) | sum(hashed) | fit    |
4. …