.\" Automatically generated by Pod::Man 4.07 (Pod::Simple 3.32) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is >0, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .if !\nF .nr F 0 .if \nF>0 \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} .\} .\" ======================================================================== .\" .IX Title "MySQL::Sandbox::Recipes 3pm" .TH MySQL::Sandbox::Recipes 3pm "2017-01-05" "perl v5.24.1" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" MySQL::Sandbox::Recipes \- A cookbook for MySQL Sandbox .SH "PURPOSE" .IX Header "PURPOSE" This package is a collection of HOW-TO brief tutorials and recipes for MySQL Sandbox .SH "Installing MySQL::Sandbox" .IX Header "Installing MySQL::Sandbox" All the recipes here need the 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 .SS "the easy way \- as root" .IX Subsection "the easy way - as root" This is so easy, that I am almost ashamed to show it. Anyway, here goes. .PP .Vb 2 \& $ sudo su \- \& # cpan MySQL::Sandbox .Ve .SS "the ambitious way \- as unprivileged user" .IX Subsection "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 \f(CW$HOME\fR/usr/local. .IP "1." 3 Download MySQL Sandbox tarball from cpan .IP "2." 3 Set the variables that you will need .Sp .Vb 3 \& mkdir \-p $HOME/usr/local \& export PATH=$HOME/usr/local/bin:$PATH \& export PERL5LIB=$HOME/usr/local/lib/perl5/site_perl/5.8.8 .Ve .IP "3." 3 Build and install .Sp .Vb 4 \& perl Makefile.PL PREFIX=$HOME/usr/local \& make \& make test \& make install .Ve .PP 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. .PP 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 \s-1CPAN\s0 to install any package in your user space. .SH "SINGLE SERVER RECIPES" .IX Header "SINGLE SERVER RECIPES" .SS "Creating a single sandbox" .IX Subsection "Creating a single sandbox" .IP "1." 3 Download or build a MySQL server tarball. Its name is something like mysql\-X.X.X\-Your_Operating_System.tar.gz .IP "2." 3 Make the sandbox .Sp .Vb 1 \& make_sandbox /path/to/mysql\-X.X.X\-Your_Operating_System.tar.gz .Ve .Sp Notice that this command will expand the tarball into a directory \f(CW\*(C`X.X.X\*(C'\fR, located in the same path where tghe tarball is. If you want to expand in a centralized directory, see the next recipe. .Sp If you have already a centralized repository for your binaries (see next recipe), then you can create a sandbox even more easily: .Sp .Vb 2 \& make_sandbox 5.1.34 \& make_replication_sandbox 5.1.34 .Ve .SS "Easily creating more sandboxes after the first one" .IX Subsection "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 \f(CW$SANDBOX_BINARY\fR, which by default is \f(CW$HOME\fR/opt/mysql If you have such a directory, you have two choices. .IP "manually" 3 .IX Item "manually" Expand the tarball, and move it under \f(CW$HOME\fR/opt/mysql (or set \f(CW$SANDBOX_BINARY\fR to a path that suits you better). Name the directory with the version number. For example: .Sp .Vb 3 \& 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 .Ve .Sp Now, next time you want to install a sandbox using 5.1.34, all you need to do is say .Sp .Vb 1 \& make_sandbox 5.1.34 .Ve .IP "automatically" 3 .IX Item "automatically" If you want to combine installation and centralization of the binaries in one go, you can: .Sp .Vb 1 \& make_sandbox \-\-export_binaries /path/to/mysql\-5.1.34\-osx10.5\-x86.tar.gz .Ve .Sp The expanded tarball is copied to the \f(CW$SANDBOX_BINARY\fR path, and you can refer to the version number only for future installations. .SS "Using a single sandbox" .IX Subsection "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 \f(CW$HOME\fR/sandboxes/msb_X_X_XX, where X_X_XX is the version number. For example if you have installed .PP .Vb 1 \& make_sandbox 5.1.34 .Ve .PP your sandbox is under \f(CW$HOME\fR/sandboxes/msb_5_1_34. .PP To use it, move to that directory and invoke the \f(CW\*(C`./use\*(C'\fR script. This script is a shortcut to invoke the mysql command line client, with all the appropriate parameters. .PP .Vb 8 \& ./msb_5_1_34/use \& Welcome to the MySQL monitor. Commands end with ; or \eg. \& Your MySQL connection id is 1 \& Server version: 5.1.34 MySQL Community Server (GPL) \& . \& Type \*(Aqhelp;\*(Aq or \*(Aq\eh\*(Aq for help. Type \*(Aq\ec\*(Aq to clear the current input statement. \& . \& mysql [localhost] {msandbox} ((none)) > .Ve .PP The default user is 'msandbox' and the password is 'msandbox'. The same password is also used by the 'root' account. .PP The 'use' script accepts all the additional options and commands that you would use with the mysql client. For example: .PP .Vb 8 \& ./use \-e \*(Aqshow schemas\*(Aq \& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ \& | Database | \& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ \& | information_schema | \& | mysql | \& | test | \& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ \& \& ./use \-N \-B \-e \*(Aqselect version()\*(Aq \& 5.1.34 .Ve .PP You don't need to be inside the sandbox to use this script. You can invoke it with a relative or absolute path. .PP .Vb 6 \& $HOME/sandboxes/msb_5_1_34/use \-e \*(Aqselect version()\*(Aq \& +\-\-\-\-\-\-\-\-\-\-\-+ \& | version() | \& +\-\-\-\-\-\-\-\-\-\-\-+ \& | 5.1.34 | \& +\-\-\-\-\-\-\-\-\-\-\-+ .Ve .PP 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. .SS "Creating a single sandbox with user-defined port and directory" .IX Subsection "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: .PP .Vb 1 \& low_level_make_sandbox \-\-help .Ve .PP You can pass any of the options listed to \f(CW\*(C`make_sandbox\*(C'\fR. In particular, since we need to change the port and directory, here's the deed: .PP .Vb 2 \& 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 .Ve .PP See the next recipe for an automatic way of getting a different port and directory. .SS "Creating a single sandbox with automatic port checking" .IX Subsection "Creating a single sandbox with automatic port checking" .Vb 1 \& make_sandbox 5.1.34 \-\- \-\-check_port .Ve .PP 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. .SS "Creating a single sandbox with a specific option file" .IX Subsection "Creating a single sandbox with a specific option file" .Vb 1 \& make_sandbox 5.1.34 \-\- \-\-my_file=large .Ve .PP 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 .PP .Vb 1 \& make_sandbox 5.1.34 \-\- \-\-my_file=/path/to/my_smart.cnf .Ve .PP 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). .SS "Creating a single sandbox from a source directory" .IX Subsection "Creating a single sandbox from a source directory" After you have compiled MySQL from source, you can create a sandbox with the new binaries: .PP .Vb 1 \& make_sandbox_from_source $PWD single [options] .Ve .PP 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. .SS "Starting or restarting a single sandbox with temporary options" .IX Subsection "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. .PP .Vb 1 \& ./start \-\-key\-buffer=3G .Ve .PP 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. .SS "Stopping a sandbox" .IX Subsection "Stopping a sandbox" Inside every single sandbox there are two scripts that can stop a sandbox. .PP .Vb 1 \& ./stop .Ve .PP The 'stop' script attempts a clean stop, using mysqladmin. This works most of the time, especially if you are using a \s-1GA\s0 release. .PP .Vb 1 \& ./send_kill .Ve .PP 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 \f(CW\*(C`kill \-15\*(C'\fR to the server \s-1PID.\s0 If this fails, after a reasonable timeout, it sends a deadly \f(CW\*(C`kill \-9\*(C'\fR and removes the \s-1PID\s0 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. .SS "Cleaning up a sandbox" .IX Subsection "Cleaning up a sandbox" .Vb 1 \& ./clear .Ve .PP 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 \f(CW\*(C`drop database\*(C'\fR 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. \&\s-1WARNING\s0! No confirmation is asked! The data will be gone in 1 second. .SS "Copying sandbox contents to another" .IX Subsection "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 \f(CW\*(C`\-\-source_dir\*(C'\fR option (or \f(CW\*(C`\-s\*(C'\fR for short). The second directory, identified with \f(CW\*(C`\-\-dest_dir\*(C'\fR, (or \f(CW\*(C`\-d\*(C'\fR) is the place where the data is copied. \&\s-1WARNING\s0! the destination data is overwritten! This command skips binary logs, relay logs, and general logs. .PP .Vb 3 \& sbtool \-o copy \e \& \-s /path/to/source/sandbox \e \& \-d /path/to/destination/sandbox .Ve .PP Some important points to remember: .IP "\(bu" 3 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. .IP "\(bu" 3 Before copying, this command stops both source and destination sandbox. .SS "Moving a sandbox" .IX Subsection "Moving a sandbox" .Vb 3 \& sbtool \-o move \e \& \-s /path/to/source/sandbox \e \& \-d /path/to/destination/directory .Ve .PP 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. .PP If the destination directory already exists, the command fails. .SS "Changing port to an existing sandbox" .IX Subsection "Changing port to an existing sandbox" .Vb 3 \& sbtool \-o port \e \& \-s /path/to/source/sandbox \e \& \-\-new_port=XXXX .Ve .PP 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. .SS "Removing a sandbox completely" .IX Subsection "Removing a sandbox completely" .Vb 2 \& sbtool \-o delete \e \& \-s /path/to/source/sandbox .Ve .PP 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. .PP \&\s-1WARNING\s0! No confirmation is asked! The data will be gone in 1 second. .SS "Making a sandbox permanent" .IX Subsection "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 \*(L"oh no\*(R" moments. Notice that nothing will protect you against hastily typed '\s-1DROP DATABASE\s0' queries! If you really need your data around, make a copy! .PP .Vb 2 \& sbtool \-o preserve \e \& \-s /path/to/source/sandbox .Ve .PP If you change your mind, invoking sbtool with the 'unpreserve' operation, makes the sandbox erasable again. .PP .Vb 2 \& sbtool \-o unpreserve \e \& \-s /path/to/source/sandbox .Ve .SS "Starting and stopping a sandbox when the host server starts" .IX Subsection "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. .SS "Installing a sandbox from already installed binaries" .IX Subsection "Installing a sandbox from already installed binaries" .Vb 1 \& make_sandbox_from_installed VERSION [options] .Ve .PP 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: .PP .Vb 3 \& mkdir \-p $HOME/opt/mysql \& cd $HOME/opt/mysql \& make_sandbox_from_installed 5.1.34 \-\-no_confirm .Ve .PP After this call, you can then install sandboxes (single or multiple) with a simple .PP .Vb 1 \& make_{replication_|multiple_}sandbox 5.1.34 .Ve .SH "MULTIPLE SERVER RECIPES" .IX Header "MULTIPLE SERVER RECIPES" .SS "Creating a standard replication sandbox" .IX Subsection "Creating a standard replication sandbox" .Vb 1 \& make_replication_sandbox /path/to/tarball5.1.34.tar.gz .Ve .PP 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 \f(CW$SANDBOX_BINARY\fR (see \*(L"Easily creating more sandboxes after the first one\*(R"), then you can also say .PP .Vb 1 \& make_replication_sandbox 5.1.34 .Ve .PP If you want a different number of slaves, you can add an option .PP .Vb 1 \& make_replication_sandbox \-\-how_many_slaves=5 5.1.34 .Ve .SS "Using a replication sandbox" .IX Subsection "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 \f(CW$HOME\fR/sandboxes/rsandbox_X_X_XX, where X_X_XX is the version number. For example if you have installed .PP .Vb 1 \& make_replication_sandbox 5.1.34 .Ve .PP your sandbox is under \f(CW$HOME\fR/sandboxes/rsandbox_5_1_34. .PP To use it, move to that directory and invoke one of these scripts: .PP .Vb 5 \& * ./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 .Ve .PP 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. .SS "Creating a circular replication sandbox" .IX Subsection "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. .PP .Vb 1 \& make_replication_sandbox \-\-circular=4 /path/to/tarball5.1.34.tar.gz .Ve .PP 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. .PP If you have a binary repository under \f(CW$SANDBOX_BINARY\fR, you can use the simplified call: .PP .Vb 1 \& make_replication_sandbox \-\-circular=4 5.1.34 .Ve .SS "Using a circular sandbox" .IX Subsection "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: .PP .Vb 10 \& $ ./n1 \-e \*(Aqcreate table test.t1 (i int)\*(Aq \& $ ./n3 \-e \*(Aqinsert into test.t1 values (3)\*(Aq \& $ ./use_all \*(Aqselect * from test.t1\*(Aq \& # server: 1: \& i \& 3 \& # server: 2: \& i \& 3 \& # server: 3: \& i \& 3 \& # server: 4: \& i \& 3 .Ve .SS "Creating a group of unrelated sandboxes (same version)" .IX Subsection "Creating a group of unrelated sandboxes (same version)" .Vb 2 \& make_multiple_sandbox /path/to/tarball \& make_multiple_sandbox \-\-how_many_nodes=4 /path/to/tarball .Ve .PP 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. .SS "Creating a group of unrelated sandboxes (different versions)" .IX Subsection "Creating a group of unrelated sandboxes (different versions)" .Vb 2 \& 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 .Ve .PP 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. .SS "Using a group of sandboxes" .IX Subsection "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. .PP A group of sandboxes is easily manged with the 'use_all' script. For example, you may want to pass a \s-1SQL\s0 instruction to all the servers .PP .Vb 1 \& ./use_all \*(Aqselect something from dbname.tablename where x=1\*(Aq .Ve .PP Or you want to execute a \s-1SQL\s0 script for each server .PP .Vb 1 \& ./use_all \*(Aqsource somescript.sql\*(Aq .Ve .PP 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: .PP .Vb 8 \& ./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 \*(Aqselect something_heavy from somedb.sometable\*(Aq \& ./node$N/stop \& done .Ve .SS "Creating a group sandbox with port checking" .IX Subsection "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 (\f(CW\*(C`\-\-replication_directory\*(C'\fR \f(CW\*(C`\-\-group_directory\*(C'\fR), but this will use the same base port number, unless you specify \f(CW\*(C`\-\-check_base_port\*(C'\fR. .PP .Vb 3 \& 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 \e \& \-\-check_base_port 5.0.79 \& # Creates a replication directory under $SANDBOX_HOME/newdir \& # The previous one is preserved. No conflicts happen .Ve .SS "Creating a group sandbox with a specific option file" .IX Subsection "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: .PP .Vb 3 \& 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 .Ve .PP If you don't need the distinction, then you can define the same option for all nodes at once: .PP .Vb 2 \& export NODE_OPTIONS="\-\-my_file=large" \& make_replication_sandbox 5.1.34 .Ve .PP For non-replication group sandboxes (or for circular replication), \f(CW$NODE_OPTION\fR is the appropriate way of setting options. .PP .Vb 2 \& export NODE_OPTIONS="\-\-my_file=large" \& make_multiple_sandbox 5.1.34 .Ve .SS "Creating a group sandbox from a source directory" .IX Subsection "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. .PP .Vb 2 \& make_sandbox_from_source $PWD replication [options] \& make_sandbox_from_source $PWD multiple [options] .Ve .SS "Starting or restarting a group sandbox with temporary options" .IX Subsection "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. .PP .Vb 2 \& ./start_all \-\-mysqld=mysqld\-debug \-\-gdb \& ./restart_all \-\-max\-allowed\-packet=20M .Ve .SS "Stopping a group sandbox" .IX Subsection "Stopping a group sandbox" The natural way of stopping a group of sandboxes is to invoke the \f(CW\*(C`stop_all\*(C'\fR script. This will work as expected most of the time. .PP .Vb 1 \& ./stop_all .Ve .PP If you are dealing with a potentially unresponsive server (for example when testing alpha code), then you may use \f(CW\*(C`send_kill_all\*(C'\fR, 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. .PP .Vb 1 \& ./send_kill_all .Ve .SS "Cleaning up a group sandbox" .IX Subsection "Cleaning up a group sandbox" To revert a group sandbox to its original state, the quickest way is to call \f(CW\*(C`clear_all\*(C'\fR, which will invoke the \f(CW\*(C`clear\*(C'\fR script in every depending single sandbox. .PP .Vb 1 \& ./clear_all .Ve .PP In a replication sandbox, this command will also remove all replication settings. For this reason, \f(CW\*(C`clear_all\*(C'\fR creates a dummy file called \f(CW\*(C`needs_initialization\*(C'\fR, containing the date and time of the cleanup. This is a signal for \f(CW\*(C`start_all\*(C'\fR to initialize the slaves at the next occurrence. No need for the user to do anything special. The sandbox is self healing. .SS "Moving a group sandbox" .IX Subsection "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. .PP .Vb 3 \& sbtool \-o move \e \& \-s /path/to/source/sandbox \e \& \-d /path/to/destination/directory .Ve .SS "Removing a group sandbox completely" .IX Subsection "Removing a group sandbox completely" The sbtool can delete completely any sandbox, either single or multiple. .PP .Vb 2 \& sbtool \-o delete \e \& \-s /path/to/source/sandbox .Ve .PP This operation will fail if the sandbox has been made permanent. (See next recipe). .SS "Making a group sandbox permanent" .IX Subsection "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. \f(CW\*(C`sbtool\*(C'\fR achieves this goal by disabling the \f(CW\*(C`clear_all\*(C'\fR script and the \f(CW\*(C`clear\*(C'\fR script in all depending sandboxes. In this state, also the 'delete' operation fails (see previous recipe). .PP .Vb 2 \& sbtool \-o preserve \e \& \-s /path/to/source/sandbox .Ve .PP When you need to get rid of the sandbox contents quickly, you can 'unpreserve' it, and the clear* scripts will be enabled again. .PP .Vb 2 \& sbtool \-o unpreserve \e \& \-s /path/to/source/sandbox .Ve .SH "Managing sandboxes in groups" .IX Header "Managing sandboxes in groups" .SS "Using more than one \s-1SANDBOX_HOME\s0" .IX Subsection "Using more than one SANDBOX_HOME" The default \f(CW$SANDBOX_HOME\fR is \f(CW$HOME\fR/sandboxes, which is suitable for most purposes. If your \f(CW$HOME\fR is not fit for this task (e.g. if it is located in a \s-1NFS\s0 partition), you may set a different one on the command line or in your shell startup file. .PP .Vb 2 \& export SANDBOX_HOME=/my/alternative/directory \& make_sandbox 5.1.34 \-\- \-\-check_port .Ve .PP 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. .SS "Stopping all sandboxes at once" .IX Subsection "Stopping all sandboxes at once" The \f(CW$SANDBOX_HOME\fR 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. .PP .Vb 1 \& $SANDBOX_HOME/stop_all .Ve .SS "Starting all sandboxes at once" .IX Subsection "Starting all sandboxes at once" Similarly to the previous recipe, you can start all sandboxes at once with a single command. .PP .Vb 1 \& $SANDBOX_HOME/start_all .Ve .PP 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. .SS "Running the same query on all active sandboxes" .IX Subsection "Running the same query on all active sandboxes" This is a quick way of getting a result from every sandbox under \f(CW$SANDBOX_HOME\fR. The query passed to \f(CW\*(C`use_all\*(C'\fR will be passed to every \f(CW\*(C`use\*(C'\fR or \f(CW\*(C`use_all\*(C'\fR scripts of the depending sandboxes. .PP .Vb 1 \& $SANDBOX_HOME/use_all \*(Aqselect something_cool\*(Aq .Ve .PP If you want to run several queries from a script, use the \f(CW\*(C`source\*(C'\fR keyword: .PP .Vb 1 \& $SANDBOX_HOME/use_all \*(Aqsource /full/path/to/script.sql\*(Aq .Ve .SH "Testing with sandboxes" .IX Header "Testing with sandboxes" .SS "Running the built-in test suite" .IX Subsection "Running the built-in test suite" Download and expand the MySQL Sandbox package .PP .Vb 5 \& perl Makefile.PL \& make \& TEST_VERSION=/path/to/mysql/tarball make test \& # or \& TEST_VERSION=5.1.34 make test .Ve .PP The \s-1TEST_VERSION\s0 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 \s-1SANDBOX_HOME\s0 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. .PP \&\s-1IMPORTANT:\s0 When running test_sandbox, either standalone or within the test suite, it will stop all sandboxes inside \f(CW$SANDBOX_HOME\fR, to prevent conflicts with the sandboxes created during the tests. .SS "Creating and running your own tests" .IX Subsection "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 .PP .Vb 1 \& test_sandbox \-\-user_test=your_test.sb .Ve .PP To use a Perl test, name the test with a .sb.pl extension. .PP .Vb 1 \& test_sandbox \-\-user_test=your_test.sb.pl .Ve .SH "Remote Sandboxes" .IX Header "Remote Sandboxes" .SS "Access sandboxes from other hosts" .IX Subsection "Access sandboxes from other hosts" By default, a MySQL sandbox instance can be accessed by localhost only. This access is regulated by an option, \f(CW\*(C`\-\-remote_access\*(C'\fR, 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. .PP .Vb 5 \& grant all on *.* to msandbox@\*(Aq127.%\*(Aq identified by \*(Aqmsandbox\*(Aq; \& grant all on *.* to msandbox@\*(Aqlocalhost\*(Aq identified by \*(Aqmsandbox\*(Aq; \& grant SELECT,EXECUTE on *.* to msandbox_ro@\*(Aq127.%\*(Aq identified by \*(Aqmsandbox\*(Aq; \& grant SELECT,EXECUTE on *.* to msandbox_ro@\*(Aqlocalhost\*(Aq identified by \*(Aqmsandbox\*(Aq; \& grant REPLICATION SLAVE on *.* to rsandbox@\*(Aq127.%\*(Aq identified by \*(Aqrsandbox\*(Aq; .Ve .PP If you want to access the sandbox remotely, you can change \f(CW\*(C`\-\-remote_access\*(C'\fR to include your specific subnet, or to open it completely .PP .Vb 2 \& \-\-remote_access=\*(Aq192.168.1.%\*(Aq \& \-\-remote_access=\*(Aq%\*(Aq .Ve .PP 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. .SS "Deploy MySQL sandboxes to many hosts" .IX Subsection "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. .PP .Vb 9 \& $ 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\*(Aqt work. .Ve .SH "COPYRIGHT" .IX Header "COPYRIGHT" Version 3.1 .PP Copyright (C) 2006\-2016 Giuseppe Maxia .PP Home Page https://github.com/datacharmer .SH "LEGAL NOTICE" .IX Header "LEGAL NOTICE" .Vb 1 \& Copyright 2006\-2016 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. .Ve