arrows-rotate(v3.5.13 マイグレーション) プロジェクト全履歴の移行

プロジェクト履歴の完全移行

その 3.5.x Community Edition のリリースには含まれています プロジェクト履歴の完全機能arrow-up-right これは既に当社の SaaS 提供で利用可能です、 overleaf.comarrow-up-right

インスタンスを Overleaf CE にアップグレードした後 3.5.13、すべての新規プロジェクトはデフォルトでプロジェクト履歴の完全機能を使用するようになります。既存のプロジェクトは移行されるまで従来の履歴システムを使い続けます。

circle-info

にアップグレードした場合 3.5.13 そして以前のバージョンにダウングレードすることを決めた場合は、フルシステムバックアップから復元する必要があります。で作成されたプロジェクトの履歴は 3.5.13 は Overleaf CE の以前のバージョンと互換性がありません。

新しいプロジェクト履歴の完全機能はユーザーにいくつかの改善をもたらします:

  • バイナリファイルの変更を追跡します。これは従来のシステムではサポートされていません。

  • ラベル付きバージョンのサポートがあります。

  • システムは全般的により堅牢で、データ損失の可能性が低くなります。

を確認してください プロジェクト履歴の完全機能ドキュメントarrow-up-right プロジェクト履歴の完全機能に関する詳細については。

既存プロジェクトの移行

1

バックアップを作成する

フルの バックアップを作成するarrow-up-right インスタンスの一貫したスナップショットを含むフルのバックアップを作成してください()。 mongo, redis および sharelatex ディレクトリ。

2

を更新します

sharelatex/sharelatex イメージのバージョンを 3.5.13 に更新します。

Toolkit: 使用する $ bin/upgrade ツールキットを最新バージョンにアップグレードするスクリプトと、を編集して config/version を 3.5.13 にします。

3

インスタンスを起動する

理想的には、移行中にユーザーがインスタンスにアクセスするのを防ぎ、復元が必要になった場合のデータ損失を避けることをお勧めします。方法の詳細は参照してください オフライン移行arrow-up-right これを行う方法についての詳細情報。

4

すべてのサービスが稼働するまで待つ

すべてのサービスが稼働するまで待ってください(下記コマンド参照)

$ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status"
web sharelatex は生きています (api)%
5

移行スクリプトを実行する

# Overleaf Toolkit ユーザー:
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"

# 従来の docker-compose.yml ユーザー:
$ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"

--force-clean 新しいシステムで部分的に移行されたプロジェクト履歴データをクリアします。これにより、以前の試行で失敗した個々のプロジェクトの移行を再試行できます;

--fix-invalid-characters 新しい履歴システムでサポートされていない不可視文字を置換します;

--convert-large-docs-to-file 編集可能サイズのしきい値 2MB を超えるドキュメントを非編集可能なファイルに変換します)

出力は次のようになります:

移行済みプロジェクト  :  1
総プロジェクト数      :  51
残りのプロジェクト数 :  51
移行する合計履歴レコード数: 98
移行を開始しています...
プロジェクトを移行中: 63d29b5772dd80015a81bffe
移行結果 { upgraded: true, historyType: 'NoneWithoutConversion' }
プロジェクトを移行中: 63d29c2e72dd80015a81c0a2
移行結果 { upgraded: true, historyType: 'NoneWithoutConversion' }

// 

移行完了
==================
移行したプロジェクト:  51
移行に失敗したプロジェクト:  0
Done.

移行が成功すると、終了コードが返されます: 0, および失敗がないことを示す最後の行:

移行に失敗したプロジェクト:  0
Done.

ユーザーへのアクセスを再開できます(次のステップを参照)。失敗がある場合は、下のトラブルシューティングセクションをご覧ください。問題がすぐに解決しない場合でもサイトを再開できます。未移行のプロジェクトはレガシーの履歴システムに残ります。

6

サイトを再開する

オフライン移行を選択していた場合は、サイトを再開する必要があります。まだログイン中の場合は次の操作が必要です:

  1. をクリックする 管理 ボタンを押して選択 サイトを管理

  2. をクリックしてください エディタを開く/閉じる タブ

  3. をクリックしてください エディタを再度開く ボタン

ブラウザを閉じている場合は、次のコマンドでサイトを再起動する必要があります: $ bin/up.

オフライン移行

履歴移行スクリプトが実行されている間にユーザーがログインできないようにするには、次の手順に従ってください:

  • 管理者アカウントで Overleaf インスタンスにログインする

  • をクリックする 管理 ボタンを押して選択 サイトを管理

  • をクリックしてください エディタを開く/閉じる タブ

  • をクリックする エディタを閉じる ボタン

  • をクリックする すべてのユーザーの接続を切断 ボタン

