XtraBackup works great for backing MySQL up to an NFS volume, but there is a gotcha that you need to be aware of. This applies to anything you do with NFS, not just XtraBackup. The gotcha is that NFS uses client-side caching to reduce overhead of sending data across the network.
If you backup to an NFS mount from your database server, and then use a different server that also mounts that volume to prepare the backup (apply the logs), that other server might not have a consistent view of the data. That’s because the data might not be flushed to the NFS server yet — it might just be sitting in the database server’s cache.
If this happens, xtrabackup will potentially see corrupt or inconsistent data. And InnoDB does not tolerate that. It will refuse to work, which is a good thing. The preparation step will fail. This is one reason why you should always prepare your backups so they are completely ready to use. (You should test your backups even more than that — we’ve blogged before about that. Let us know if you want help with that.)
You can solve this by mounting NFS synchronously on the database host. This is slower for general-purpose usage, but it should not be a big deal for xtrabackup. This and lots of other details about xtrabackup are documented on the XtraBackup docs.
Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.
Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below.