ClouSE version 1.0b.1.2 and WordPress on S3 / Yapixx refresh is released

OblakSoft is pleased to announce the release of ClouSE version 1.0b.1.2 and WordPress on S3 / Yapixx refresh.

This release addresses performances and usability issues reported by our early adopters.  Thank you all for your feedback.

• Support for MySQL 5.5.25

Now ClouSE supports MySQL thru 5.5.25.  To keep the distribution small, we don’t build binaries for MySQL prior to 5.5.14 anymore.  If you need one, please contact us.

• Weblob content type improvement

Now the content type for Weblobs is set based on their name.  Previously, the content type for all Weblobs was set to application/octet-stream, which could lead to undesirable Web Browser behavior when the …

You can get Flexviews at the project page:
Flexviews project page

This release includes the following new features:

Table change logs now include a new column: fv$gsn. This column carries the "global sequence number" which uniquely identifies the order in which to make changes in the database. This was required to fix some problems identified in updating views that did not contain aggregate functions.

Updated refresh algorithm takes GSN into account and applies changes in GSN order.

All reported bugs have been fixed.

FlexCDC now supports all MySQL data types properly.

You can get Flexviews at the project page:
Flexviews project page

This release includes the following new features:

Table change logs now include a new column: fv$gsn. This column carries the "global sequence number" which uniquely identifies the order in which to make changes in the database. This was required to fix some problems identified in updating views that did not contain aggregate functions.

Updated refresh algorithm takes GSN into account and applies changes in GSN order.

All reported bugs have been fixed.

FlexCDC now supports all MySQL data types properly.

Sheeri K. Cabral at the Mozilla Foundation wrote about an issue with the June 30th 2012 leap second affecting at least MySQL, Java and Minecraft servers. It now appears that the underlying cause is a Linux kernel bug, as noted by John Stultz (IBM) on the Linux Kernel mailing list, and the team Sheeri is part of deserves due credit for doing awesome pattern recognition and being the first to bring it to public attention, enabling people to quickly correlate their own experience with that of others and finding a practical solution as well as helping figure out the cause.

Sheeri’s original post MySQL and the Leap Second, High CPU and the Fix describes how MySQL servers would suddenly exhibit high CPU usage during a period of low load. …

When executing an ALTER TABLE, InnoDB (and XtraDB) will create two InnoDB transactions:

1. One transaction is created when the table being ALTERed is locked by the server.
   This will show up as something like “TABLE LOCK table `schema`.`table_name` trx id XXXX lock mode S” in SHOW ENGINE INNODB STATUS.
2. Another is created when adding or dropping an index to perform operations on the InnoDB data dictionary.

A little known fact is that the InnoDB data dictionary is somewhat transactional (the big thing it’s missing is any form of MVCC. It’s not ACID). The largest part of ALTER TABLE not being completely crash safe in MySQL is the MySQL server manipulating FRM files.

The only MySQL storage engine I’m aware of having fully crash safe DDL is MySQL Cluster (NDB).

Proving that MEMORY is/isn’t crash safe around DDL is an exercise left to the reader

Thanks go to …

The slow query log is one of the most misused features of MySQL.  I say this because I often talk to people who are using it, but they're not getting everything they could from it.  It's an awesomely powerful source of information! When used correctly it can make performance optimization much simpler, and enable you to really understand what your mysql server spends its time doing.

Slow is faster than you think 


The most misunderstood part of the query log is the "slow" part.  People often set the long query time to some high value (default 10 seconds) and wait for a few outlier queries to trickle in.  At most they will reduce the threshold to 1 second to be really aggressive.  Here's the a secret:  those queries aren't  really the ones that matter.

A query that runs for 60 seconds and hits your server twice a day, may look ripe …

I promissed to release a complenent to my jsonload project, a json unload / export tool, in a blog post last week, but since then, not much has happened. Well, what happened was two things:

• Amazon distracted me with all sorts of issues, downs, connectioon problems and power outages.
• I got WAY more ambitious than I first planned to be.

You know what it is like, you really want to do the right thing, and when you start doing that you figure what the right thing really is, and it's much more featureful and performant that you had originally envisioned. But stuff is in the works, and it's pretty cool. In the process, I have introdused a few features that are such that I want to link them up to how jsonload works, so that these guys work nicely together. Also, I'm changing the …

ETA: For those wanting to know the root cause, see the comments on the original post.

So, MySQL seemed to be faring just fine during and after the leap second. There were no big problems or catastrophic failures. However, we noticed that MySQL (and Java) servers* had a huge spike in CPU – which was odd, because nothing out of the ordinary was running. We were able to fix the problem quite easily. Here’s the graph, and the fix:

Note that the CPU spikes starting at 17:00 Pacific, which is midnight UTC. We fixed it around 19:35 Pacific.

The fix is quite simple – simply set the date. Alternatively, you can restart the machine, which also works. Restarting MySQL (or Java, or whatever) does …

I wrote one week ago about how to find duplicate indexes. This time we’ll learn how to find unused indexes to continue improving our schema and the overall performance. There are different possibilites and we’ll explore the two most common here. User Statistics from Percona Server and pt-index-usage.

User Statistics

User Statistics is an improvement on Percona Server that adds some tables to Information Schema with useful information to understand the server activity and identify the source of the load. …

This week we present an interview with Rohit Nadhani of WebYog about MONyog, a MySQL monitoring and advisory tool.

Conferences
OSCon will be held Monday Jul 16th through Friday Jul 20th and has a data track. We did a podcast about OSCon, including a discount code!

MySQL Connect will be held in San Francisco on Saturday September 29th and Sunday September 30th. This is a technical conference about MySQL, bringing together MySQL engineers at Oracle and the MySQL Community, and will include sessions about the latest MySQL …