（v5.0.1 迁移）文档版本恢复

如果您从未运行过 Server Pro 版本 5.0.1 或 Community Edition 版本 5.0.1，或者您使用 5.0.1 启动了全新的实例，则无需运行此恢复过程。

本页更新：

• (2024-04-22 13:40 BST)：添加步骤“阻止新更新进入系统并将所有更改刷新到 MongoDB”。

• (2024-04-23 11:45 BST)：考虑到 5.0.1 中的刷新损坏，并在启动 5.0.2 时跳过刷新。

恢复所需的时间取决于您实例中项目的数量和大小，以及历史存储用于分片的后端存储（如在 OVERLEAF_HISTORY_CHUNKS_BUCKET).

恢复过程将在 Server Pro 容器内延迟应用启动。在此期间网站将显示为离线。我们仅支持从单个 Server Pro 容器实例运行恢复，所有其他水平扩展的工作节点需要下线。

如有需要，您可以停止并恢复恢复过程。

根据我们的性能测试，恢复过程在现代硬件（3GHz CPU 时钟速度和本地 NVMe 存储）上大约每分钟可处理 1 万个小项目。举例来说，对于拥有 10 万个项目的实例，请安排至少 10+2 分钟停机时间的维护窗口。使用以下查询估算实例中的项目数量：

$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'

请在开始之前完整阅读以下恢复步骤。Server Pro 客户如有任何问题，欢迎联系 [email protected] 提出任何问题。

恢复过程

1

拉取发布镜像

拉取 5.0.3 发布镜像。

2

识别一些项目

通过 id 识别一些缺少历史记录的项目；理想情况下您有权限对其中一个进行修改。

3

安排维护

为停机安排维护窗口。

4

停止除一个工作节点外的所有节点

在使用水平扩展设置时，停止除一个工作节点外的所有节点。

5

阻止新更新并将所有更改刷新到 MongoDB

阻止新更新进入系统并将所有更改刷新到 MongoDB：

1. 通过 https://my-server-pro.example.com/admin#open-close-editor 的管理面板在“打开/关闭编辑器”选项卡上手动关闭编辑器并断开所有用户连接。

2. 停止 Websocket/实时服务。

   $ docker exec sharelatex sv stop real-time-overleaf

3. 等待实时服务退出，如下所示 down：.

   $ docker exec sharelatex sv status real-time-overleaf
   run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
   # 再等一会儿……
   
   $ docker exec sharelatex sv status real-time-overleaf
   down: real-time-sharelatex: 7s, normally up

4. 如果启用了 git-bridge，则停止 git-bridge 容器。

   $ docker stop git-bridge

5. 如果您从未运行过 5.0.2：为文档更新发起手动刷新并等待其成功完成。

   您可以在出错时重复该命令。如果在连续运行中看到非零 failureCount ，请停止迁移（通过 docker restart git-bridge sharelatex）恢复服务并联系支持。

   $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /etc/overleaf/env.sh && cd services/document-updater && LOG_LEVEL=info node scripts/flush_all.js'
   ...
   {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"finished flushing all projects","time":"...","v":0}
   已完成刷新所有项目

6. 如果您从未运行过 5.0.2：确保所有更改已从 redis 中刷新出去。

   如果您从 redis-cli获得任何输出，请停止迁移（通过恢复服务 docker restart git-bridge sharelatex）恢复服务并联系支持。

   $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # redis-cli 无输出表示成功，接下来检查 redis-cli 的退出码，应该为零
   $ echo $?
   0

7. 尝试刷新任何待处理的历史更改。

   这需要尽最大努力刷新，因为一些项目由于错误的数据库迁移而导致历史记录损坏。任何失败将在恢复过程结束时通过重新同步历史来处理。

   $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /

6

进行备份

考虑对实例进行 一致的备份 的备份。

7

升级

升级到版本 5.0.3.

8

自动恢复

恢复过程在容器启动时会自动运行。

9

跟踪进度

您可以通过尾随日志文件来跟踪脚本进度 /var/lib/overleaf/data/history/doc-version-recovery.log。它将在开始时打印项目总数，并在每处理 1000 个项目后打印摘要。

$ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers

10

等待恢复过程完成

通过尾随上述日志文件直到打印出 Done. 行，或等待打印出 Finished recovery of doc versions. 到 Server Pro 容器的标准输出，来等待恢复过程完成。

11

验证恢复过程

通过打开之前缺少历史记录的几个项目的历史面板来验证恢复过程。

1. 加快需要测试的项目的重新同步（它们最终会被处理，但我们不想等待轮到它们）。

   $ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"

   （对要测试的每个项目 id 重复， 每次替换为一个项目 id。） 000000000000000000000000 替换为单个项目 id。）

2. 为这些项目打开项目编辑器 https://my-server-pro.example.com/project/000000000000000000000000

3. 打开项目的“历史”面板并查看最新内容。

4. 可选：再次关闭“历史”面板。进行一次代码更改，例如在页眉添加注释。

5. 可选：发起重新编译以触发本地更改的刷新。再次打开“历史”面板并查看更改。完成后撤销该更改。

12

对于水平扩展……

重新启动其他工作节点。

13

保持实例运行

请保持执行恢复过程的实例运行。它将在后台以并发数为 1 的方式为所有项目重新同步历史记录。这将导致基础负载略有上升。（您可以重启该实例，但它将需要从头开始重新同步。）

14

完成后请告知我们

Server Pro 客户：完成恢复过程后，请告知支持团队。