（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 时跳过刷写。

恢复所需的时间取决于实例中项目的数量和大小，以及历史存储用于存放 chunk 的存储后端（由 OVERLEAF_HISTORY_CHUNKS_BUCKET 定义）。

恢复流程会延迟 Server Pro 容器内应用的启动，在此期间站点会显示为离线。我们仅支持在单个 Server Pro 容器实例上运行恢复，其他所有水平扩展的 worker 都需要处于离线状态。

如有需要，你可以停止并继续恢复流程。

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

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

开始之前，请完整阅读以下恢复步骤。Server Pro 客户如有任何问题，非常欢迎联系 [e-mail]。

​

恢复流程

1. 拉取发布镜像

   拉取 5.0.3 发布镜像。

2. 确定几个项目

   通过 ID 确定几个缺失历史记录的项目；最好你有权限修改其中一个项目。

3. 安排维护

   为停机安排一个维护窗口。

4. 仅保留一个 worker

   如果使用水平扩展部署，请停止除一个 worker 之外的所有 worker。

5. 阻止新的更新并将所有更改刷写到 MongoDB

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

   1. 通过 https://my-server-pro.example.com/admin#open-close-editor 上管理面板的“Open/Close Editor”标签页，关闭编辑器并手动断开所有用户的连接。

   2. 停止 Websocket/real-time 服务。

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. 等待 real-time 服务退出，以 down: 为标志。

      $ docker exec sharelatex sv status real-time-overleaf
      run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
      # wait a little longer...
      
      $ docker exec sharelatex sv status real-time-overleaf
      down: real-time-sharelatex: 7s, normally up
      

   4. 如果启用了 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}
          Done flushing all projects
          
      

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

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

      $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
          # no output from redis-cli indicates success, check exit code of redis-cli next, it should be zero
          $ echo $?
          0
          
      

   7. 尝试刷写所有待处理的历史更改。

      这只能是尽力而为的刷写，因为部分项目的历史记录已因错误的数据库迁移而损坏。任何失败都将在恢复流程结束时通过重新同步历史记录来解决。

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. 进行备份

   建议对实例进行一次一致性备份。

7. 升级

   升级到 5.0.3 版本。

8. 自动恢复

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

9. 跟踪进度

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

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. 等待恢复流程完成

    等待恢复流程完成：可以持续 tail 上述日志文件，直到打印出 Done. 行；或者等待 Server Pro 容器的标准输出中打印出 Finished recovery of doc versions.。

11. 验证恢复流程

    打开几个之前缺失历史记录的项目的历史面板，以验证恢复流程。

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

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

       （对每个要测试的项目 ID 重复执行，每次将 000000000000000000000000 替换为一个项目 ID。）

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

    3. 打开项目的“History”面板，查看最新内容。

    4. 可选：再次关闭“History”面板。进行一处代码修改，例如在文件头部添加一条注释。

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

12. 对于水平扩展部署……

    重新启动其他 worker。

13. 保持实例运行

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

14. 完成后通知我们

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