Category Archives: Technology

Panoramas of the World

When I first got my Canon PowerShot S230, it came with software for stitching panoramas together, made by Canon. The software worked OK for perfectly-shot panoramas, but it didn’t deal well with differing exposure levels, imperfect alignment, etc., and dealt very poorly with bad angles. Nonetheless, I was immediately hooked on making panoramas.

A year ago or so, I found some software called autostitch, which absolutely rules for stitching panoramas together. The downside is, it only runs on Windows. I have a Mac. On Sunday, I went to the autostitch site, and noticed some new links; they’ve licensed their technology to Kekus Digital, who have made Calico … autostitch for Mac OS X! I downloaded it, tried it out, and bought it immediately.

Here are some of the panoramas I’ve stitched together with it:

Note that if you click on the image on the gallery pages, you will get the full size version, some of which are up to 30MB. Enjoy!

rum rum rum DUH

About halfway through my trip camping near Nevada, I noticed my “Check Engine”1 light came on. I also noticed that at idle, the engine was missing occasionally, just idling poorly. I had been buying gas at strange places, so I went through another tank of gas to be sure it wasn’t the gas. It still continued.

I figured it was the spark plugs (they haven’t been changed ever, which is ~77k miles), so when I got home yesterday, I went by Kragen and got a full set of new plugs and the tools to change them. Damn you, crackhead, for stealing my sockets.

I got home and went to work changing them out. The Jeep has an inline 6-cylinder 4.0L engine, so the cylinders are laid out front to back in a straight line. That means that they pass under all kinds of obstacles, and that the back cylinder is really far from the front of the car, just against the firewall2. In addition, they don’t just have the typical spark plug wires connected to each, they have a single long bar that connects to all of them, held on by more bolts that require wrangling to get out. An hour of struggling with a long and short socket wrench, with and without an extension, up to my elbows in engine parts, I finally got them all changed, and got the bar re-attached.

I cleaned everything up, double checked things, and started her up… and hey, it worked! No more misses… I did a full round of about 10 miles on the freeway to get the engine warmed up and running nicely, and re-checked. Still perfect.

1 Actually, it doesn’t say “Check Engine”, it’s a picture of an engine, which doesn’t really look like an engine. When it first came on, I went “what the fuck is that?” I was in 4WD at the time, so my first thought was it was supposed to look like a transmission, so I pulled over and double checked the Jeep’s manual. They should consider updating it to look like an inline-6. :)

2 This makes me appreciative that the Jeep’s hood can be opened all the way back to rest on the windshield, which gives you a lot more elbow and head room while working.

Tent Blogging

In case you needed any more proof of how ubiquitous the internet has become, I’m currently sitting in a tent, many miles up a gravel road1, outside of Reno, Nevada. I’m camping solo, since Adrienne is going to Ohio for a few days.

It’s currently a bit after midnight, and I got the tent set up, got in, and noticed that I have full GSM service (thanks, Cingular!) with EDGE support, even. So I logged on in order to chat and tent blog. :)

1 Note that location, in case I get eaten by a bear…

Plugin-based backup for MySQL

I’ve been working on a new project to fulfill a specific need: consistent, fast, cheap, and flexible backups for MySQL, for all storage engines1. To that end I’m creating a tool called dbsnapper—a plugin-based backup tool. The tool itself is very basic and handles a few jobs: getting configuration information from the user, running through a “run sheet” of different configurable tasks, and reporting status and errors to the user.

The tasks then—the actual backup steps—are fully configurable, via plugins. In fact, the whole process isn’t even MySQL specific, and can potentially be used for PostgreSQL2 and other database as well. Remember the requirements for backups (above):

  • Consistent—We need to do some locking inside MySQL to make sure that the backups are consistent, for both MyISAM and InnoDB tables. This generally means the FLUSH TABLES WITH READ LOCK command.
  • Fast—There are two ways to get fast, but they both involve snapshotting: either inside the database, or on the volume level. The best way to get a backup quickly is by using Linux’s LVM, the Logical Volume Manager, to take a snapshot of the whole filesystem. Using mysqldump for backups fails miserably on this point.
  • Cheap—Well, backups should be free, and open source. Sorry ibbackup, sorry commercial utilities, become open source and we’ll talk.
  • Flexible—Everyone wants to do something slightly different with their backups, and in order for them to use one common tool, that tool needs to be very flexible. Most backup tools for MySQL are completely inflexible (other than the destination of the backup files). People often have slightly different requirements, why not try to make a single tool work?

