使用永久磁盘时

Question

我正在尝试为我在Google Compute Engine上运行的PostgreSQL实例设置每日备份（使用永久磁盘快照），其数据目录位于永久磁盘上。

现在，根据Persistent Disk Backups博文，我应该：

• 停止我的应用程序（PostgreSQL）
• fsfreeze我的文件系统，以防止进一步修改并将待处理的块刷新到磁盘
• 获取永久磁盘快照
• 解冻我的文件系统
• 启动我的应用程序（PostgreSQL）

这显然会带来一些停机时间（我的测试中的每个步骤从几秒到几分钟），我想避免或至少最小化。

博客帖子的步骤被标记为必要，以确保快照一致（我假设在文件系统级别），但我对干净的文件系统不感兴趣，我有兴趣能够恢复从这样的快照中我的PostgreSQL实例中的所有数据。

提交时

PostgreSQL uses fsync，所以PostgreSQL确认为已提交的所有数据已经​​进入磁盘（fsync goes to the disk）。

出于本次讨论的目的，我认为有必要比较永久磁盘快照不用停止PostgreSQL和不带使用fsfreeze和文件系统刚刚遇到意外断电的磁盘。

在阅读https://wiki.postgresql.org/wiki/Corruption和http://www.postgresql.org/docs/current/static/wal-reliability.html之后，我的理解是所有提交的数据都应该在意外停电时继续存在。

我的问题是：

1. 我对意外停电的比较是准确还是我遗漏了什么？

2. 我是否可以在不停止PostgreSQL且不使用fsfreeze的情况下拍摄快照，或者我是否遗漏了一些副作用？

3. 如果上面的答案是我不应该只拍摄快照，那么创建另一个永久磁盘是不是惯用的，定期使用pg_dumpall(1)转储整个数据库，然后快照其他永久磁盘？

Answer 1

1）是的，虽然拍摄快照应该更安全。 fsfreeze的东西真的是100％安全（有趣的是：我从来没有在我的PD上使用fsfreeze而且没有遇到问题）

2）是的，但没有100％保证它将始终有效（偏执解决方案：拍摄快照，使用该快照启动临时虚拟机，检查磁盘是否正常，并删除虚拟机。这可以是自动化）

3）不，我不会在快照上推荐这个。这将花费更多的时间，可能会降低您的数据库性能，如果在转储过程中发生了什么，会发生什么？此外，PD对于增量备份来说非常昂贵。快照是差异化的，因此您不必为每个副本（只是第一个）付费，只需更改。

可能的建议：

执行＃3，然后创建新PD的快照，然后删除PD。

Answer 2

https://cloud.google.com/compute/docs/disks/persistent-disks#creating_snapshots最近已更新，现在包含以下新段落：

  

如果跳过此步骤，则只有应用程序成功flushed to disk的数据才会包含在快照中。该应用程序遇到这种情况，好像是突然停电一样。

所以我原来问题的答案是：

1. 是
2. 是
3. N / A，因为对②的答案是肯定的。