Provided by: mysql-sandbox_3.1.04-1_all 
NAME
MySQL::Sandbox::Recipes - A cookbook for MySQL Sandbox
PURPOSE
This package is a collection of HOW-TO brief tutorials and recipes for MySQL Sandbox
Installing MySQL::Sandbox
All the recipes here need the MySQL Sandbox <http://launchpad.net/mysql-sandbox>. Therefore you need to
install it, to be able to follow these recipes. For a general description of the application, see
MySQL::Sandbox. A presentation on this matter is available at Slideshare
<http://www.slideshare.net/datacharmer/mysql-sandbox-3>
the easy way - as root
This is so easy, that I am almost ashamed to show it. Anyway, here goes.
$ sudo su -
# cpan MySQL::Sandbox
the ambitious way - as unprivileged user
It is not difficult, but it requires some steps that depend on your environment. To simplify the
example, let's assume that you are using perl 5.8.8 and you want to install in $HOME/usr/local.
1. Download MySQL Sandbox tarball from cpan
2. Set the variables that you will need
mkdir -p $HOME/usr/local
export PATH=$HOME/usr/local/bin:$PATH
export PERL5LIB=$HOME/usr/local/lib/perl5/site_perl/5.8.8
3. Build and install
perl Makefile.PL PREFIX=$HOME/usr/local
make
make test
make install
It is a bit complex, but you need to do the setup only once. After that, you can use MySQL Sandbox in
your user space.
Another solution, which can be habdy if you use a box without Perl and without root access, is to install
Perl in your user space, and then you can use CPAN to install any package in your user space.
SINGLE SERVER RECIPES
Creating a single sandbox
1. Download or build a MySQL server tarball. Its name is something like
mysql-X.X.X-Your_Operating_System.tar.gz
2. Make the sandbox
make_sandbox /path/to/mysql-X.X.X-Your_Operating_System.tar.gz
Notice that this command will expand the tarball into a directory "X.X.X", located in the same path
where tghe tarball is. If you want to expand in a centralized directory, see the next recipe.
If you have already a centralized repository for your binaries (see next recipe), then you can create
a sandbox even more easily:
make_sandbox 5.1.34
make_replication_sandbox 5.1.34
Easily creating more sandboxes after the first one
If you want to reuse the same binaries more than once, you can set up a repository for such binaries,
under $SANDBOX_BINARY, which by default is $HOME/opt/mysql If you have such a directory, you have two
choices.
manually
Expand the tarball, and move it under $HOME/opt/mysql (or set $SANDBOX_BINARY to a path that suits you
better). Name the directory with the version number. For example:
cd $HOME/opt/mysql
gunzip -c /path/to/mysql-5.1.34-osx10.5-x86.tar.gz | tar -xf -
mv mysql-5.1.34-osx10.5-x86 5.1.34
Now, next time you want to install a sandbox using 5.1.34, all you need to do is say
make_sandbox 5.1.34
automatically
If you want to combine installation and centralization of the binaries in one go, you can:
make_sandbox --export_binaries /path/to/mysql-5.1.34-osx10.5-x86.tar.gz
The expanded tarball is copied to the $SANDBOX_BINARY path, and you can refer to the version number
only for future installations.
Using a single sandbox
When you create a sandbox, the last line of the application output tells you where it was created. If
you don't remember where it is, the default location is $HOME/sandboxes/msb_X_X_XX, where X_X_XX is the
version number. For example if you have installed
make_sandbox 5.1.34
your sandbox is under $HOME/sandboxes/msb_5_1_34.
To use it, move to that directory and invoke the "./use" script. This script is a shortcut to invoke the
mysql command line client, with all the appropriate parameters.
./msb_5_1_34/use
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.34 MySQL Community Server (GPL)
.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
.
mysql [localhost] {msandbox} ((none)) >
The default user is 'msandbox' and the password is 'msandbox'. The same password is also used by the
'root' account.
The 'use' script accepts all the additional options and commands that you would use with the mysql
client. For example:
./use -e 'show schemas'
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| test |
+--------------------+
./use -N -B -e 'select version()'
5.1.34
You don't need to be inside the sandbox to use this script. You can invoke it with a relative or absolute
path.
$HOME/sandboxes/msb_5_1_34/use -e 'select version()'
+-----------+
| version() |
+-----------+
| 5.1.34 |
+-----------+
Notice that this script is created when the sandbox is installed. It is heavily customized for that
sandbox only, and it is not replaceable by the same script from another sandbox. Even if you move it to
another directory, it will still refer to the sandbox in which it was created. See 'moving a sandbox' for
a safe way of moving a sandbox with all its scripts to a different directory.
Creating a single sandbox with user-defined port and directory
When you create a sandbox, you can fine tune the final product by adding options. You can list of all the
available options easily:
low_level_make_sandbox --help
You can pass any of the options listed to "make_sandbox". In particular, since we need to change the port
and directory, here's the deed:
make_sandbox 5.1.34
# installs on $SANDBOX_HOME/msb_5_1_34 with port 5134
make_sandbox 5.1.34 -- --sandbox_port=7800 --sandbox_directory=mickeymouse
# installs on $SANDBOX_HOME/mickeymouse with port 7800
See the next recipe for an automatic way of getting a different port and directory.
Creating a single sandbox with automatic port checking
make_sandbox 5.1.34 -- --check_port
This option will check if port 5134 is used. If it is, it will check the next available port, until it
finds a free one. In the previous statement context, 'free' means not only 'in use', but also allocated
by another sandbox that is currently not running. If the directory msb_5_1_34 is used, the sandbox is
created in msb_5_1_34_a. The application keeps checking for free ports and unused directories until it
finds a suitable combination. Notice that this option is disabled when you use a group sandbox
(replication or multiple). Even if you set NODE_OPTIONS=--check_port, it won't be used, because every
group sandbox invokes make_sandbox with the --no_check_port option.
Creating a single sandbox with a specific option file
make_sandbox 5.1.34 -- --my_file=large
This option installs the option file template my-large.cnf, which ships with every MySQL release.
Similarly, you can choose 'small' or 'huge' to load the appropriate template. If you have your favorite
option file, you can specify the full path to it
make_sandbox 5.1.34 -- --my_file=/path/to/my_smart.cnf
In all cases, the sandbox installer skips all the options that are necessary to keep the sandbox isolated
and efficient (user, port,socket,datadir,basedir).
Creating a single sandbox from a source directory
After you have compiled MySQL from source, you can create a sandbox with the new binaries:
make_sandbox_from_source $PWD single [options]
The options are the same that you can pass to make_sandbox. This script creates a tarball, and then
invokes make_sandbox to finish the job.
Starting or restarting a single sandbox with temporary options
Every single server sandbox has a 'start' script, which does what the name suggests. Not only that, but
you can start a sandbox with additional parameters for the mysqld daemon.
./start --key-buffer=3G
The 'restart' script accepts parameters in the same way. While 'start' only works when the sandboxed
server is not running, 'restart' makes sure that the server is stopped, and then invokes 'start' with the
optional parameters.
Stopping a sandbox
Inside every single sandbox there are two scripts that can stop a sandbox.
./stop
The 'stop' script attempts a clean stop, using mysqladmin. This works most of the time, especially if you
are using a GA release.
./send_kill
The 'send_kill' script achieve the same result, but with a different path. First, it tries to stop the
sandboxed server nicely, by sending a "kill -15" to the server PID. If this fails, after a reasonable
timeout, it sends a deadly "kill -9" and removes the PID file. This brutal method is not recommended for
general usage, but it is sometimes necessary when dealing with servers in early stages of their
development.
Cleaning up a sandbox
./clear
The 'clear' script will empty the data directory, trying to clean the system as much as possible. If the
server is running when you invoke the script, it will issue a "drop database" query for each schema. It
will also truncate the general and slow query log tables, if they exist. If the server is not running,
'clear' will clean up the data directory as best as it can. Notice however that invoking 'clear' when the
server is not running will not remove stored routines and events. WARNING! No confirmation is asked! The
data will be gone in 1 second.
Copying sandbox contents to another
Using 'sbtool', the Sandbox helper, this task is easy to perform. You need two sandboxes. This command
cannnot copy to an arbitrary directory, but only to an existing sandbox. The first sandbox is where the
data is stored. You need to use the "--source_dir" option (or "-s" for short). The second directory,
identified with "--dest_dir", (or "-d") is the place where the data is copied. WARNING! the destination
data is overwritten! This command skips binary logs, relay logs, and general logs.
sbtool -o copy \
-s /path/to/source/sandbox \
-d /path/to/destination/sandbox
Some important points to remember:
• This command only copies from a single sandbox to another. If you want to copy from a masterto several
slaves, you need to run the command multiple times.
• Before copying, this command stops both source and destination sandbox.
Moving a sandbox
sbtool -o move \
-s /path/to/source/sandbox \
-d /path/to/destination/directory
This command stops the sandbox, moves it to the requested directory, and then changes all the paths in
the scripts, to refer to the new directory.
If the destination directory already exists, the command fails.
Changing port to an existing sandbox
sbtool -o port \
-s /path/to/source/sandbox \
--new_port=XXXX
THis is similar to moving a sandbox, except that the directory is not changed. The sandbox is stopped,
and the port changed in all the scripts.
Removing a sandbox completely
sbtool -o delete \
-s /path/to/source/sandbox
This is a combination of using the 'clear' script and removing the sandbox. There is a safety check,
though. If the sandbox is a permanent one (see next recipe), the operation aborts. Otherwise, the script
calls 'clear' (clear_all if it is a group sandbox) and then removes all the contents.
WARNING! No confirmation is asked! The data will be gone in 1 second.
Making a sandbox permanent
MySQL Sandbox has been created with testing in mind. As such, the sandboxes are expendable, and there are
some commands to get rid of them easily and quickly. However, you don't want always to do this.
Sometimes, you need to keep the data for some time, to record it, or to copy it somewhere, or to use it
for some similar testing. Whatever the reason, in these cases you don't want your data to disappear
accidentally. The 'preserve' command, part of the sbtool, disables the 'clear' script in your sandbox,
to avoid unpleasant "oh no" moments. Notice that nothing will protect you against hastily typed 'DROP
DATABASE' queries! If you really need your data around, make a copy!
sbtool -o preserve \
-s /path/to/source/sandbox
If you change your mind, invoking sbtool with the 'unpreserve' operation, makes the sandbox erasable
again.
sbtool -o unpreserve \
-s /path/to/source/sandbox
Starting and stopping a sandbox when the host server starts
There is no built-in solution for this recipe. Every operating system has its own method to launch
applications at start up. The important point is that probably you don't need it. MySQL Sandbox is a
tool for testing, aiming at creating temporary MySQL servers, and as such you should not need to launch a
sandbox at start up. If you really need it, the MySQL manual explain how to launch at startup the main
instance of the database.
Installing a sandbox from already installed binaries
make_sandbox_from_installed VERSION [options]
This script (introduced in 2.0.99e) creates a repository of symbolic links from already installed
binaries, arranging them in a way that the MySQL Sandbox easily recognizes. You should move to a
directory where you want to keep this repository, before invoking this script. For example:
mkdir -p $HOME/opt/mysql
cd $HOME/opt/mysql
make_sandbox_from_installed 5.1.34 --no_confirm
After this call, you can then install sandboxes (single or multiple) with a simple
make_{replication_|multiple_}sandbox 5.1.34
MULTIPLE SERVER RECIPES
Creating a standard replication sandbox
make_replication_sandbox /path/to/tarball5.1.34.tar.gz
As easy as making a single sandbox, this command creates a replication system with one master an two
slaves. If you have set the repository under $SANDBOX_BINARY (see "Easily creating more sandboxes after
the first one"), then you can also say
make_replication_sandbox 5.1.34
If you want a different number of slaves, you can add an option
make_replication_sandbox --how_many_slaves=5 5.1.34
Using a replication sandbox
When you create a replication sandbox, the last line of the application output tells you where it was
created. If you don't remember where it is, the default location is $HOME/sandboxes/rsandbox_X_X_XX,
where X_X_XX is the version number. For example if you have installed
make_replication_sandbox 5.1.34
your sandbox is under $HOME/sandboxes/rsandbox_5_1_34.
To use it, move to that directory and invoke one of these scripts:
* ./m for the master
* ./s1 for the first slave
* ./s2 for the second slave, s3 for the third one, and so on
* ./use_all to send a command to the master and all slaves
* ./check_slaves to see as a quick glance if the slaves are working
All the above scripts are shortcuts to the 'use' script in the appropriate directory. The 'use' script
was described in the section dedicated to single server recipes.
Creating a circular replication sandbox
To create a circular replication system, you use the same command used for standard replication, but you
add an option to indicate that you want a circular topology.
make_replication_sandbox --circular=4 /path/to/tarball5.1.34.tar.gz
The above command creates a system with 4 nodes, where node 1 is master of 2, node 2 is master of 3, node
3 is master of 4, and node 4, to close the circle, is master of 1.
If you have a binary repository under $SANDBOX_BINARY, you can use the simplified call:
make_replication_sandbox --circular=4 5.1.34
Using a circular sandbox
Same as using a replication sandbox (see above), but there are no 'm' and 's#' scripts. Instead, there
are 'n#' scripts, to access node 1 (n1), node 2, (n2) and so on. You may try this:
$ ./n1 -e 'create table test.t1 (i int)'
$ ./n3 -e 'insert into test.t1 values (3)'
$ ./use_all 'select * from test.t1'
# server: 1:
i
3
# server: 2:
i
3
# server: 3:
i
3
# server: 4:
i
3
Creating a group of unrelated sandboxes (same version)
make_multiple_sandbox /path/to/tarball
make_multiple_sandbox --how_many_nodes=4 /path/to/tarball
A group of unrelated sandboxes is a set of three or more servers installed under the same directory.
What is the purpose of this? It is useful whenever you need to play with several servers without being
tied by the master/slave relationship. One possible reason is to try new replication schemes with a
clean setup. Or you may want to test the Federated engine. Another common usage is when you need to test
different approaches to the same problem, and you want to compare results quickly.
Creating a group of unrelated sandboxes (different versions)
make_multiple_custom_sandbox /path/to/tarball5.1.34 /path/to/tarball5.0.77
make_multiple_custom_sandbox 5.1.34 5.0.77 5.4.0
Similar to the previous one, the composite group is a collection of servers of different versions, all
under the same directory. It can be useful when you want to compare some scheme in different versions,
and automate the operations as much as possible.
Using a group of sandboxes
Same as using a replication sandbox (see above), but there are no 'm' and 's#' scripts. Instead, there
are 'n#' scripts, to access node 1 (n1), node 2, (n2) and so on.
A group of sandboxes is easily manged with the 'use_all' script. For example, you may want to pass a SQL
instruction to all the servers
./use_all 'select something from dbname.tablename where x=1'
Or you want to execute a SQL script for each server
./use_all 'source somescript.sql'
The internal organization of the directory makes it easy to do more complex operations with all the
servers within the group. For example, if you want to measure the speed of execution of the same
statement for each server (assuming that you have different setups for each one), you can create a shell
script:
./stop_all
for N in 1 2 3
do
echo "processing node $N"
./node$N/start --some_mysqld_option=somevalue
time ./node$N/use -e 'select something_heavy from somedb.sometable'
./node$N/stop
done
Creating a group sandbox with port checking
When you create a multiple sandbox (make_replication_sandbox, make_multiple_sandbox,
make_multiple_custom_sandbox) the default behavior is to overwrite the existing sandbox without asking
for confirmation. The rationale is that a multiple sandbox is definitely more likely to be a created
only for testing purposes, and overwriting it should not be a problem. If you want to avoid overwriting,
you can specify a different group name ("--replication_directory" "--group_directory"), but this will use
the same base port number, unless you specify "--check_base_port".
make_replication_sandbox 5.0.79
# Creates a replication directory under $SANDBOX_HOME/rsandbox_5_0_79
# The default base_port is 7000
make_replication_sandbox 5.0.79
# Creates a replication directory under $SANDBOX_HOME/rsandbox_5_0_79
# overwriting the previous one. The default base port is still 7000
# WRONG
make_replication_sandbox --check_base_port 5.0.79
# Creates a replication directory under $SANDBOX_HOME/rsandbox_5_0_79
# overwriting the previous one.
# WRONG
make_replication_sandbox --replication_directory=newdir 5.0.79
# Created a replication directory under $SANDBOX_HOME/newdir.
# The previous one is preserved, but the new sandbox does not start
# because of port conflict.
# RIGHT
make_replication_sandbox --replication_directory=newwdir \
--check_base_port 5.0.79
# Creates a replication directory under $SANDBOX_HOME/newdir
# The previous one is preserved. No conflicts happen
Creating a group sandbox with a specific option file
When you create a group sandbox, make_sanbox is invoked several times, with a predefined set of options.
You can add options for each node by means of environmental variables. If you create a replication
sandbox, you can set different options for the master and for the slaves:
export MASTER_OPTIONS="--my_file=huge"
export SLAVE_OPTIONS="--my_file=large"
make_replication_sandbox 5.1.34
export MASTER_OPTIONS="--my_file=/path/to/my.cnf"
export SLAVE_OPTIONS="--my_file=/path/to/my_other.cnf"
make_replication_sandbox 5.1.34
If you don't need the distinction, then you can define the same option for all nodes at once:
export NODE_OPTIONS="--my_file=large"
make_replication_sandbox 5.1.34
For non-replication group sandboxes (or for circular replication), $NODE_OPTION is the appropriate way of
setting options.
export NODE_OPTIONS="--my_file=large"
make_multiple_sandbox 5.1.34
Creating a group sandbox from a source directory
Same as for a single sandbox, but use the 'replication' or 'multiple' keyword when calling the script.
make_sandbox_from_source $PWD replication [options]
make_sandbox_from_source $PWD multiple [options]
Starting or restarting a group sandbox with temporary options
When you want to restart a group of sandboxes with some temporary options, all you need to do is to pass
the option to the command line of ./start_all (if the group was not running) or ./restart_all.
./start_all --mysqld=mysqld-debug --gdb
./restart_all --max-allowed-packet=20M
Stopping a group sandbox
The natural way of stopping a group of sandboxes is to invoke the "stop_all" script. This will work as
expected most of the time.
./stop_all
If you are dealing with a potentially unresponsive server (for example when testing alpha code), then you
may use "send_kill_all", which will attempt a gentle stop first, and then kill the server brutally, if it
does not respond after a predefined timeout of 10 seconds.
./send_kill_all
Cleaning up a group sandbox
To revert a group sandbox to its original state, the quickest way is to call "clear_all", which will
invoke the "clear" script in every depending single sandbox.
./clear_all
In a replication sandbox, this command will also remove all replication settings. For this reason,
"clear_all" creates a dummy file called "needs_initialization", containing the date and time of the
cleanup. This is a signal for "start_all" to initialize the slaves at the next occurrence. No need for
the user to do anything special. The sandbox is self healing.
Moving a group sandbox
This recipe is the same for single and multiple sandboxes. Using the sbtool will move a sandbox in a
clean and safe way. All the elements of the sandbox will be changed to adapt to the new location.
sbtool -o move \
-s /path/to/source/sandbox \
-d /path/to/destination/directory
Removing a group sandbox completely
The sbtool can delete completely any sandbox, either single or multiple.
sbtool -o delete \
-s /path/to/source/sandbox
This operation will fail if the sandbox has been made permanent. (See next recipe).
Making a group sandbox permanent
A sandbox is designed to be easy to create and to throw away, because its primary purpose is testing.
However, there are cases when you want to keep the contents around for a while, and you therefore want to
make sure that the sandbox is not cleaned up or deleted by mistake. "sbtool" achieves this goal by
disabling the "clear_all" script and the "clear" script in all depending sandboxes. In this state, also
the 'delete' operation fails (see previous recipe).
sbtool -o preserve \
-s /path/to/source/sandbox
When you need to get rid of the sandbox contents quickly, you can 'unpreserve' it, and the clear* scripts
will be enabled again.
sbtool -o unpreserve \
-s /path/to/source/sandbox
Managing sandboxes in groups
Using more than one SANDBOX_HOME
The default $SANDBOX_HOME is $HOME/sandboxes, which is suitable for most purposes. If your $HOME is not
fit for this task (e.g. if it is located in a NFS partition), you may set a different one on the command
line or in your shell startup file.
export SANDBOX_HOME=/my/alternative/directory
make_sandbox 5.1.34 -- --check_port
The above procedure is also useful when you, for any reasons, want a completely different set of
sandboxes for a new batch of tests, and you want to be able to manage all of them at once. To avoid
conflicts, you should always use the --check_port option.
Stopping all sandboxes at once
The $SANDBOX_HOME directory is the place containing all sandboxes, both single and multiple. This allows
you to stop all of them at once with a single command.
$SANDBOX_HOME/stop_all
Starting all sandboxes at once
Similarly to the previous recipe, you can start all sandboxes at once with a single command.
$SANDBOX_HOME/start_all
Notice that, if you created two or more sandboxes that use the same port, (create one with port X, stop
it, create another with port X), there will be a conflict, and the second sandbox (and subsequent ones)
won't start.
Running the same query on all active sandboxes
This is a quick way of getting a result from every sandbox under $SANDBOX_HOME. The query passed to
"use_all" will be passed to every "use" or "use_all" scripts of the depending sandboxes.
$SANDBOX_HOME/use_all 'select something_cool'
If you want to run several queries from a script, use the "source" keyword:
$SANDBOX_HOME/use_all 'source /full/path/to/script.sql'
Testing with sandboxes
Running the built-in test suite
Download and expand the MySQL Sandbox package
perl Makefile.PL
make
TEST_VERSION=/path/to/mysql/tarball make test
# or
TEST_VERSION=5.1.34 make test
The TEST_VERSION environment variable contains a version or the path to a tarball used by the test suite.
If no test version is provided, most of the tests are skipped. The test suite creates a private
SANDBOX_HOME under ./t/test_sb. All the sandboxes needed for the test are executed there. If something
goes wrong, that is the place to inspect for clues.
IMPORTANT: When running test_sandbox, either standalone or within the test suite, it will stop all
sandboxes inside $SANDBOX_HOME, to prevent conflicts with the sandboxes created during the tests.
Creating and running your own tests
Look at the ./t directory inside the MySQL Sandbox package (previous recipe). There are several .sb
files, which are good examples of what you can do with the simple testing language. If this is not
enough, you can use Perl itself. There are a few .sb.pl files, which are plugins for test_sandbox. Once
you create your file, you can run it with
test_sandbox --user_test=your_test.sb
To use a Perl test, name the test with a .sb.pl extension.
test_sandbox --user_test=your_test.sb.pl
Remote Sandboxes
Access sandboxes from other hosts
By default, a MySQL sandbox instance can be accessed by localhost only. This access is regulated by an
option, "--remote_access", which is set to '127.%', and it is used to create the default users. You can
see the resulting instructions in the file 'grants.mysql' inside each sandbox.
grant all on *.* to msandbox@'127.%' identified by 'msandbox';
grant all on *.* to msandbox@'localhost' identified by 'msandbox';
grant SELECT,EXECUTE on *.* to msandbox_ro@'127.%' identified by 'msandbox';
grant SELECT,EXECUTE on *.* to msandbox_ro@'localhost' identified by 'msandbox';
grant REPLICATION SLAVE on *.* to rsandbox@'127.%' identified by 'rsandbox';
If you want to access the sandbox remotely, you can change "--remote_access" to include your specific
subnet, or to open it completely
--remote_access='192.168.1.%'
--remote_access='%'
Starting with MySQL::Sandbox 3.0.34, you can also define the bind address for your MySQL server. By
default it is '127.0.0.1'. It will be changed to '0.0.0.0' if you choose a customized --remote_access. If
you change both --remote_access and --bind_address, No adjustment will be made.
Deploy MySQL sandboxes to many hosts
MySQL Sandbox 3.0.32 and later include a script that lets you deploy a sandbox quickly to several hosts.
$ deploy_to_remote_sandboxes -h
Deploy to remote sandboxes.
Usage: deploy_to_remote_sandboxes [options]
-h => help
-P port => MySQL port (15530)
-d sandbox dir => sandbox directory name (remote_sb)
-m version => MySQL version (5.5.30)
-l list of nodes =>list of nodes where to deploy
-t tarball => MySQL tarball to install remotely (none)
This command takes the list of nodes and installs a MySQL sandbox in each one.
You must have ssh access to the remote nodes, or this script won't work.
COPYRIGHT
Version 3.1
Copyright (C) 2006-2015 Giuseppe Maxia
Home Page http://github.com/datacharmer
LEGAL NOTICE
Copyright 2006-2015 Giuseppe Maxia
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
perl v5.22.1 2016-01-12 MySQL::Sandbox::Recipes(3pm)