备份顺序

重要的是，参与者的备份不能比Sequencer的备份更新，因为这将构成账本分叉。因此，如果您按顺序备份参与者、Mediator和排序者数据库，则适用以下限制：

• 在Sequencer之前备份调解者和参与者；否则，他们可能无法重新连接到Sequencer (ForkHappened)。调解者和参与者的相对顺序并不重要。

如果您通过一步执行完整的系统备份（例如，使用云 RDS），请确保备份过程中没有任何组件写入数据库。

在从备份恢复同步器的情况下，如果参与者领先于同步器，则参与者将拒绝连接到同步器 (ForkHappened)，并且您必须：

• 将参与者的状态恢复到同步器发生灾难之前的备份，或者
• 推出新的同步器作为修复策略，以便从丢失的同步器中恢复

与参与者的 Ledger API 交互的应用程序的状态必须在参与者之前备份，否则必须重置应用程序状态。

恢复警告

从备份恢复 Canton 节点时，由于备份点和节点最新状态之间的数据丢失，以下注意事项适用。

不完整的命令重复数据删除状态

恢复后，参与者的正在进行的提交跟踪将与备份后参与者发送到Sequencer的内容不同步。如果应用程序重新提交重复的命令，即使参与者应已删除重复命令，它也可能会被接受。

在以下情况下，此跟踪将再次同步：

• 参与者已处理来自Sequencer的所有事件，并且
• Sequencer上的队列不包含可再次排序的恢复之前的传输/交易请求的任何提交请求

此类提交请求的最大排序时间为账本时间加上同步器的账本时间记录时间容差。从同步器观察时间戳应该足够了，该时间戳是在参与者在恢复之前停止的时间超过容差的时间之后的。一旦观察到这样的时间戳，正在进行的提交跟踪将再次同步，并且应用程序可以恢复提交具有完整命令重复数据删除保证的命令。

应用程序状态重置

从备份恢复后的 Ledger API 事件流可能与备份和恢复之间的事件流存在以下差异：

• 分配的账本偏移量可能会有所不同。

• 完成流上的拒绝可能会丢失。作为参与者节点的 Ledger API 客户端的所有应用程序都必须处理这些差异：

• 无状态应用程序不受影响。

• 如果可能，应将有状态应用程序重置为备份时或之前的状态，以便应用程序可以根据新流重新处理更新。如果重置不可行，则应用程序必须跳过已处理的更改。为此，应用程序可以存储每个同步器所有摄取更改的记录时间，并跳过其同步器记录时间较低的事务。

私钥

假设一个场景，节点需要轮换其加密私钥，该私钥当前存储在节点的数据库中。如果在执行备份之前已在系统中宣布密钥轮换，则新密钥在恢复时将不可用，但系统中的所有其他节点都希望使用新密钥。

为了避免这种情况，请按以下顺序执行关键轮换步骤：

1. 生成新的私钥并存储到数据库中 2、备份数据库
2. 备份完成后，撤销之前的密钥

当密钥存储在 KMS 中时，情况会更简单，因为参与者只需将密钥的 ID 存储在其数据库中即可。从备份恢复参与者后，必须使用命令 keys.secret.register_kms_encryption_key 或 keys.secret.register_kms_signing_key 注册自备份以来创建的所有密钥。

本地配置

从备份恢复会将节点的本地配置重置为进行备份时的状态。本地配置包括以下几个方面：

• 同步器连接配置
• 用户管理
• DAR上传
• 维修
• Party 复制

恢复后，操作员必须重复完全相同的配置更改。因此，操作员应在每次配置更改后执行备份，以免重复更改。

Postgres 示例

如果您使用 Postgres 来保存参与者节点或同步器数据，您可以创建备份到文件并使用 Postgres 的实用命令 pg_dump 和 pg_restore 恢复它，如下所示：

将 Postgres 数据库备份到文件：

pg_dump -U <user> -h <host> -p <port> -w -F tar -f <fileName> <dbName>

从文件恢复 Postgres 数据库数据：

pg_restore -U <user> -h <host> -p <port> -w -d <dbName> <fileName>

尽管上面显示的方法适用于小型部署，但不建议用于大型部署。为此，我们建议研究增量备份并参考以下资源：

• PostgreSQL 文档：备份和恢复
• 增量备份在 PostgreSQL 中如何工作

用于灾难恢复的数据库复制

同步复制我们建议在生产中至少同步器应该使用异地同步复制来运行，以确保同步器的状态始终比参与者的状态更新。然而，为了避免与备份恢复类似的警告，参与者也应该使用同步复制，或者作为手动灾难恢复故障过程的一部分，必须解决这些警告。

数据库备份允许您将分类帐恢复到创建上次备份时的位置。但是，在发生灾难时，创建备份后接受的任何命令都可能会丢失。因此，恢复备份可能会导致数据丢失。

如果此类数据丢失是不可接受的，您需要针对复制数据库运行 Canton，该数据库将其状态复制到另一个站点。如果原始站点因灾难而关闭，Canton 可以根据数据库中的复制状态在另一个站点上启动。至关重要的是，原始站点中没有写入者留在数据库中，因为 Canton 中使用的数据库机制无法跨站点使用以避免多个写入器从而避免数据损坏。

有关如何设置复制数据库以及如何执行故障转移的详细说明，我们参考数据库系统文档，例如PostgreSQL 的高可用性文档。

强烈建议将复制配置为同步。 这意味着，只有在将数据库事务持久化到所有数据库副本后，数据库才应将其报告为已成功提交。在 PostgreSQL 中，这对应于设置 synchronous_commit = on。如果您不遵循此建议，您可能会在数据库故障转移后发现数据丢失和/或损坏状态。启用同步复制可能会影响 Canton 的性能，具体取决于主数据库和异地数据库之间的网络延迟。

对于 PostgreSQL，Canton 努力验证数据库复制配置，如果检测到配置错误，则会失败并显示错误。然而，这种验证是尽力而为的；因此它可能无法检测到不正确的复制配置。对于 Oracle，不会尝试验证数据库配置。总的来说，您不应该依赖 Canton 来检测数据库配置中的错误。

---

本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。