ZFS is excellent for database development! Create a snapshot before you try something that mess up your data and instantly restore it! If your development database is a few gigabytes, this will save you a lot of time.
When I was a contractor at IBM in the 90's we had something similar so we could work on OS/2 source code. The entire build project was made up of hundreds of other sub projects and it was way too big to fit on a single developer machine of the time. Plus the reality was that individual developers only edited small portions of any part, even though they needed the whole to build and test.
In later years, I've found myself thinking about ZFS for other big project scenarios. Like legacy enterprise websites that have gigs of static files and scripts that integrate with parts of webapps, etc. it's a pita to sync an 80gb mirror to every dev and a horrible waste of space. Much more efficient to simply mount the production mirror once and then store small edits locally.
Note that these kind of legacy sites are usually not checked into source control because they are too big.
What's the pro/con of zfs compare to docker?
I'd be really curious to see some actual numbers on this though.
https://clusterhq.com/flocker/introduction/
The ZFS version is not yet considered a production release due to delays in stabilizing the /dev/zfs API though.
Is ZFS any better than Btrfs in this regard?
The proper way of doing this is to clone the snapshot and then spin up a new container using the clone. That way you do not need to risk downtime on your production code. I believe that Delphix has a ZFS-based solution for doing this.
Might not be really feasible. In order to create a consistent snapshot you have to stop the database server (or, if running a multi-master setup, take one master out of replication, but MM setups are rare and even more so is experience with them).
Then, you have to actually do the clone - with a couple-GB-sized database, that's easy and fast but once you hit triple-digits GB sizes, you'll end up with a massive disk performance loss during the copy.
Also, in case your DB upgrade went through, you have to (magically) apply it to the other servers because in the time between clone-begin, clone-end and db-upgrade-end data will have changed on the prod system...
It's easier to make a short maintenance window, do a snapshot, hope for the best and if it blows up, restore service with a single click (by removing the maintenance page).
Also, if you need to stop the database for a consistent snapshot, then your database is not ACID compliant.
Do not try to snapshot a running database though. Before you execute the snapshot you should make sure everything is flushed to disk. For example with PostgreSQL you need to create a checkpoint before the snapshot, so you write:
SELECT pg_start_backup('prepare_my_snapshot');
AND when the snapshot is done:
SELECT pg_stop_backup();
Is a database (or anything else) really supposed to behave that way? Shouldn't every state along the way be possible to resume from? In particular, shouldn't database transactions take care of this?
The fine print: Due to the architecture of file system access in contemporary kernels (esp. file system caches), it's next to impossible for a user-space application to actually guarantee that writes are durable (i.e. synced to disk at a defined point in time), but most RDBMS manage well enough in practice.
While this doesn't relate to a specific file, you can always look at the size of Dirty and Writeback in /proc/meminfo. They correspond to the amount of dirty file page caches that have yet to be synced.
The problem is that production RDBMS tend to span multiple volumes, e.g., for logs vs. data to pick a simple case. FS snapshots in this case may not be consistent which would cause recovery to fail.
AFAIK this is why even robust RDBMS like MS SQL server use mechanisms like VSS to ensure data are flushed, which guarantees not just crash consistency but application consistency.
When this snapshot is taken you can send & recv the diff to a remote backup server.
As for flushing the database first, it is unnecessary as long as the database is ACID compliant. If you use MySQL, you will probably want to freeze and flush the database first to be absolutely certain of safety. DDL statements and a few minor other things in MySQL are known not to be ACID compliant.
Yes, but that's the point
You're right about LVM though
>You've been able to do this for years on Linux with LVM anyway.
What's the point of saying this in that tone? I could achieve the same goal in a number of different ways - that doesn't make any of those methods invalid because another one exists.
Also, the discussion is centered around ZFS, there's no reason to bring up LVM. Everyone knows there's many ways to skin this cat and it doesn't make anyone appear any smarter because they know of one way.