# Note: the command above does work if -export_binaries is removed. tar.gz -force -sandbox_ port=49311 -sandbox_ directory= memcached2 $ make_sandbox -export_binaries /volumes/ gemini/ sandbox- setup/mysql- 5.6.6-m9- osx10.6- x86_64. (On OS X, I don't have /opt/mysql at all.) Even after creating /opt/mysql/ myself, I could not get the command to run without a syntax error: Looks like it requires an additional x.y.z version argument, and for the /opt/mysql/ directory to already exist. I tried adding the -export_binaries option to the command I was already using. Adding -export_binaries to my previous make_sandbox command gives a succession of syntax errors. What would simplify my life would be a way with sbtool to change the BASEDIR settings in all the scripts for an existing sandbox. > # the binaries will now be in $HOME/opt/mysql/5.6.5 and the sandbox > $ make_sandbox -export_binaries /external/drive/mysql-5.6.5-linux-x86_ # BASEDIR=/volumes/gemini/sandbox-setup/5.6.6īASEDIR=/Users/cirrus/sandbox-setup/5.6.6 SBDIR="/Users/cirrus/sandboxes/memcached"
> You received this question notification because you are a directĮxport LD_LIBRARY_PATH=/Users/cirrus/sandbox-setup/5.6.6/lib:/Users/cirrus/sandbox-setup/5.6.6/lib/mysql:$LD_LIBRARY_PATHĮxport DYLD_LIBRARY_PATH=/Users/cirrus/sandbox-setup/5.6.6/lib:/Users/cirrus/sandbox-setup/5.6.6/lib/mysql:$DYLD_LIBRARY_PATH > # the binaries will now be in $HOME/opt/ mysql/5. > $ make_sandbox -export_binaries /external/ drive/mysql- 5.6.5-linux- x86_64- glibc23.
> There is a shortcut to achieve this goal, using make_sandbox with the If, instead, you wish to keep the expanded tarball for longer, you should move the expanded tarball into $SANDBOX_BINARY, which by default is $HOME/opt/mysql > If you are trying a temporary build that you will discard after you use the sandbox, this is fine. > by design, make_sandbox extracts the tarball in the same location where the tarball file is. > Giuseppe Maxia proposed the following answer: > Question #72638 on MySQL Sandbox changed: On May 23, 2012, at 11:45 PM, Giuseppe Maxia wrote: I don't know the solution yet for this latest. In my experience there are several different / frequent causes for this same 'sandbox server not started' error. Just minutes ago, I was happily doing stop, start, use with this particular sandbox, and hadn't made any changes involving ports, protocols, etc.Īnyway, sorry to go off on a tangent. I just rebooted a few minutes ago and now on startup it's writing out *.sock files rather than *.pid files, so I'm getting 'sandbox server not started' for what seems like a completely different reason. What seems to happen to me is that after any reboot, some new condition occurs that prompts the 'sandbox server not started' error.
#Sandvox mysql full#
In the other scripts such as 'start', those *_PATH variables are declared after BASEDIR, and reference $BASEDIR rather than spelling out the full path again. notice I changed the definition of BASEDIR from /volumes/gemini to /Users/Cirrus, but I had to make the same edit in the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH lines. 6.6īASEDIR= /Users/ cirrus/ sandbox- setup/5. # BASEDIR= /volumes/ gemini/ sandbox- setup/5. SBDIR=" /Users/ cirrus/ sandboxes/ memcached" 6.6/lib: /Users/ cirrus/ sandbox- setup/5. 6.6/lib/ mysql:$ LD_LIBRARY_ PATHĮxport DYLD_LIBRARY_ PATH=/Users/ cirrus/ sandbox- setup/5. For example, in 'use':Įxport LD_LIBRARY_ PATH=/Users/ cirrus/ sandbox- setup/5. When I tried to edit the various scripts to reflect the new BASEDIR location, I was successful but I found it required more editing than necessary. Or, if I start with the tarball unpacked on an external drive, I want to disconnect it to carry the laptop outside, so again I'd like to relocate it after the fact. So when the MySQL directory tree (or several) begins life on the SSD, I want to move it to an external drive to save on space. However, I'm running on a Macbook Air with a relatively full internal SSD. My conundrum is that I always start out wanting the unpacked tarball to be permanent.
0 kommentar(er)
