用于快照一致性备份的存储快照-不同的数据和日志卷

我们正在vmware /共享存储环境中运行许多Linux VM，每个Linux VM都运行自己的postgreSQL实例（混合使用9.0和9.3）。当前，整个VM都位于单个根分区/卷上，使用基础VMFS卷的基于存储的快照进行备份/还原过程（以及复制到我们的DR站点），我们已经取得了巨大的成功（〜8年）。

由于我们的存储体系结构，将postgres WAL文件分离到一个非缓存的（主要是写入的）卷中会比较有利，这样可以减少我们在存储方面的缓存混乱。使用我们的存储（Nimble Storage），我们可以将两个卷都分配到一个保护/快照组，但是我无法从供应商处得出快照将在保护组中的所有卷上完全同时发生-可能会，但是总是有相隔毫秒的机会。

为此，我们进行了一些实验，所有实验都使用pg_bench尽可能快地将数据写入数据库。实验之后，我们恢复了快照的卷并启动了VM + postgres

• 快照数据和日志卷同时接近-结果：数据库已恢复
• 首先快照数据量，约1分钟后日志量-结果：数据库已恢复
• 首先是快照日志卷，之后是约1分钟的数据卷-结果：数据库已恢复
• 在WAL检查点将新数据写入数据文件之后，快照日志卷首先出现，数据量在大约3分钟后出现：结果：数据库已恢复

因此，测试似乎告诉我们，只要两个快照在卷级别上是一致的，并且相对紧密，就可以基于WAL / Log卷快照的时间获得数据库的一致副本。

我的问题：这样安全吗？我们在测试中缺少哪些极端情况？可能出什么问题？

Postgres的文档表明这样做并不安全，但是测试似乎表明它非常健壮：http : //www.postgresql.org/docs/9.1/static/backup-file.html

如果您的数据库分布在多个文件系统中，则可能没有任何方法可以获取所有卷的完全同步的冻结快照。例如，如果数据文件和WAL日志位于不同的磁盘上，或者表空间位于不同的文件系统上，则由于快照必须同时进行，因此可能无法使用快照备份。在这种情况下，请务必仔细阅读文件系统文档，然后再使用一致快照技术。

注意：是的，我们知道其他确保其一致性的选项，例如将PostgreSQL置于热备份模式或使用我们存储的VMware集成来静默VM本身，但是我们正在寻找一种仅存储的解决方案以提高速度，便利性，对客户的影响为零。

您引用的文档说明了所有内容，但是如果您想尝试验证供应商有关同时拍摄快照的声明，我不会怪您。揭示问题的一种方法可能是对WAL系统进行更具体的压力测试。

例如，除了基于pgbench的测试外，尝试添加随机调用以pg_switch_xlog()强制日志轮换，缩短和延长检查点间隔（缩短和延长checkpoint_timeoutand checkpoint_timeout），甚至使用小或大的wal文件大小。

除非我缺少某些东西，否则由于无法同时拍摄快照，我可能会将恢复的数据库归因于一些幸运的时机。在最后一种情况下，假设您在当前xlog位置为时拍摄了日志快照0/A1C0FFEE。然后，您在系统上有3分钟特别重的负载，这将导致遍历WAL文件的整个周期，并且此时数据库已处于0/DEADBEEF获取数据快照的状态。当您尝试还原时，在数据快照时写入的WAL文件已久，恢复将失败。