It’s possible to meet all of the above requirements right now, but you would likely have to write your own backup script. When writing that script, you would likely do the minimum to make it work in your environment. Why should everyone write their own? My project3, dbsnapper is designed from the start to handle backups in a flexible and configurable way—to allow the user to decide what tools and processes to use, but to do it for them.

Keep an eye out, I’ll blog again once I’ve published the code!

1 Yes, yes, I know about the blue-sky internal online backup plans. Need I mention that online backup was originally planned for 4.0? Then it was moved to 4.1, where it would definitely get done… then to 5.0, a major new version, surely it will get done then. Now it’s likely not going to make it in 5.1, and slotted for 5.2, as far as I know. In the end, even if it does get done, that still doesn’t help people who want to backup their 4.0 or 4.1 installations, which is very common.

2 If someone is interested in working on the plugins for PostgreSQL, let me know, and I’ll give you a nudge once the plugin API is stable!

3 It need not be only “my” project. Anyone interested in helping?

New Storage Engines: A welcome change

There’s been a lot of buzz lately about new storage engines (Solid’s SolidDB and Jim Starkey’s Falcon) being developed for MySQL. Quite a few people have asked me what I think about them, and if it’s really a seamless process to switch storage engines. Everybody still has Oracle’s acquisition of Innobase Oy fresh on their minds, so nobody is really terribly surprised by the recent announcements. As for my opinion on the matter, well, it’ll take some discussion. I was quoted in ComputerWorld‘s article MySQL to encourage partners to build data storage engines:

Jeremy Cole, who oversees about 8,000 installations of the open-source database at Yahoo Inc., said the Sunnyvale, Calif.-based Web firm uses MyISAM for applications mostly requiring the reading of data—and InnoDB when many users may be writing data simultaneously.

Cole called InnoDB “great,” but also said it is “somewhat poorly integrated” with MySQL, lacking several common features such as full-text search and online configuration changes, while poorly supporting “referential integrity,” which keeps the relationships between data tables consistent.

Furthermore, the only way to do “reasonably fast online hot backups” with InnoDB is a closed-source tool called ibbackup, which is now owned by Oracle.

“If a new storage engine offered InnoDB’s current feature set without the above problems, and was stable, I would switch in a heartbeat,” Cole said. However, he doesn’t expect any of the unnannounced storage engines “to really be ready for use for another year or so.”

I wanted to follow up and provide a bit more depth and context, and some of the technical details that were not completely appropriate for ComputerWorld’s audience:

InnoDB has been great in that it has row-level locking, supports multi-versioning and isolation. That solves quite a few problems for transactional heavy-write applications. However, it’s somewhat poorly integrated into MySQL, and has some problems of its own. To name a few:

  • InnoDB’s only option for reasonably fast online hot backup is a tool called ibbackup, which is closed-source, was previously owned and sold by Innobase Oy (for about $1400 per server) and is now owned by Oracle. I haven’t heard anything about what Oracle intends to do with ibbackup.
  • InnoDB doesn’t allow any online configuration changes, as the rest of MySQL (and MyISAM) does. (Technically: It doesn’t support using the SET command to change its configuration on-the-fly.)
  • InnoDB doesn’t support full-text search—the ability to search for words within text documents. This is a feature used by many web applications. Effectively, users must choose between no transactions, table level locking, and full-text search (MyISAM), or transactions, row-level locking, and no full-text search (InnoDB). It’s sometimes a very painful choice.
  • Innobase Oy / InnoDB made a very “cowboy” effort to support foreign keys a.k.a. “referential integrity”—instead of working with MySQL to support it as a in-built feature of MySQL itself, they basically duck-taped it onto InnoDB itself. This has caused a lot of headaches for many people, including but not limited to completely useless error messages and mysterious failures.
  • InnoDB’s tablespace management leaves a lot to be desired. There are no online tablespace management commands (CREATE TABLESPACE, DROP TABLESPACE, ALTER TABLESPACE). You have two options:

    • All data for all tables and databases is stored in a single common set of files, with no online management, no ability to shrink the tablespace, the only way to add space is to set one of the files (and only one!) to auto-extend, and no ability to move data between the tablespace files; or
    • Each table’s data is stored in a single .ibd file—this file will be as large as the size of the table, so if you have 500GB of data in one table, you have a single unmanageable 500GB file. This file can never be shrunk, it can only grow.

Switching storage engines in MySQL is actually almost as easy as they claim. However, I don’t expect any of these new storage engines to really be ready for use for another year or so. There are a lot of integration issues to be had when pulling in a new storage engine. InnoDB had quite a lot of bugs in the first year due to this as well.

Will I use them? Absolutely.