Only works on Unix-like servers. Works with MySQL, Percona & MariaDB servers. MySQL server has the data directory, the port and the socket – you can’t share these.

To use it: make_sandbox foo.tar.gz. Then just do ./use.

$SANDBOX_HOME is ~/sandboxes. You can also create ~/opt/mysql/ and if you have MySQL 5.0.91 binary in that directory, you can just do “sb 5.1.91″.

Sandbox has features to start replication systems as well. You can have varying master/slave setups with varying versions as well (good idea to test from MySQL -> MariaDB master->slave for migration).

You can now also play with tungsten-sandbox, which is a great way to start playing with Tungsten Replicator (see documentation and tungsten-toolbox). There is apparently also a MySQL Cluster sandbox tool that someone is working on.

Related posts:

1. Building simple & complex replication clusters with Tungsten Replicator by Giuseppe Maxia
2. MySQL HA reloaded by Ivan Zoratti
3. MySQL synchronous replication in practice with Galera by Oli Sennhauser

Only works on Unix-like servers. Works with MySQL, Percona & MariaDB servers. MySQL server has the data directory, the port and the socket – you can’t share these.

To use it: make_sandbox foo.tar.gz. Then just do ./use.

$SANDBOX_HOME is ~/sandboxes. You can also create ~/opt/mysql/ and if you have MySQL 5.0.91 binary in that directory, you can just do “sb 5.1.91″.

Sandbox has features to start replication systems as well. You can have varying master/slave setups with varying versions as well (good idea to test from MySQL -> MariaDB master->slave for migration).

You can now also play with tungsten-sandbox, which is a great way to start playing with Tungsten Replicator (see documentation and tungsten-toolbox). There is apparently also a MySQL Cluster sandbox tool that someone is working on.

Related posts:

1. Building simple & complex replication clusters with Tungsten Replicator by Giuseppe Maxia
2. MySQL HA reloaded by Ivan Zoratti
3. MySQL synchronous replication in practice with Galera by Oli Sennhauser

MariaDB added to the Debian/Ubuntu wishlists
One of MariaDB’s goals is that it should be easily available for download. While we provide binaries and source at the MariaDB download page, we would love to see the binaries sitting in Linux distributions. So it is definitely good to see that it is on the Debian wishlist. It is also worth noting that Ubuntu has got it as a wishlist item as well.

MariaDB via the OpenSUSE build service
A community member, Michal Hrušecký, has decided that there will be tracking of MariaDB, and since it comes out of the OpenSUSE build service, you can find them in the unstable repository, for CentOS/RHEL 5, Fedora 11 and 12, Mandriva 2010, and OpenSUSE 11.1, 11.2, and the factory builds. All these are of course of the latest release available, which is MariaDB 5.1.42.

MariaDB for Solaris 10 and Debian on SPARC
Mark has very kindly decided to build binaries for Solaris 10 on Sparc as well as Debian GNU/Linux on Sparc. He even managed to write up a quick & dirty install guide, which should suffice for all intents and purposes. Note that these are still 5.1.41-RC releases, and you can expect to get updates soon for the released 5.1.42.

Using MariaDB with the MySQL Sandbox
The MySQL Sandbox is a great way to play with new releases of MySQL or MariaDB. Gerry Narvaja has got some tricks up his sleeve, to allow you to get going using MariaDB with the MySQL Sandbox.

MariaDB resources
A few resources if you’re new to the community:

• maria-discuss mailing list (and its archives)
• maria-developers mailing list (and its archives)
• #maria IRC logs. Don’t hesitate to join us on irc.freenode.net on #maria

Hope you’ve found this useful, and the aim is to have this bi-monthly, more frequent if there is a need for it. I might even record it as a short podcast, so you can take it on the go. If you have thoughts on this, don’t hesitate to contact me, or drop me an email at colin[AT]askmonty.org.

Related posts:

1. MariaDB 5.1.42 released!
2. MySQL with yaSSL vulnerability
3. Getting emo over binaries?

Step 1: Use A Symlink For The Tarball

ln -sv mariadb-5.1.42-Linux-x86_64.tar.gz mysql-5.1.42-Linux-x86_64.tar.gz
make_sandbox /home/gnarvaja/Downloads/mysql-5.1.42-Linux-x86_64.tar.gz --sandbox_directory=maria_5.1.42

Step 2: Use A Symlink For The MariaDB Binaries Directory

ln -sv mariadb-5.1.42-Linux-x86_64 mysql-5.1.42-Linux-x86_64
make_sandbox /home/gnarvaja/Downloads/mysql-5.1.42-Linux-x86_64.tar.gz --sandbox_directory=maria_5.1.42

