[PR] Only mount shared DB drive if already mounting #322
Conversation
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.
|
I just did a fresh DB data is no longer persistent, so if |
|
Initial tests with vagrant-vbox-snapshot are making me happy. :) |
|
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
|
ae53361 introduces support for vagrant-triggers. Right now it only performs an action on |
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.
|
In d5f433a, you can now include executable files such as |
|
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
|
Just tested this again with a full, from scratch |
Provides some sort of feedback when the script runs so that we know something happened.
|
Because everyone wants to look at a screenshot before I merge this in a day or two... :) |
|
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. At this point, MySQL is horribly broken because we surprised it by taking the directory away. 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. |
|
This will go in this weekend, you've been warned. ;-) |
|
And it's on. Master can probably be considered slightly more unstable than usual for the near future between this and #335. |
[PR] 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.
See #287, #318, #213, #14