Add example on how to keep the DB

[TLyngeJ]

If the container is killed, the DB usually goes the same way. This example show how to keep the data even is the container dies.

[achekulaev]

@lmakarov looks like nice to have

[lmakarov]

This would only make sense on Linux. On Mac and Windows (via boot2docker) /var/lib/mysql would be effectively mounted over NFS/SMB, which would make performance painfully slow.

@TLyngeJ can you please explain your use case? What would be the benefit of making /var/lib/mysql persist even after the DB container is completely removed?

[TLyngeJ]

The use case is, that sometimes you'll need to update the container, but won't like to spend the 30 minutes, it sometimes takes to import databases.

And the purpose of this change is more to make people aware that it can be done, not enabling it by default. A comment could also make people aware of that this shouldn't be done, if you're running docker through a VM.

[fuzzbomb]

@TLyngeJ There's a typo in a comment.

Uncomment the followinf line => Uncomment the following line

[james-nesbitt]

RE: persistant data:

consider snapshotting dbs by "docker commit" to a new image tag? images are exportable and distributable, but commited images are big. Requires that you don't use "VOLUME /var/lib/mysql"

[achekulaev]

@james-nesbitt this would mean no updates to container

[kyleskrinak]

This aspect — losing a database on a container rebuild — came up in my Drude presentation to a TriDUG meetup. Excuse my weak docker knowledge, but could you use a container solely dedicated as a persistent storage volume for the mysql data?

[james-nesbitt]

@achekulaev yeah good point. (you couldn't update the db base image without significant effort, if you kept a versioned db image with content)

@kyleskrinak a versioned volume container is a good idea. It of course needs db image version pinning to be considered at the application layer, for cases where the /var/lib/mysql would be invalid with a newer db version. That would really suck for testing.