The latest from the MySQL community

It’s like removing the brakes from your car. yes, it will go faster (slightly less weight) but, dude, you just removed the brakes.

Just got home finally from PHP Appalachia.  I enjoyed meeting all the great people.

I presented about what I learned and how we deal with importing large amounts of CSV data into MySQL.  I threw my idea onto the wiki at the last minute, made the slides while everyone ate breakfast and I had planned on researching it all (been a few years since I wrote it), but we had no reliable internet.  Some claims I made and their corrections.

1. 
   
2. I said our largest file is about 1.8 million lines.  WRONG.  Actually it is about 4.6 million.  I was correct however that it does finish importing and indexing in about 5 minutes.
3. 
   
4. I claimed I LOAD DATA INFILE to MyISAM first and then "insert into ... select from" into an InnoDB table for speed reasons.  WRONG.  In fact, I do that because I need to merge fields from the file sometimes …

The setup on Launchpad is better organised (Launchpad rocks!), and we already have the first feedback in the form of bugreports - mainly on the packaging and repo information. That’s excellent! Thanks Vladimir Cherednichenko, Steve Walsh, and Peter Lieverdink! Peter actually deserves a special mention as he has put in a lot of work on the debian packaging.

Also, because sometimes instant banter is useful, there’s now a #ourdelta channel on Freenode. Naturally, real discussion should just happen on the ourdelta-developers team and list. It’s really easy to join.

Antony Curtis did just that (join) and already put one of his many patches in: this one fixes issues which occur while a thread …

Updated the release, sure it’s only been a matter of hours but I added the standard cnf files for 2,4,8 and 16GB server installations. Also added the rhcluster-wrapper script that can be used to run just about anything on the active database node when using mysql in an active/passive setup.

Download here:  http://code.google.com/p/monolith-toolkit/

We are pleased to announce the release 1.0.14 of HoneyMonitor, our GUI for MySQL™ administration and monitoring.

With this release, available for immediate download, all HoneyMonitor’s Editions:

• Lite Free
• Standard
• Enterprise
• Network
• Pro
• Audit Pro

reach the beta stage. The …

I just read this post on Matt Casters' blog. Here, Matt describes why Element 61's Jan Claes is dead wrong in the way he assesses the maturity of open source ETL tools.

Well, I've just read Jan Claes' article in the "research and insights" area of the Element61 website, and frankly, it is pretty easy to see how unsubstantiated it is. Some may be tempted to classify the article as …

Today I decided to package all of my various scripts together into a useful toolkit. Some are perl, some are shell script. These scripts are, in general, one off scripts that I wrote in order to get things done that weren’t available at the time. Now they’re nicely organized and will receive updates at the google code repo.

So far the toolkit includes the following scripts:

• mt-backup-parallel -> the parallel backup script I wrote about in my last post
• mt-check-replication -> script to report on replication status for slave servers
• mt-check-rhcluster-filesystems -> reports on redhat cluster filesystems (for mysql active/passive clustering)
• mt-connections-log -> logs connections to mysql to disk, reports on threshold overages
• mt-flush-tables-sequence -> runs through schema.tables to …

Hi,
How that I have the latest release of PBMS out the door I thought I would post some of the ideas I have had for possible ways in which the BLOB streaming engine could be expanded upon. 
What if the BLOB streaming engine supported the idea of having it's own BLOB storage engines that could be plugged into it the same way that storage engines are plugged into MySQL. The API for these BLOB storage engines would be dead simple, all they would need to support would be a 'get', 'put', and 'delete' method. The BLOB streaming engine would handle the reference counting and still provide the simple HTTP server for direct access to the BLOBs but the BLOB engines would handle how and where the actual BLOB data would be stored.
Currently the blob data is stored locally in blob repository files, which is very efficient but may not be ideal for some applications. Here are a few ideas I have had for possible BLOB storage engines:

Background Knowledge

I’m trying to determine the difference in minutes between two timestamps. I’m using Pear::Date to do this. The issue comes into play when I noticed that the wrong timezone was being used by Pear::Date, UTC. If I do not use Pear::Date the timezone is set correctly.

I have tried using date_default_timezone_set() and it does set the timezone back, however I feel this shouldn’t be necessary as the default timezone should be used. I have been using date_default_timezone_get() to determine what timezone is being used.

It’s my understanding that Pear::Date uses UTC when it is unable to determine the default timezone. As far as I know I have the default timezone set correctly and with a …

The errmsg plugin interface is almost done.

The next plugin interface will be fairly more fraught, but useful. Making the configuration interface as a plugin.

This means that instead of keeping the configuration in the /etc/my.cnf and/or /etc/drizzle.cnf, the configuration variables could be kept in the Gnome registry, or in LDAP, or via lookups in some online configuration database server.

This would make managing and configuring huge arrays of Drizzle servers much much easier.