> 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/ja/sapto/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 が起動された場合はフラッシュをスキップ。

復旧にかかる時間は、インスタンス内のプロジェクト数とサイズ、および履歴ストアがチャンクに使用するストレージバックエンド（で定義される）に依存します `OVERLEAF_HISTORY_CHUNKS_BUCKET`).

復旧プロセスは、Server Pro コンテナ内でのアプリケーション起動を遅らせます。その間、サイトはオフラインのように見えます。復旧の実行は Server Pro コンテナの単一インスタンスからのみサポートされており、他のすべての水平スケーリングワーカーはオフラインである必要があります。

必要に応じて、復旧プロセスを停止して再開できます。

当社の性能テストでは、現代的なハードウェア（3GHz CPU クロック速度とローカル NVMe ストレージ）上で、復旧プロセスは 1 分あたり約 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 でいくつかのプロジェクトを特定します。できれば、そのうち1件に変更を加える権限があると理想的です。
{% endstep %}

{% step %}

#### メンテナンスを計画する

ダウンタイムのためのメンテナンス時間帯を計画してください。
{% endstep %}

{% step %}

#### 1 つのワーカーを除いてすべて停止する

水平スケーリング構成を使用している場合は、1 つのワーカーを除いてすべて停止してください。
{% endstep %}

{% step %}

#### 新しい更新を止め、すべての変更を MongoDB にフラッシュする

新しい更新がシステムに入るのを止め、すべての変更を MongoDB にフラッシュします:

1. エディタを閉じ、管理パネルで手動で全ユーザーを切断します。 `https://my-server-pro.example.com/admin#open-close-editor` 「エディタを開く/閉じる」タブで。
2. Websocket/リアルタイムサービスを停止する。

   ```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`でサービスを復元し）、サポートに連絡してください。

   <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`でサービスを復元し）、サポートに連絡してください。

   <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 について繰り返し、 `000000000000000000000000` 一度に1つの 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/ja/sapto/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.