Perhaps the best thing about a datadot is that you can commit it with a simple command:
dm commit -m "empty state"
This creates a commit: a point-in-time snapshot of the state of the filesystem on the current branch for the current dot.
Suppose PostgreSQL then writes some data to the docker volume. You can then capture this new state in another commit with:
dm commit -m "some data"
There will then be two commits, frozen point-in-time snapshots, that
were created from the state of the
master branch at the point in
time when they were created:
You can confirm this in the output of:
commit 7f8c7cb6-c925-44b4-5a65-bcbf05a1da39 Author: admin Date: 1517055060834886217 empty state commit 435a520f-d01e-4bda-70e0-fc42e2043634 Author: admin Date: 1517055069443640226 some data
Commits are made immediately and atomically: they are “consistent snapshots” in the sense used in the PostgreSQL documentation.
It’s safe to create a commit while a database is running as long as the database supports recovering from a power outage.
Given the example above, you can roll back to the first commit with:
dm reset --hard HEAD^
HEAD^ means “one commit before the latest commit on the current
branch”. You can also do
dm log and refer to commits by id.
Note that rolling back stops the containers using a branch before the rollback, and starts them again afterwards. Otherwise, the database would be confused by its data directory changing “under its feet”.
Note also that a rollback is destructive – the commits after the commit that is rolled back to are irretrievably destroyed.
When you commit the state of a dot in a multi-node dotmesh cluster, that read-only snapshot of the dot gets replicated to all the other nodes. This means that, in a clustered installation, every commit is also a backup you can quickly roll back to from another node if the original one has an accident. Which is handy!