(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 分間に 10k の小規模プロジェクトを処理できます。例として、100k プロジェクトのインスタンスでは、少なくとも 10+2 分のダウンタイムを許容するメンテナンスウィンドウを予定してください。インスタンス内のプロジェクト数を見積もるには次のクエリを使用します。

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

開始前に以下の復旧手順をよくお読みください。Server Pro のお客様はいつでも歓迎して以下にお問い合わせください。 [email protected] ご質問があれば。

復旧プロセス

1

リリースイメージを取得する

次の 5.0.3 リリースイメージを取得します。

2

いくつかのプロジェクトを特定する

履歴が欠落しているいくつかのプロジェクトを id によって特定してください。理想的にはそのうちの1つに変更を加える権限があることが望ましいです。

3

メンテナンスを予定する

ダウンタイムのためのメンテナンスウィンドウを予定してください。

4

1 つを残してすべてのワーカーを停止する

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

5

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

システムに新しい更新が入らないようにし、すべての変更を MongoDB にフラッシュしてください:

1. 管理パネルの https://my-server-pro.example.com/admin#open-close-editor の「Open/Close Editor」タブでエディタを閉じ、すべてのユーザーを手動で切断してください。

2. Websocket/リアルタイムサービスを停止します。

   $ 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
   # もう少し待つ...
   
   $ 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}
   すべてのプロジェクトのフラッシュが完了しました

6. もし 5.0.2 を一度も実行していない場合: すべての変更が redis からフラッシュされていることを確認してください。

   もし redis-cliから何か出力が得られる場合は、マイグレーションを停止してください（サービスを復元するには次を実行） docker restart git-bridge sharelatex）サポートに連絡してください。

   $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # redis-cli からの出力がないことは成功を示します。次に redis-cli の終了コードを確認してください。ゼロであるべきです
   $ 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。開始時に総プロジェクト数を出力し、処理された毎 1000 プロジェクトごとに要約を出力します。

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

10

復旧プロセスが終了するのを待つ

上記のログファイルを追跡して「 Done. 」という行が出力されるまで、または Finished recovery of doc versions. が Server Pro コンテナの標準出力に表示されるのを待って、復旧プロセスが完了するのを待ってください。

11

復旧プロセスを検証する

履歴が以前欠落していたいくつかのプロジェクトで履歴パネルを開き、復旧プロセスを検証してください。

1. テスト用のプロジェクトの再同期を迅速化する（最終的には処理されますが、順番を待ちたくない場合）

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

   （テストする各プロジェクト ID で繰り返してください。各実行ごとに 000000000000000000000000 を 1 つのプロジェクト ID に置き換えてください。）

2. 対象プロジェクトのエディタを開く https://my-server-pro.example.com/project/000000000000000000000000

3. プロジェクトの「History」パネルを開き、最新の内容を確認してください。

4. 任意: 「History」パネルを再度閉じます。ヘッダにコメントを追加するなどコードの変更を行ってください。

5. 任意: ローカル変更のフラッシュをトリガーするために再コンパイルを実行してください。再度「History」パネルを開き、変更を確認します。完了したら変更を元に戻してください。

12

水平スケーリングの場合...

他のワーカーを再起動します。

13

インスタンスを稼働させ続ける

復旧プロセスを実行したインスタンスを稼働し続けてください。バックグラウンドで同時実行数 1 で全プロジェクトの履歴を再同期します。これによりベースロードがやや上昇します。（インスタンスを再起動することはできますが、再同期は最初からやり直す必要があります。）

14

完了したらお知らせください

Server Pro のお客様: 復旧プロセスを完了したらサポートチームにお知らせください。