Skip to content
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
Merged

Conversation

jeremyfelt
Copy link
Member

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

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
Copy link
Member Author

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
Copy link
Member Author

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

@jeremyfelt
Copy link
Member Author

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.

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
Copy link
Member Author

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.

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.
We can fill this out a bit once we know what the scripts will
actually be doing.
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
Copy link
Member Author

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
Copy link
Member Author

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.

If a custom trigger script exists, we won't do anything in VVV.
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"`
Documents how databases are mapped, not mapped, and backed up
on halt, suspend, and destroy.
Merges changes to phpMyAdmin instalation
@jeremyfelt
Copy link
Member Author

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

Provides some sort of feedback when the script runs so that we know
something happened.
@jeremyfelt
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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

@jeremyfelt
Copy link
Member Author

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
[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 18:30
@jeremyfelt jeremyfelt mentioned this pull request Jan 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant