(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 고객은 질문이 있으면 언제든지 [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:으로 표시될 때까지 real-time 서비스가 종료되기를 기다립니다.

      $ 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가 0이 아닌 값으로 나타나면, 마이그레이션을 중지하고(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. 진행 상황 확인하기

   로그 파일 /var/lib/overleaf/data/history/doc-version-recovery.log를 tail하여 스크립트의 진행 상황을 확인할 수 있습니다. 시작 시 전체 프로젝트 수를 출력하고, 프로젝트 1000개를 처리할 때마다 요약을 출력합니다.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. 복구 과정이 끝날 때까지 기다리기

    위 로그 파일에 Done. 줄이 출력될 때까지 tail하거나, 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"
           
       

       (테스트할 각 project-id에 대해 반복하며, 000000000000000000000000을 한 번에 하나의 project-id로 바꾸세요.)

    2. 프로젝트의 편집기 https://my-server-pro.example.com/project/000000000000000000000000을 엽니다.

    3. 프로젝트의 “History” 창을 열고 최신 콘텐츠를 확인합니다.

    4. 선택 사항: “History” 창을 다시 닫습니다. 헤더에 주석을 추가하는 등 코드를 변경합니다.

    5. 선택 사항: 다시 컴파일하여 로컬 변경 사항의 플러시를 트리거합니다. “History” 창을 다시 열어 변경 사항을 확인합니다. 완료되면 변경 사항을 되돌립니다.

12. 수평 확장의 경우...

    다른 워커를 다시 시작합니다.

13. 인스턴스를 계속 실행하기

    복구 과정을 실행한 인스턴스를 계속 실행 상태로 유지하세요. 이 인스턴스는 백그라운드에서 동시성 1로 모든 프로젝트의 히스토리를 재동기화합니다. 이로 인해 기본 부하가 약간 높아집니다. (인스턴스를 재시작할 수는 있지만, 재동기화를 처음부터 다시 시작해야 합니다.)

14. 완료되면 알려주세요

    Server Pro 고객: 복구 과정을 완료하면 지원팀에 알려주세요.