Conclusion

I use CentOS and the rpm packages it provides and these work quite well. However, the MySQL rpms do not allow me to manage single and multiple instances alike and while mysqld runs as the mysql user the instance management needs to be done as root (stopping, starting instances, or default access). If you want to run multiple instances you can also use mysqld_multi, but that’s not the default setup.

So this is not ideal. While this may not be much of an issue if you manage a single server, if you manage tens or hundreds things changes somewhat and you REALLY want to manage all instances consistently.

So I’ve been thinking about finding an alternative which would suit me better. What do I need?

• The same treatment of a single instance or multiples on one box.
• Management as much as possible from a non-root user (mysql?)
• Separation of instances into separate “areas”, along the lines of Oracle’s Optimal Flexible Architecture.
• Automatic startup on server boot, and shutdown of “SELECTED” instances.
• Ability to support different versions of mysql running at the same time.
• Straight forward mechanism to upgrade a server or switch the version of MySQL that is used to manage a specific instance..

I was thinking of writing my own scripts but one solution which looks potentially close enough to my ideal solution would be to use Giuseppe Maxia’s MySQL Sandbox. I think this project was born with a completely different goal (enable you to quickly get a different mysql version up and running for testing), but it actually seems to solve most of the things I want for managing production instances.

If you’ve not used it yet take a look. It works pretty well and is easy to setup.

So what can it do at the moment:

• Allow you to install different versions of mysql on the same box.
• Run everthing as a non-root user
• Stop and start either one or all instances easily

For my needs it seems to be missing:

• The ability to indicate which instances should start / stop and a way to trigger this from init during startup / shutdown.
• The way to access the instances is quite different from a normal mysql installation. That has confused me quite a bit and as I use the Sandbox infrequently I have to go back and workout how to “get in” and also how to start or stop any instance, or check if it’s running.
• I’m not entirely sure if it’s easy to adjust the paths for the different mysql “areas” to fit in with my usage of MySQL or something similar to OFA. These things are probably pretty easy to fix.
• The name MySQL Sandbox sounds rather inappropriate if you really used it to manage mysql instances. That’s easy to change.

Ideal MySQL Layout

So how would I like the layout to look like?

Tarball binaries should probably be located somewhere like /path/to/some_binary_name, which allows us to distinguish between different architectures (i686, x86_64), and versions (5.0.89, 5.1.42, 5.5.0-m2). That’s already solved by the current tarballs which have a prefix such as mysql-5.5.0-m2-osx10.5-x86.

Each instance’s data should probably be located along the lines of:

/path/to/instance_name/data (for MySQL data files and my.cnf)
/path/to/instance_name/tmp (for MySQL tmpdir)
/path/to/instance_name/log (for MySQL logfiles (binlog and relaylog)

This allows the locations under /path/to/ to be mounted on different file systems for performance (if needed). In my case /path/to is simply /mysql, but that does not need to be that rigid. OFA is slightly different but the idea is the same.

Accessing the Instances

How do I access the instances?

Currently I access the instances using the following mechanism. Each instance has a name so that name is used to access the instance as a prefix of the normal mysql command.

So instance “a” is “managed”/”accessed” as follows:

mysql_a access to mysql command line
mysqldump_a access to mysqldump
mysqladmin_a access to mysqladmin
…

Oracle does something slightly different by setting up the environment to determine which instance to be accessed. Then the normal command line utilities talk to the right instance.

Either way is fine but it should be very clear which instance you are attempting to access to avoid what could be costly mistakes.

It would be nice if the sandbox provided a common directory which could be included in $PATH so that all instances could be accessed from one place.

I don’t currently have a managed way to start / stop the instances. A file like /etc/oratab would do and then a command like:

mysql_init start # start all ‘marked’ instances
mysql_init stop # stop all ‘marked’ instances
mysql_init_a start # start instance a

The final thing to want to do is to upgrade an instance. Normally this involves:

• Downloading the new version.
• Stopping the instance to be upgraded.
• Adjusting links/directories.
• Perform various “admin tasks” to upgrade the instance.
• Starting it normally again.

All that MySQL sandbox would need to do would be to perform 3.

So these are some of my ideas. I need to look at the MySQL Sandbox code in more detail to see if it will fit my needs but I expect it should not be too difficult to adjust it if needed.

Perhaps if you use other operating systems or package managers and manage one or more MySQL instances on multiple servers these issues are less of a problem. I have not seen comments by others worrying about some of the limitations of the current MySQL rpms and the problem is not really with rpm itself but with the expected usage of a single instance on a single server.

So is there a better way to do this or might MySQL Sandbox be the right solution to achieve my goal?