Products.TIDStorage 5.5.0

概要

此产品提供了一种在运行多存储实例时进行一致性备份的方法（目前仅支持ZEO）。

当涉及多个存储的事务时，对同一实例中的单个Data.fs（一个挂载在另一个中的）进行备份是一个问题：如果在事务提交期间发生崩溃，则无法确定哪个存储已提交，哪个未提交（数据库之间没有TID一致性）。还有一个更复杂的情况。考虑以下

2 transactions running in parallel:
 T1: modifies storage A and B
 T2: modifies storage A
Commit order scenario:
 T1 starts committing (takes commit lock on A and B)
 T2 starts committing (waits for commit lock on A)
 T1 commits A (commit lock released on A)
 T2 commits A (takes & releases commit lock on A)
 [crash]
 T1 commits B (commit lock released on B) <- never happens because of crash

在这里，T2 可以完全提交，但不得保存。这是因为事务以提交的顺序存储在 ZODB 中。因此，如果 T2 在备份中，T1 的一部分也会在备份中，备份将不一致（T1 在 B 上的提交从未发生）。

用法

将产品放入 Zope 产品以激活 Zope 端补丁。

创建配置，示例在 repozo/sample_configuration.py 中提供

使用创建的配置运行 bin/tidstorage.py。当 Zope 提交事务时，它将连接到 TIDStorage 服务器，这将在 Zope 和 TIDStorage 服务器日志中显示。

<product-config TIDStorage>
  backend-ip ip-of-tidstorage-server
  backend-port port-of-tidstorage-server
</product-config>

技术细节

TIDStorage 通过跟踪所有参与任何事务的存储（通过 ZEO 的 ZODB）的事务到 TID 关系以及跟踪事务间的依赖关系来解决这些问题。

TIDStorage 由 3 部分组成

• 一个 Zope 产品，它是对“ZEO”和“transaction”产品的 monkey-patch。

  事务补丁

  TIDStorage 在事务边界上工作，因此我们钩住 _commitResource 方法以知道何时发生。它必须配置以适应您的网络设置（TID_STORAGE_ADDRESS）

  ZEO 补丁

  在常规 ZEO 中，没有方法知道事务代码级别的最后一个已提交的 TID。此补丁将最后一个已提交的 TID 存储在 ZEO 连接对象上，以便由事务补丁读取。

• 一个守护进程 这实际上是 TIDStorage 本身，从 Zopes 接收 TID 并将一致性点传递给备份脚本。

• 备份脚本和其他实用工具 这些脚本主要是 repozo 备份脚本的包装，从 TIDStorage 守护进程获取一致性点并调用 repozo。不需要修改 repozo.py，因为它仅用作子系统以执行可靠的备份和恢复。使用提供的 utils 目录中的实用工具，可以查询服务器上最后已知的 TID 并对 TIDStorage 日志进行操作。

TIDStorage 设计时所受的限制

• 设计 Zope 性能协议（见下文）时作为单向（Zope 将数据推送到 TIDStorage，并不需要回答），这样 TIDStorage 的速度就不会限制 Zope 的性能。

• 没有增加单点故障 即使 Zope 无法连接到 TIDStorage，它仍然可以工作。如果连接丢失或第一次尝试失败，它只会发出一条日志行。当连接建立时，还会发出一条日志行。

• 作为TIDStorage的Bootstrap可以在ZODBs上运行时启动和停止，它必须在任何备份发生之前能够引导其内容。这是通过创建人工的Zope事务来完成的，这些事务的唯一目的是在每个ZODB上触发提交，填充TIDStorage并确保任何存储上都没有挂起的提交（由于这些事务可能占用所有锁，这意味着所有在TIDStorage之前开始的事务都已经结束并接收到了通知）。

• 从Data.fs恢复 除了能够从repozo风格的备份中恢复之外，为了提供比repozo在大数据库上能提供的更频繁的备份，TIDStorage提供了从崩溃的Data.fs中恢复一致性的可能性——只要它们没有被损坏。

限制

• 恢复“延迟”由于TIDStorage只能在独立事务全部完成（提交或中止）时提供一致性点，因此TIDStorage日志文件备份从时间T可能实际上包含在T时间之前的时刻的数据。因此，在用-t选项进行恢复时，数据将被切割到T时间-未定义的状态，存在小的延迟。

  甚至存在无法找到一致性点的病理情况，因此TIDStorage日志文件将没有任何信息。

守护进程信号支持

• HUP重新打开所有日志文件

• USR1将tid配置转储到日志文件

• TERM杀死守护进程

协议规范

在数据中允许所有字符，除了n和r（0x0A & 0x0D）。每个字段以n结尾，r被忽略。没有转义。在传输列表时，它由包含的字段数开头。示例

3\n
foo\n
bar\n
baz\n

在传输字典时，它由项目数开头，然后是键，然后是值。值必须是作为字符串表示的整数。示例

2\n
key1\n
key2\n
1\n
2\n

命令不区分大小写。

1. 提交命令的开始

BEGINn <commit id>n <涉及存储列表>

<commit id>：必须与提交完成时给出的ID相同（无论是ABORT还是COMMIT）<涉及存储列表>：涉及事务的存储ID列表 NB：最后的n是列表表示的一部分，因此在上文中没有显示。

响应：（无内容）

2. 事务中止命令

ABORTn <commit id>n

<commit id>：（参见BEGIN）

响应：（无内容）

3. 事务最终化命令

COMMITn <commit id>n <涉及存储和提交TID的字典>

<commit id>：（参见BEGIN）涉及的存储：（参见BEGIN）提交的TID：每个存储的TID，作为整数。NB：最后的n是列表表示的一部分，因此在上文中没有显示。

响应：（无内容）

4. 数据读取命令

DUMPn

响应：<存储和TID的字典>

5. 连接终止命令

QUITn

响应：（无内容，服务器关闭连接）

6. 引导状态命令

BOOTSTRAPEDn

响应：如果是完全完成的引导则为1，否则为0。

5.5.0 (2019-06-21)

• 不要依赖于Medusa HTTP服务器。这需要ERP5 > 2018-04-26（提交6d74ba22a962d08624ef35342708f333a21ceff5）。

5.4.9 (2013-09-12)

• 仅保留最近repozoby保存的最新索引文件

5.4.8 (2012-07-31)

• 删除base_url参数 [Romain Courteaud]

• 添加缺少的__init__.py文件 [Romain Courteaud]

5.4.7 (2012-07-30)

• 删除与Zope的循环依赖关系 [Romain Courteaud]

• <product-config tidstorage>部分在zope.conf中受支持 [Łukasz Nowak]

• 始终写入pidfile，即使不是为了进行分叉 [Łukasz Nowak]