これが行われると、ログインしているユーザーはメンテナンスページにリダイレクトされ、ログインページを訪れる新しいユーザーはメンテナンスページと できません ログインできなくなります。

オンライン移行

アプリケーションを稼働させたまま移行スクリプトを実行することは可能です。考慮すべき点がいくつかあります:

  • 移行プロセスはCPU集約型です。スクリプト実行中はリソース使用状況を監視してください。

  • 高い --concurrency 値では、一部のサービス(track-changes 特に)がイベントループのブロッキングを経験する可能性があり、ユーザーエクスペリエンスの低下につながることがあります。推奨される開始値はデフォルトの --concurrency=1 値です。

  • スクリプトはいつでも停止できます。再開すると、前回の中断したところから移行を再開します。夜間など、空いている時間に実行する場合に便利です。

プロジェクト数が1000未満の場合は、サイトを閉じてメンテナンスウィンドウでオフライン移行を実行することを推奨します(db.projects.count())。プロジェクト数が多い場合はスクリプトを実行して進行状況を監視し、オンラインで続行するかオフラインで実行するかを判断してください。

レガシー履歴データのクリーンアップ

レガシー履歴データをクリーンアップするスクリプトは Server Pro に追加されました 3.5.6, 4.0.6 および 4.1.0.

このスクリプトはすべてのプロジェクトが移行された後に実行できます。オンライン移行中に空き領域を確保するためにも使用できます。

circle-info

Server Pro の 3.5.13 より前のバージョンでは、スクリプトは次の内容を削除します: docHistory および docHistoryIndex コレクション。MongoDB はドキュメントを削除してもディスクスペースを解放しません。代わりに同じコレクション内の将来のドキュメントのためにそのスペースを再利用します。履歴移行後、これらのコレクションに再び書き込みは行われないため、ディスクスペースは未使用のままになります。

ディスクスペースを再び利用可能にしたい場合は、Server Pro 3.5.13(3.x リリースを使用している場合)または Server Pro 4.2.5(4.x リリースを使用している場合)にアップグレードしてクリーンアップスクリプトを再実行できます。

Server Pro の最新パッチリリースに含まれるクリーンアップスクリプトは、 3.5.x および最新の 4.x.x 最終ステップとしてコレクションを削除しています。

クリーンアップスクリプトを再実行しても安全です。

トラブルシューティング

ここにトラブルシューティングのアドバイスを追加します。通常はServer Proの顧客にのみサポートを提供しますが、このマイグレーションの性質を考慮して、フルプロジェクト履歴マイグレーションに特有の問題が発生したCE顧客にも可能な限りサポートを行いますのでご留意ください。

フルプロジェクト履歴マイグレーションスクリプトが失敗した場合(エラーで終了する、または失敗したプロジェクト数が0でない数を表示する場合)、以下の詳細をメールでサポートチームに送信してください。 [email protected]envelope、詳細:

件名: フルプロジェクト履歴マイグレーションの問題

  • インスタンスタイプ: CE または Server Pro(適宜削除)

  • インストールタイプ: Overleaf toolkit または docker-compose.yml またはその他(適宜削除)

  • バージョン: 3.5.x(toolkit: $ cat config/version)

  • マイグレーションスクリプトの出力(コンテナ内の次の場所にあるはずです): /overleaf/services/web)

  • マイグレーション済みプロジェクト:(マイグレーションスクリプトの出力による)

  • 合計プロジェクト数:(マイグレーションスクリプトの出力による)

  • 残りのプロジェクト:(マイグレーションスクリプトの出力による)

  • マイグレーションの所要時間:

  • bin/doctor 出力(toolkit使用時)

  • Toolkit バージョン: $ git rev-parse HEAD (Toolkit 使用時)

ログファイルをメールに添付することを検討してください。 history-v1, project-history および track-changes サービスのログは次の場所で確認できます: /var/log/sharelatex の中に sharelatex コンテナ内からエクスポートするには次のようにします:

ログファイルを添付する前に、機密情報を編集(赤字化)してください。

壊れたファイルツリーの検出

ファイル名が空など、ファイルツリーが不正なプロジェクトではマイグレーションが失敗することがあります。これらの問題の一覧は次のコマンドで確認できます。 find_malformed_filetrees データベース内のすべてのプロジェクトをチェックするスクリプト:

無効なパスを修正するには、次のスクリプトを使用してください。 fix_malformed_filetree 各不正パスごとに1回ずつ次のコマンドを実行します:

フルプロジェクト履歴からレガシー履歴へのダウングレード

フルプロジェクト履歴にマイグレーションされたプロジェクトをレガシー履歴に戻したい場合は、次のスクリプトを使用してください。 downgrade_project スクリプトは次のように実行します:

最終更新