April 5, 2009

How MySQL Sandbox Solves All My Problems

Filed under: Code, MySQL — Gregory Haase @ 4:01 am

I just can’t help thinking about how amazing and useful MySQL Sanbox is. There are so many things that it can do, and so many problems that it solves for Database Developers. When it comes down to it, I really think that every project that uses MySQL can benefit in some way or another just by using MySQL Sandbox. Here are just some of the challenges that database developers face on a regular basis that sandbox can fix:

  • Upgrade Planning – Are you wanting to upgrade your binaries but are afraid to take the leap. Is there too much activity going on in development that you can’t afford to be disruptive? MySQL Sandbox provides an easy, non-destructive means of testing. Just use make_sandbox with the –datadir_from option. It will copy your current data directory (or a copy of your data directory residing somewhere on the filesystem) into a new sandbox with the version. From there you can test as much as you want without disrupting your current development database.
  • Support Multiple Branches and Multiple Developers - When you have a lot of developers working with your database one of two things can happen – either they all have local instances of the database (in which case you end up running around trying to fix a bunch of broken instances that are all running different versions), or they are all using the same database and breaking things for each other. The old way to fix this was to run a bunch of cheap commodity hardware boxes and have a server on each. The smarter guys got virtualization going, and saved snapshots of database servers and cloned that way. Other guys used mysqld_multi to run a bunch of MySQL servers on the same set of binaries on the same OS. The problem with all these methods is that it’s a lot of overhead for something that is typically short lived. Development cycles can be quick – sometimes lasting less than a week. MySQL Sandbox resolves this by making it trivial to spin up lots and lots of instances. Whenever a developer needs a new copy to work with, just run make_sandbox and give him the new connection string (This will most likely be identical to his current connection string with a change of port number).
  •  Check Backward Compatibility - Does your software package boast that it runs on mysql > 4.0. Does it work on every version in between? How do you even know? And how do you prevent that developer who’s using MySQL 5.1 from introducing incompatible features? How do you catch it if he does? You wouldn’t want to have permanent or even semi-permanent copies of your database on every version. MySQL_Sandbox makes it easy. Just store all the binaries you want to test against and create sandboxes to test each one before you release.
  • Easily Support Multiple Versions – I’ve seen it enough times; It’s an open source project, and there’s a user out there that is seeing an error that no one else can replicate. The development staff things it’s a version issue, but no one seems to have that user’s version installed.  The next step is a call to the community – is anyone else running version XYZ that can test this out. With sandbox, you have no more excuses. Just download the binaries for that version, make_sandbox, and try to replicate the error. Did the user compile their own binaries? If you had the same architecture, could he send them to you?
  • Test New Replication Schemes - Is your environment getting complicated? To you have two many slaves running off a single master and need to introduce a new layer. Mysql_sandbox comes with several prepared schemes out of the box, including standard, circular, and master-master. Start with one of these existing schemes, or start with a bunch of disconnected sandboxes and connect them all together to test your production plans.

I’m sure this is just the tip of the iceberg. I’m sure that are many others ways that people can think of to use MySQL Sandbox. And I bet that some people are already doing wild things that none of us have even thought of. If you are, please share your experiences with us.

March 22, 2009

Choosing the Tools for Release Management

Filed under: Code, MySQL — Gregory Haase @ 3:10 am

There is More Than One Way…

When I give my tutorial session at the MySQL Conference and Expo next month, I am going to talk a lot about different tools that you can use to manage your release processes. For example, I will be spending a lot of time talk about how to use source control, and I will be using Bazaar in the tutorial. And I will be talking about how to package releases and I will be using Apache’s Maven. The system that I will show you how to put together will work brilliantly on it’s own. And it wasn’t entirely created in a vacuum – it is based on at least 2 implementations with which I’ve been involved. But it may not work for you and your environment out of the box. There are tons of different source control systems out there, and there are probably equally as many build systems. Chances are your company is already using some of these tools for application development. You should leverage these existing tools as much as possible. (more…)

January 27, 2009

Source Control Layouts for Databases

Filed under: Code, MySQL — Gregory Haase @ 2:53 am

It’s easy to decide that you’re going to store changes to your database in source control, but it can be difficult to figure out what and where it should be stored.  In this article I’ll explain what I like to see put into source control, and how I layout my source control folders. (more…)

December 20, 2008

Continuous Integration is Not New!

Filed under: MySQL — Gregory Haase @ 1:57 am

There is no news flash: Continuous Integration is not new. It will, however, get a significant amount of attention during my upcoming tutorial session at the MySQL User Conference in April, where I am very pleased to be presenting Build and Release Management for Database Engineers(more…)

December 1, 2008

Performance notes on INFORMATION_SCHEMA tables

Filed under: Code, MySQL — Gregory Haase @ 2:38 pm

I have written a bit in the past about using INFORMATION_SCHEMA tables, and I use them extensively in stored procedures for performing regular maintenance operations. There are a great many clever and useful things you can do with them. However, recently I have been noticing some performance issues using these tables that puts a damper on their usefulness. (more…)

Older Posts »

The Silver is the New Black Theme Blog at


Get every new post delivered to your Inbox.