Actually with zfs and btrfs you can service mysql stop, put checkpoint back and bring it back up at roughly the same speed as AWS can do it.
I also have done enough recoveries to know that actually placing back a checkpoint is admitting defeat and stating that you
a) don't know what happened
b) don't have any way to fix it
And often it means
c) don't have any way to prevent it from reoccuring, potentially immediately.
It's a quick and direct action that often satisfies the call to action from above. It is exactly the wrong thing to do. It very rarely solves the issue.
Actually fixing things mostly means putting the checkpoint on another server, and going through a designed fix process.
Have you benchmarked the time it takes to bring up a ZFS based Mysql restore?
a) don't know what happened
b) don't have any way to fix it
And often it means
c) don't have any way to prevent it from reoccuring, potentially immediately.
Can you ensure the filesystem consistency when you restore with ZFS?
a) don't know what happened
b) don't have any way to fix it
And often it means
c) don't have any way to prevent it from reoccuring, potentially immediately.
In the example that was given in the parent post, we know what happened:
Someone inadvertently (hopefully) did
Delete * From table
You restore the table to the previous state and you take measures to prevent human error.
