The latest from the MySQL community

I've been struggling to come up with a decent prototype for the self-verifying random testcases I wrote about earlier. In the mean time, I wrote a set of triggers and a view which should yield the same information, no matter what you do to the underlying table. If they don't, there's a bug in the server.

The test table, t1 is simple. It has an int and a varchar column. There are triggers after insert/update/delete. The triggers update an evolving summary table.

The evolving summary table maintains the average+sum value of the int, and the average+sum length of the varchar field. The view selects these values from the table too.

To test it, I ran 50 threads of random insert/update/delete queries to table t1 for a few minutes. Then after the test had stopped I confirmed the results matched. (i.e. the running totals had been correctly maintained - if they match the view).

…

In search of better qa tools, i have resumed work on my gypsy. Within hours i verified a bug i thought was not possible any time soon...

crash on prepared statement + cursor + geometry + too many open files !

The code is also in launchpad (bzr branch lp:gypsy) if anybody cares.

While Andrey made good progress with the Connector/OpenOffice.org I wasted my time trying to use OpenSolaris 2008.05 as an OpenOffice.org development platform. OpenSolaris is not on the list of platforms used my the maintainers and developers of OpenOffice.org. Another open technology - JDK 1.5 - has lowered my openness towards new development platforms.

If you are an OpenOffice.org end-user, skip this blog posting: grab a binary package and be happy! That’s better for the world-wide climate because your power consumption will be lower. An Intel Core 2 Duo E6750 …

MySQL will be well represented at FrOSCon 2008. August 23-24 2008.
This will be my third presence there as a speaker. I fondly remember the pleasant experience of the 2006 and 2007 editions.

This time, MySQL is also a sponsor. In addition to having 5 speakers from the database group, we will also have a table and a BoF (MySQL 5.1 and beyond).
The list of speakers and talks makes you want to be there. (I hope)

In April this year, Kickfire announced the first high-performance appliance for MySQL. As part of the announcement, the company released data warehouse benchmark results that broke prior records in terms of price/performance and performance in a non-clustered environment. While the creation of a new appliance built exclusively for MySQL along with the benchmark records was noteworthy, perhaps the bigger story lies in what we believe to be the beginning of a paradigm shift in the database world - one marked by the advent of the first SQL chip.

To give some context to this story I have included a graph below which depicts the evolution of VLSI (Very-Large-Scale Integration) semiconductor technology and its growing impact on a broadening range of industries.

…

“MySQL Cluster 6.4 Windows tree” branch in Launchpad

(which really should have the -fail suffix… but anyway)

In what will (soon) be mirrored to launchpad, all but 17 targets (yeah, working on that… but it’s out of 130 or something) build.

Not only that, I’ve used the management client (ndb_mgm.exe) to monitor the cluster running my Bugzilla instance (which is now a rather old 6.3 build).

Getting closer to NDB on Windows.

Be afraid. Be very, very afraid.

One of the approaches we are using to look at MySQL scalability is to identify and if possible eliminate hot locks inside MySQL. For locks that cannot be eliminated, we are looking at ways to reduce the mutex hold times, or replace the critical sections with lock-free algorithms. It won't happen overnight, but it needs to be done if we are to make MySQL more scalable.

Along the way we're planning to blog about how we identified and eliminated performance bottlenecks and provide you with all the gory details about the process and technique. This will hopefully entice you all to contribute to fixing performance issues We can reach our goal of a highly scalable MySQL much faster!. If you any other ideas about how we can scale the MySQL scalability effort (pun intended), or you would like to bust some locks, please feel free to let us know.

Fixing locks is sometimes very tricky as sometimes eliminating a really hot lock can only …

One of the approaches we are using to look at MySQL scalability is to identify and if possible eliminate hot locks inside MySQL. For locks that cannot be eliminated, we are looking at ways to reduce the mutex hold times, or replace the critical sections with lock-free algorithms. It won't happen overnight, but it needs to be done if we are to make MySQL more scalable.

Along the way we're planning to blog about how we identified and eliminated performance bottlenecks and provide you with all the gory details about the process and technique. This will hopefully entice you all to contribute to fixing performance issues We can reach our goal of a highly scalable MySQL much faster!. If you any other ideas about how we can scale the MySQL scalability effort (pun intended), or you would like to bust some locks, please feel free to let us know.

Fixing locks is sometimes very tricky as sometimes eliminating a really hot lock can only …

So, we’re coming up on that time again. When I moved back to Malta in order to work for Pythian one of the things that I wanted to do was to involve myself more in the community. Currently, I’m doing this by trying to keep an active blog with tips and tricks, good standard knowledge, and just overall trying to enlighten people. I’m also doing this by organizing a MySQL User Group here in Malta.

We’re set to have our 2nd meeting this coming Thursday, the 28thof August, in Ta’ Xbiex where we have graciously been donated a board room and projector (and parking space, luckily) for use. I’m trying to get one of our members to give a session about security (not only on MySQL, but also on the OS level to secure the process), and I know there is work being done on a presentation on MySQL Cluster, which I personally find …

Changes (as compared to 2.51) include:

Features:
* Log Analyzer code has been completely refactored resulting in better performance and stability and more maintainable code.
* The progress indicator for downloads in Log Analyzer page is now a true quantitative progress bar.
* Error messages in Log Analyzer were rewritten. Every single possible error is now differentiated by a specific message providing help for the situation.

Bug fixes:
* “Group by” option in history/trends page could deliver incorrect results if MySQL and MONyog were using different timezones.
* With SFTP connection to the log file selecting “ALL” for log size to be downloaded in Log Analyzer page could have the result that the log file download would last forever.
* Analyzing log chunks containing BULK INSERT statements could in special situations cause a program …