31–40 of 148 posts
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.
Traditionally, DB engines avoid FS specific features like the plague.
It looks like ZFS which came from BSD systems will be/is the next big thing in Linux, not Ubuntu on Windows which gets more hype...
Earlier quoted context omitted.
Yes, if they have ZFS too, it is basically snapshot, send & receive. Or you can clone it and rsync it to them. 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: SE…
It's too bad Unix/Linux doesn't offer something like Windows' VSS API, where the operating system can inform registered applications or services of an impending backup operation.
> Who needs Git? > Notably missing is support for merging So, it's almost like a car except it's missing its wheels No, it's not like Git
> Using ZFS as a replacement of Git for is probably not a good idea, but just to give you a sense of what ZFS supports at the file system level, let me go through a few typical git-like operations:
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.
Earlier quoted context omitted.
Except you'll lose all the data since you created the snapshot... You've been able to do this for years on Linux with LVM anyway.
I don't think you read the comment thoroughly. This is the point. 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.
How production ready is ZFS on Ubuntu (Debian?) ? Is there any risk of Oracle fighting back open source zfs as for Java with Google and Android ?
As the article notes, ZFS on Linux has been production-ready and stable for over three years. For in-depth info see [2].
Earlier quoted context omitted.
Yes, if they have ZFS too, it is basically snapshot, send & receive. Or you can clone it and rsync it to them. 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: SE…
> Do not try to snapshot a running database though. Before you execute the snapshot you should make sure everything is flushed to disk. 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?