> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/ko/support/support-guides/doc-version-recovery.md).

# (v5.0.1 마이그레이션) 문서 버전 복구

{% hint style="info" %}
Server Pro 버전 5.0.1 또는 Community Edition 버전 5.0.1을 한 번도 실행한 적이 없거나, 5.0.1로 새 인스턴스를 시작했다면 이 복구 프로세스를 실행할 필요가 없습니다.
{% endhint %}

**이 페이지의 업데이트:**

* (2024-04-22 13:40 BST): 단계 "시스템에 새 업데이트가 들어오는 것을 중지하고 모든 변경 사항을 MongoDB에 플러시"를 추가했습니다.
* (2024-04-23 11:45 BST): 5.0.1의 손상된 플러시를 고려하고, 5.0.2가 시작된 경우 플러시를 건너뜁니다.

복구에 걸리는 시간은 인스턴스의 프로젝트 수와 크기, 그리고 청크에 대한 history store에서 사용하는 저장 백엔드에 따라 달라집니다(정의는 `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

복구 프로세스는 Server Pro 컨테이너 내부의 애플리케이션 시작을 지연시킵니다. 그동안 사이트는 오프라인으로 표시됩니다. 복구는 Server Pro 컨테이너의 단일 인스턴스에서만 실행할 수 있으며, 다른 모든 수평 확장 작업자는 오프라인이어야 합니다.

필요한 경우 복구 프로세스를 중지하고 다시 시작할 수 있습니다.

성능 테스트에 따르면, 최신 하드웨어(3GHz CPU 클럭 속도와 로컬 NVMe 저장소)에서는 복구 프로세스가 분당 약 1만 개의 작은 프로젝트를 처리할 수 있습니다. 예를 들어 10만 개의 프로젝트가 있는 인스턴스라면 최소 10+2분의 다운타임을 허용하는 유지보수 창을 예약하세요. 다음 쿼리를 사용해 인스턴스의 프로젝트 수를 추정할 수 있습니다:

{% code overflow="wrap" %}

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

{% endcode %}

복구 단계를 시작하기 전에 아래 복구 절차를 끝까지 읽어 주세요. Server Pro 고객분들은 언제든지 <support@overleaf.com> 로 문의해 주셔도 됩니다.

### 복구 절차

{% stepper %}
{% step %}

#### 릴리스 이미지 가져오기

릴리스 이미지를 `5.0.3` 가져옵니다.
{% endstep %}

{% step %}

#### 몇 개의 프로젝트 식별

히스토리가 누락된 몇 개의 프로젝트를 ID로 식별합니다. 가능하다면 그중 하나를 수정할 권한이 있어야 합니다.
{% endstep %}

{% step %}

#### 유지보수 일정 잡기

다운타임을 위한 유지보수 창을 예약합니다.
{% endstep %}

{% step %}

#### 작업자 하나만 제외하고 모두 중지

수평 확장 구성을 사용할 때는 작업자 하나만 제외하고 모두 중지합니다.
{% endstep %}

{% step %}

#### 새 업데이트 중지 및 MongoDB에 모든 변경 사항 플러시

시스템에 새 업데이트가 들어오는 것을 중지하고 모든 변경 사항을 MongoDB에 플러시합니다:

1. 편집기를 닫고 다음의 관리 패널을 통해 모든 사용자의 연결을 수동으로 끊습니다: `https://my-server-pro.example.com/admin#open-close-editor` "편집기 열기/닫기" 탭에서.
2. 웹소켓/실시간 서비스를 중지합니다.

   ```bash
   $ docker exec sharelatex sv stop real-time-overleaf
   ```
3. 실시간 서비스가 종료될 때까지 기다립니다. 이는 다음에서 확인할 수 있습니다: `down:`.

   ```bash
   $ 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 컨테이너를 중지합니다.

   ```bash
   $ docker stop git-bridge
   ```
5. 5.0.2를 한 번도 실행하지 않았다면: 문서 업데이트에 대해 수동 플러시를 실행하고 성공적으로 완료될 때까지 기다립니다.

   오류가 나면 명령을 다시 실행할 수 있습니다. 연속된 실행에서 0이 아닌 `failureCount` 가 나타나면 마이그레이션을 중지하고(docker restart git-bridge sharelatex를 통해 서비스를 복원한 뒤) `docker restart git-bridge sharelatex`) 지원팀에 문의해 주세요.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /etc/overleaf/env.sh &#x26;&#x26; cd services/document-updater &#x26;&#x26; 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}
   모든 프로젝트 플러시 완료
   </code></pre>
6. 5.0.2를 한 번도 실행하지 않았다면: 모든 변경 사항이 redis에서 완전히 플러시되었는지 확인합니다.

   다음에서 출력이 나온다면 `redis-cli`, 마이그레이션을 중지하고(docker restart git-bridge sharelatex를 통해 서비스를 복원한 뒤) `docker restart git-bridge sharelatex`) 지원팀에 문의해 주세요.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # redis-cli에서 출력이 없으면 성공을 의미합니다. 다음으로 redis-cli의 종료 코드를 확인하세요. 0이어야 합니다.
   $ echo $?
   0
   </code></pre>
7. 보류 중인 모든 히스토리 변경 사항을 플러시해 보세요.

   잘못된 데이터베이스 마이그레이션으로 인해 일부 프로젝트의 히스토리가 손상되었으므로, 이 플러시는 최선을 다해 시도하는 수준이어야 합니다. 실패한 항목은 복구 프로세스 끝에서 히스토리 재동기화를 통해 해결됩니다.

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex bash -c 'source /etc/container_environment.sh &#x26;&#x26; source /
   </code></pre>

{% endstep %}

{% step %}

#### 백업 만들기

다음의 백업을 고려해 보세요 [일관된 백업](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) 인스턴스의.
{% endstep %}

{% step %}

#### 업그레이드

버전으로 업그레이드 `5.0.3`.
{% endstep %}

{% step %}

#### 자동 복구

복구 프로세스는 컨테이너 시작 시 자동으로 실행됩니다.
{% endstep %}

{% step %}

#### 진행 상황 확인

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

{% code overflow="wrap" %}

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

{% endcode %}
{% endstep %}

{% step %}

#### 복구 프로세스가 완료될 때까지 기다리기

아래 로그 파일을 tail 하여 다음이 출력될 때까지 기다리거나 `완료되었습니다.` 가 출력될 때까지 기다리거나 `doc 버전 복구 완료.` 가 Server Pro 컨테이너의 표준 출력에 출력될 때까지 기다립니다.
{% endstep %}

{% step %}

#### 복구 프로세스 검증

이전에 히스토리가 누락되었던 몇몇 프로젝트의 히스토리 패널을 열어 복구 프로세스를 검증합니다.

1. 테스트할 프로젝트의 재동기화를 앞당깁니다(어차피 나중에 처리되겠지만, 차례가 올 때까지 기다리고 싶지는 않습니다.)

   <pre class="language-bash" data-overflow="wrap"><code class="lang-bash">$ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
   </code></pre>

   (각 project-id마다 반복하고, replace `000000000000000000000000` 를 한 번에 하나의 project-id로 바꿔 넣으세요.)
2. 프로젝트들의 프로젝트 편집기를 엽니다 `https://my-server-pro.example.com/project/000000000000000000000000`
3. 프로젝트의 "히스토리" 패널을 열고 최신 내용을 확인합니다.
4. 선택 사항: "히스토리" 패널을 다시 닫습니다. 헤더에 주석을 추가하는 등의 코드 변경을 합니다.
5. 선택 사항: 다시 컴파일을 실행해 로컬 변경 사항의 플러시를 유도합니다. "히스토리" 패널을 다시 열어 변경 사항을 확인합니다. 완료되면 변경 사항을 되돌립니다.
   {% endstep %}

{% step %}

#### 수평 확장 시...

다른 작업자들을 다시 시작합니다.
{% endstep %}

{% step %}

#### 인스턴스를 계속 실행 상태로 유지

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

{% step %}

#### 완료되면 알려 주세요

Server Pro 고객: 복구 프로세스를 완료하면 지원팀에 알려 주세요.
{% endstep %}
{% endstepper %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ayakaleaf-pro.ayaka.space/on-premises/ko/support/support-guides/doc-version-recovery.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.