[PR] Only mount shared DB drive if already mounting #322
This shifts the default behavior for VVV to non-persisting
This addresses the pain that is #287 and moves to a model that
We'll probably want to think of ways we can avoid data loss by
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
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
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.
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.
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.
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.