New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PR] Only mount shared DB drive if already mounting #322

Merged
merged 14 commits into from May 4, 2014

Conversation

Projects
None yet
1 participant
@jeremyfelt
Member

jeremyfelt commented Apr 4, 2014

This shifts the default behavior for VVV to non-persisting
databases. If an existing VM is already storing database data on
the guest machine, drives will continue to mount. If you remove
this data or start fresh with VVV, the MySQL directory will not
be stored on your computer.

This addresses the pain that is #287 and moves to a model that
(to me) makes more sense at all.

We'll probably want to think of ways we can avoid data loss by
making it easy to backup data on a regular basis as required.

See #287, #318, #213, #14

Only mount shared DB drive if already mounting
This shifts the default behavior for VVV to non-persisting
databases. If an existing VM is already storing database data on
the guest machine, drives will continue to mount. If you remove
this data or start fresh with VVV, the MySQL directory will not
be stored on your computer.

This addresses the pain that is #287 and moves to a model that
(to me) makes more sense at all.

We'll probably want to think of ways we can avoid data loss by
making it easy to backup data on a regular basis as required.
@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 12, 2014

I just did a fresh vagrant up on OSX with Vagrant 1.5.2 and VirtualBox 4.3.10 and all is good. A vagrant halt followed by a vagrant up worked as well, with no MySQL issues.

DB data is no longer persistent, so if vagrant destroy is used or the VM is lost/corrupted somehow, it will disappear. I'm going to explore some snapshot methods. At the very least, we can probably include a bash script that dumps all databases and another that imports them.

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 12, 2014

Initial tests with vagrant-vbox-snapshot are making me happy. :)

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 12, 2014

Snapshots do not work once a box is destroyed as they are still tied to the VM instance, so this really only helps if your original box is still up/halted.

Introduce vagrant_halt homebin file to run on halt
If the vagrant-triggers plugin is installed, the vagrant_halt
script will fire immediately before the virual machine is halted
after issuing the `vagrant halt` command.

This script can be used to perform useful cleanup and backup tasks,
though other backup options should always be used for critical data.

Next we can add a hook to a custom script so that additional tasks
can be added without worrying about maintaining upstream compatibility
@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 12, 2014

ae53361 introduces support for vagrant-triggers. Right now it only performs an action on vagrant halt—and that action is empty :)—but actions for destroy and suspend will soon follow.

jeremyfelt added some commits Apr 12, 2014

Add triggers for destroy and suspend
We can add triggers for a bunch of different Vagrant commands, but
the ones that bring down a VM seem most important in the near term
for things like backing up databases. This commit adds support for
both `vagrant destroy` and `vagrant suspend`. We can revisit
`vagrant up`, `vagrant resume`, etc... in the future.
Add README item for vagrant-triggers installation
We can fill this out a bit once we know what the scripts will
actually be doing.
Allow for custom trigger scripts
This sets each of the included trigger scripts to call a possible
custom trigger script. These can be used to perform various tasks
when the state of your virtual machine is about to be changed via
the Vagrant command line.
@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 12, 2014

In d5f433a, you can now include executable files such as config/homebin/vagrant_halt_custom that will be executed when the related Vagrant commands are issued. We should include some default DB related stuff, but anything is possible outside of that.

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 13, 2014

I'm going to go in the direction of providing default DB backups only if a custom script does not exist. If a custom script is added, then we'll assume it is handling DB backups on its own. If nothing else, the defaults can be copied to this new custom file if they need to run in addition. This way we aren't stomping on or defining any workflows too strictly.

jeremyfelt added some commits Apr 13, 2014

Handle custom and default triggers as either or
If a custom trigger script exists, we won't do anything in VVV.
Introduce db_backup command to backup databases
Introduces a home/vagrant/bin/db_backup that creates SQL dumps for
each of the databases setup in MySQL. These files overwrite existing
previous versions in the database/backups directory in the local
environment and can be used to restore the database if a VM is lost
or purposely destroyed.

By default, db_backup is fired whenever the halt, suspend, or destroy
commands are used. It can also be used from the command line inside
the virtual machine or on the host machine through something like:

`vagrant ssh -c "db_backup"`
Inline provisioning documentation for new behavior
Documents how databases are mapped, not mapped, and backed up
on halt, suspend, and destroy.
Merge branch 'master' into database
Merges changes to phpMyAdmin instalation
@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 13, 2014

Just tested this again with a full, from scratch vagrant up after a vagrant destroy created backup files. Databases imported as expected. 👍

Output a line for each database backed up
Provides some sort of feedback when the script runs so that we know
something happened.
@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 14, 2014

screen shot 2014-04-13 at 8 26 35 pm

Because everyone wants to look at a screenshot before I merge this in a day or two... :)

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 15, 2014

I'll do a better overall writeup later. For now, I'm going through the process of converting another machine and I'm taking notes. This is moving a powered off virtual machine to a non persistent DB. If you're starting in a destroyed state, the second set won't be necessary.

vagrant halt
cd vvv-dir/database/data/
rm -fr *
git checkout readme.txt
vagrant up

At this point, MySQL is horribly broken because we surprised it by taking the directory away.

vagrant ssh
sudo rm /etc/php5/fpm/pool.d/www.conf
sudo apt-get remove mysql-server-5.5 mysql-client-5.5 mysql-common php5-mysql
sudo apt-get purge mysql-server-5.5 mysql-client-5.5 mysql-common php5-mysql
exit
vagrant provision

Heads up, the above doesn't work that great, but it is close. The conversion process sucks. I ended up destroying so I could start over. I'll revisit at some point soon.

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented Apr 25, 2014

This will go in this weekend, you've been warned. ;-)

@jeremyfelt

This comment has been minimized.

Member

jeremyfelt commented May 4, 2014

And it's on. Master can probably be considered slightly more unstable than usual for the near future between this and #335.

jeremyfelt added a commit that referenced this pull request May 4, 2014

Merge pull request #322 from Varying-Vagrant-Vagrants/database
[PR] Only mount shared DB drive if already mounting

@jeremyfelt jeremyfelt merged commit 868f33b into master May 4, 2014

@jeremyfelt jeremyfelt deleted the database branch May 4, 2014

@jeremyfelt jeremyfelt referenced this pull request Jan 3, 2015

Closed

Keep DB in the VM #539

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment