4 ms·

> 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 dat

by ryao 10y ago

> 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. 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.

mschuster91 10y ago
> The proper way of doing this is to clone the snapshot 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).
- ryao 10y ago
  I think you are confused about ZFS clones. You never stop a production application for a clone because the clone is made from a snapshot. It also is copy on write, so you have no massive data copy. If your application, is not crash consistent, you do need to get it to pause, flush a consistent state and do the snapshot, but the snapshot takes less than a second to do, so such a thing is probably fine. Also, if you need to stop the database for a consistent snapshot, then your database is not ACID compliant.

by ryao 10y ago

mschuster91 10y ago

> The proper way of doing this is to clone the snapshot 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).

ryao 10y ago
I think you are confused about ZFS clones. You never stop a production application for a clone because the clone is made from a snapshot. It also is copy on write, so you have no massive data copy. If your application, is not crash consistent, you do need to get it to pause, flush a consistent state and do the snapshot, but the snapshot takes less than a second to do, so such a thing is probably fine. Also, if you need to stop the database for a consistent snapshot, then your database is not ACID compliant.