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

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

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

これが全体の数字です。

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

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

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

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

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

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

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

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

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

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

「いいね!」 1