（v5.0.1 遷移）文件版本復原

如果您從未執行過 Server Pro 5.0.1 版或 Community Edition 5.0.1 版，或您是以 5.0.1 版全新啟動的執行個體，則不需要執行此復原流程。

• （2024-04-22 13:40 BST）：新增步驟「停止新的更新進入系統，並將所有變更排清（flush）至 MongoDB」。
• （2024-04-23 11:45 BST）：考量 5.0.1 中排清失敗的情況，並在已啟動 5.0.2 時略過排清。

復原所需時間取決於您執行個體中專案的數量與大小，以及歷程記錄儲存區用於區塊（chunks）的儲存後端（由 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 客戶如有任何問題，非常歡迎聯絡 [e-mail]。

​

復原流程

1. 拉取發行版映像檔

   拉取 5.0.3 發行版映像檔。

2. 找出幾個專案

   依 ID 找出幾個缺少歷程記錄的專案；最好是您有權限修改的專案。

3. 安排維護時段

   為停機時間安排維護時段。

4. 停止所有工作節點，僅保留一個

   若使用水平擴展架構，請停止所有工作節點，僅保留一個。

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. 等待即時服務結束，以 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. 若使用水平擴展……

    重新啟動其他工作節點。

13. 保持執行個體運作

    請保持執行復原流程的執行個體持續運作。它會在背景以並行數 1 重新同步所有專案的歷程記錄。這會導致基本負載略微升高。（您可以重新啟動執行個體，但重新同步將需要從頭開始。）

14. 完成後請通知我們

    Server Pro 客戶：完成復原流程後，請通知支援團隊。