MySQL-Bind Mounts
another ways
About my topic at Data Persistence we talked how to mount a volume to our database container and we used Use Volumes for the first time.
Another ways to achieve it but slightly different from ‘Use Volumes’ is use ‘Bind Mounts’ method.
Before we go deeper please take an attention to Data Persistence at the last word (about docker-compose). We will run this section with docker-compose.
run it with
docker-compose up -d
if you notice we didn’t have a folder db-data before, but when we had run the compose we bring it (db-data folder) to this world. And it matches with what we previously believed that this folder was mounted to /var/lib/mysql. So it should be the same content as /var/lib/mysql in the container.
Use Volumes vs Use Bind Mounts
In general they both have the same results but slightly different in terms of performance and maintenance.
Use Bind Mounts when you need to share “artifacts” between hosts and containers (e.g. configuration files). But this method depends on our host machine’s filesystem structure which seems to be a potential problem on the next day, especially if we need to deploy on Linux and Windows with the same docker-compose.yml.
When we use ‘Use Volume’ we can get rid of the previous problems we encountered with binding mounts, and also this method will give us ‘hands free’ to perform backups or migrate data between different platforms which we cannot do with Bind Mounts . And of course YES for the Docker API.
Best practice for a database engine was use ‘Use Volume’ because its stored on Linux VM so we shouldn’t facing any issue when we need to migrate or backup and also we can have more performance compared ‘Bind Mounts’. But we still need ‘Bind Mounts’ for our configuration file, so we can easily tuning our engine.
