vBulletin 5データベースの移行 - インポートスクリプトのエラー

では、あなたにとって「悪い知らせ」ですね、ジャミー。

スクリプトが未完成の状態であるため、vb3のインストールをディスコースに直接移行するためにゼロから書き直すことにしました。C#も使用しており、これにより速度が桁違いに向上します。

スクリプトを十分に「汎用的」にできれば、GitHubを公開しますが、今日でもvb3に留まっている古いコミュニティの移行にそれほど関心があるとは思えません。

「いいね!」 2

ちょっとしたアップデートです。非常に献身的な少人数のグループの尽力のおかげで、ほぼ完了しました。

来週月曜日からステージングマシンでいくつかのテスト実行を開始しますが、結果は有望です。

これが全体の数字です。

サイズ的には、vbulletin3形式のDBは約8GBです。

そして、ローカルマシンからソースDBにリモートで接続して実行するテストは約6時間で完了します。

このスクリプトは、すべてのフォーラム/サブフォーラムを移行し、それらをカテゴリとサブカテゴリに翻訳します。3レベルのサブカテゴリが必要です。なぜなら、私たちはかなり古いスタイルのフォーラムを持っており、そこにホストされている「クラン」フォーラムが非常に、非常にネストされているからです。

3レベルを超えるものはすべて自動的にタグに変換され、親/子のサブフォーラムの関係(タググループを使用)における階層構造を維持します。

カスタムパーミッション(例:読み取り専用)が設定されているサブフォーラム、またはモデレーター/管理者のみ、あるいはパスワードアクセスで非表示にされているサブフォーラムはすべて、「スタッフのみアクセス可能」として移行されます。最終的にはそれらは数十個になり、スタッフが手動で正しいユーザーグループに再有効化できます。

ユーザー、ユーザーグループ、プライベートメッセージも移行されます。プライベートメッセージは「Discourse流」で移行されます。つまり、データベースの単純な1対1移行で見られるようなN件のトピックと1件のメッセージ(本当に愚かなデータベース構造です)ではなく、Discourseが使用するスレッド編成の方法になります。

スクリプトは、すべての投稿のクッキングもすでに実行しており、プロセスを高速化します。

トピックと投稿の移行は、複数の並列接続で行われ、ソースDBが許可する接続を最大限に活用しようとします。

2vcore/4GB RAMの小さなマシンで平均してどれくらいの時間がかかるか見ていきますが、現在(未完成の)バルク移行スクリプトよりもすでに数桁高速です。

いくつかの部分はより最適化できる可能性があり、その多くは私たちのフォーラムのために特別に設計されています(フォーラム構造をあまり混沌としないように再編成するためのJSONマッピングさえあります)ので、多少の調整なしに他の誰かがそれを持ち上げて使用できるとは思いませんが、移行が完了した後、ソースリポジトリを公開するかどうかを内部で議論します。

「いいね!」 1

最終アップデートだと思います。

インフラ、コード、ユーザー、モデレーターなどをすべて調整し、移行を完了しました。昨日行われました。コミュニティへのリンクは、許可されているかどうかわからないため、また、イタリアではかなり有名なコミュニティであるため、ここでは共有しません。

これは、ボットを除外した後の、30日間の平均的な数値です。

もちろん、ボランティアチームにはかなりのプレッシャーがかかりましたが、まだ完了していません。カスタムテーマやDiscourseのバックグラウンド設定の一部を微調整しているところです(ヘルプ/明確化/指示を求めるトピックをたくさん開く必要がありそうです)。

私たちのスクリプトは、希望するすべてを移行することに成功しました。

  • ユーザー
  • ユーザーグループ
  • モデレーター/BAN/管理者ステータス
  • プライベートメッセージ
  • カテゴリ
  • トピック
  • 返信

などなど。また、vBulletinにはツイートやYouTube動画などを埋め込むためのカスタマイズがいくつかあり、Discourseのデフォルトの処理方法ではうまく移行できないため、移行プロセス自体にクッキングを統合しました。

4vcore/8GBのテスト環境で実行したところ、移行全体は約7〜8時間で完了しました。
本番環境では、Patreonで8vcore/30GBの費用を賄うのに十分な資金が集まったため、全体で4時間かかりました。

移行のライブ配信を行いました。何度か(もちろん:stuck_out_tongue:)やり直したり、BGMを流したりしました。とても楽しかったです。

トピック/投稿数とタイミングの詳細はスクリーンショットで確認できます。
3つのタイミングは、読み込み時間、クッキング時間、書き込み時間です。

疲労困憊しましたが、非常に刺激的な冒険でした。そして、@pfaffman、私があなたの助けを雇わないと決めたとき、あなたは窮地を脱したと信じてください。

今日現在、このプロジェクトに費やした私の時間だけで約£25kと推定されます:rofl:
過去2ヶ月ほど、他の3人が費やした時間は数えていません。しばしば夜遅くまで作業していました。

現在も移行後のスクリプトを実行中です。アバターをすべてインポートするスクリプトと、返信内に記載された古いURL形式へのリンクが正しくリダイレクトされるようにするためのパーマリンクリダイレクトを作成するスクリプトです。これらは24時間以内に完了する見込みです。

数週間後に、スクリプトのリポジトリをクリーンアップしてオープンソースとして提供できるかどうかを議論する予定です。私一人では決定できません。

編集:すべてのユーザーアバターの完全な移行と、トピック/カテゴリへの内部参照のパーマリンクを追加しました。

image

メインのデータ移行後に実行しました。

Cheers

「いいね!」 3

それは本当のようですね。あなたのコードはかなり素晴らしいように聞こえますが、スクリプトを実行し続けるだけで同じ結果が得られたでしょう。最終的なインポートは数時間、あるいはそれ以下で完了したはずです。

完了したとのこと、おめでとうございます!よくやった!

「いいね!」 1

つまり、ウェブサイトを1か月間閉鎖して移行を待つ必要がないようにすることが目的でした:slight_smile:

また、公式スクリプトに一部欠けている場合、それはかなり難しいです:thinking:

必要はありませんでした。スクリプトを実行すれば、サイトは稼働したままです。スクリプトが完了したら、再度実行します。すでにインポートされたデータはスキップされるため、はるかに高速に実行されます。これを数回繰り返す必要があるかもしれませんが、最終的には数分または数時間で完了します。なぜなら、処理する新しいデータはほとんどなくなるからです。その後、古いサイトを停止し、最後に一度実行します。デフォルトでは、スクリプトは各ユーザーと投稿をチェックしますが、IMPORT_AFTER を設定して日付を指定することもできます。これにより、古いデータは完全に無視されるため、非常に短時間で完了します。

こんにちは!私もこのプロジェクトに関わった者の一人です。
個人的には、非常に豊かな学習経験となりました。まだ最後の問題を解決する必要がありますが、コミュニティ全体が好意的に反応してくれています。新しいフォーラムのリアクションスレッドは…

約24時間でこの数の投稿に達しました :smile:

移行が必要なvB3インストールが、どれくらい他にあるのかは分かりませんが、このスレッドが将来誰かの役に立つことを願って、諦めないでください。大変な作業ですが、やり遂げることができます :smile:

「いいね!」 3