Bookmark/Search this post

ZFS Support in Blackbirds 2.0

You are here

ZFS Support in Blackbirds 2.0

Error message

Note: This blog was published over a year ago. Content may be out of date.

Hello techblog readers. There's a high probability that you've read about the new features in Blackbirds Release 2.0. The big ticket items include geo-distribution, automation, and java stored procedures. In addition to these awesome new features, we slipped in support for ZFS, specifically Native ZFS on Linux. Are you saying, hell yeah! Well you should be and here's why.

ZFS support was requested by a few folks looking to use the snapshots feature for their backup strategy. ZFS can provide a comprehensive backup strategy for storing a NuoDB database at an affordable price. ZFS is highly vigilant about protecting your data and it has a long list of features to back it up such as; data integrity (checksums, mirroring, raid-z, scrub, snapshots), storage pools, cache (ARC, L2ARC, ZIL), copy-on-write transactional model, deduplication, compression, and more.

You might recall that our CTO Seth Proctor posted a blog titled, Our Approach to Database Backup. Seth describes starting up a second Storage Manager (SM), letting it sync the database, then shutting down the second SM, and saving the archive to a backup directory. In the case of ZFS, a ZFS snapshot could be taken at step 3, "Copy the local archive somewhere" instead of taking a copy. The ability to run NuoDB on ZFS allows you to take the backup strategy even further. In Blackbirds, a snapshot can be taken while the database is running (live snapshot). How cool is that? Alright, so what's the gotcha? The restriction for the live snapshot is that both the archive directory and the journal directory must reside in the same ZFS dataset.

Here's a step by step live snapshot guide on Ubuntu using Seth's original domain and tea database.

Now create the ZFS dataset and set a few properties to enhance performance. The most notable setting is the recordsize setting which should be set to match the size of the IO. For NuoDB, this should be set to 64 KB which is the atom size (50 KB) rounded up to a power of 2.

Did you notice the compression property? NuoDB's archive and journal can be compressed through ZFS. We've seen anywhere from 1.52x to 2.24x compression ratios with the gzip compression algorithm. In addition to the space saving, turning on compression can result in a performance boost! FYI, ZFSOnLinux has a variety of supported compression algorithms such as; LZJB, ZLE, LZ4, GZIP, and GZIP-[1-9].

Ok, so at this point ZFS has been configured. Let's start up the database.

Great. The tea database is now running with ZFS. The next step is to demonstrate ZFS snapshots by creating some data and taking a snapshot with NuoDB running. Then we'll drop the table and restore it using the ZFS snapshot.

It's ok to have other databases running just not the tea database that we are trying to restore. Also, the broker and agent can remain up and running. To perform a rollback from a ZFS snapshot, the dataset must be unmounted.

Success! The ZFS snapshot has saved the day. This is a quick and simple demonstration of the power and flexibility that ZFS snapshots provides with NuoDB. If you're interested in tuning ZFS, I recommend checking out ZFS for Databases [1] & [2] and ZFS Intent Log for more details. I also recommend reading Aaron Toponce's series of posts on Zpool & ZFS Administration. Stay tuned for my next blog post on archive encryption!