我考虑将应用程序部署到Heroku以及Postres标准数据库计划。我热衷于确保数据完整性，并确保在数据库损坏或其他类似问题时，我的客户数据不会丢失。我也希望确保平稳的恢复过程。所以我有以下问题：
首先，我在Continuos中假设还有可能 数据库可能会损坏。这是真的？
什么提供了更多 如果数据库成为完整性，保护和易于恢复 损坏：标准DB /带有连续保护或标准DB 跟随者DB。
我很想听听你对此的看法。我过去的经验是用MySQL而不是Postgres，我听说过很棒的东西。
由于
答案 0 :(得分：5)
警告：我对Postgresql有一些经验，但我对Heroku没有任何经验。
Heroku所谓的“持续保护”＃39;和＆＃39;追随者＆＃39;数据库使用Postgresql的Continuous Archiving和streaming replication功能实现。他们围绕这些功能提供了一系列管理工具和基础设施，使其更易于使用。
这两个函数都利用了Postgresql在预写日志（WAL）中将所有更新写入数据库的事实。
使用Continuous Archiving，可以获取数据库中所有底层文件的完整副本 - 这称为基本备份。还可以在生成基本备份期间和之后收集数据库生成的所有WAL文件。请注意，您不需要停止数据库以进行基本备份 - 这是一个相当不引人注意的过程。
如果最糟糕的情况发生，并且有必要从备份恢复数据库，则只需恢复基本转储，配置数据库以便知道在哪里可以找到存档的WAL文件，然后启动它。然后它将按顺序重放WAL文件，直到它完全是最新的。
请注意，您也可以提前停止重播。这可能非常有用，您将在我对第一个问题的回答中看到：
- 首先，我与Continuos一起假设仍有可能 数据库可能会损坏。这是真的吗？
是的，当然。数据库损坏可能由于多种原因而发生：硬件故障，数据库中的软件故障，应用程序中的故障，甚至是操作员错误。
连续归档的一个好处是，您可以在特定时间点重播WAL文件，这样您就可以有效地回退到数据库损坏之前的那一刻。
如上所述，Follower DB使用Postgresql＆＃39; Streaming Replication＆＃39;功能。使用此功能，可以将基本备份还原到另一台服务器，将其配置为连接到主数据库，并在生成时实时获取WAL文件。随后，关注者随时了解对主人所做的任何更改。
- 如果是的话，Whats可以提供更多的完整性，保护和恢复 数据库损坏：标准DB /带Continuos保护或 带有从动DB的标准DB。
易于恢复是不同的。
如果你有一个Follower DB，它是一个热备用 - 如果master由于某种原因失败，你可以将应用程序切换到跟随者，停机时间最短。另一方面，如果你有一个大型数据库，你必须从最后一个基本备份恢复它，然后重放所有生成的WAL文件 - 这可能需要很长时间，即使它是一个非常大的数据库。
但是，请注意，如果您的数据库因例如管理员意外删除了错误的表而导致数据库损坏，那么关注者DB将毫无用处。几秒钟后，该表将在跟随者中删除。他们就像穿越悬崖的旅鼠。如果您的应用程序由于错误，黑客或其他原因而破坏数据库，则同样适用。即使使用关注者，您也必须有适当的备份，连续存档或普通的pg_dump。
- 如果数据库被破坏，或数据库完整性问题 出现，Heroku将如何修复（鉴于数据库是＆＃34;管理＆＃34; 服务）。是自动还是我必须手动使用支持 补救？
他们的documentation表示高级计划确实具有自动故障转移功能。如果发生硬件或平台故障以及大多数类型的数据库故障，系统可以检测到主数据库已关闭并启动故障转移，这将非常有用。
如果数据库被应用程序本身（或仓促管理员）损坏，那么我怀疑您必须手动启动故障转移。