Migrate a vBulletin 4 forum to Discourse

michaeld · 2월 7, 2020, 6:03오후

네, 변환됩니다. 내일 이메일로 보내드리겠습니다!

codinghorror · 2월 8, 2020, 8:41오전

개인 메시지를 사용하려면 신뢰 수준 1에 도달해야 합니다. 아직 이곳에서 주제를 충분히 읽지 않아 해당 수준에 도달하지 못했습니다.

nory · 3월 22, 2020, 9:07오후

안녕하세요, 저는 Docker 컨테이너(DigitalOcean)를 사용 중이며 mybb를 가져오려고 시도하고 있습니다(이 튜토리얼은 Vbulletin을 위한 것이지만 Gemfile 부분은 비슷합니다). bundle install 단계에서 막혀 있습니다:

chratec · 4월 7, 2020, 4:06오전

안녕하세요,

vBulletin v3.8을 Discourse로 가져오려고 시도했습니다. 300MB 크기의 데이터베이스, 약 4만 명의 사용자, 6만 개의 게시글을 가진 환경에서 이 스크립트는 잘 작동했습니다. 하지만 가져오기 과정이 끝날 무렵 문자 인코딩(charset) 문제로 인해 어려움을 겪고 있습니다.

저희 vBulletin 3.8은 latin1 문자 인코딩으로 저장되어 있습니다.
----> 가져오기 스크립트를 실행할 때, Discourse Docker 환경의 MySQL 5.6도 UTF-8 문자 인코딩으로 설정되어 있었습니다.
가져오기 스크립트는 가져오기 과정에서 데이터를 UTF-8으로 변환하도록 강제합니다.
따라서 가져오기 과정이 끝난 후 Discourse 포럼에서는 데이터가 UTF-8 인코딩 오류로 표시됩니다. 아래 이미지와 유사한 형태입니다.

가져오기 전, vB 3.8
Discourse로 가져온 후

image581×583 20.9 KB

다음과 같은 시도를 해보았습니다:

가져오기 스크립트를 실행하기 전에 vB 3.8의 문자 인코딩을 UTF-8으로 변환
이 vB 3.8 데이터베이스를 새로운 MySQL 서버에서 테스트했는데, 텍스트가 정상적으로 표시되고 인코딩 오류가 발생하지 않았습니다.

따라서 이 경우 어떤 조언을 주실 수 있을까요?

이 문제에 대한 도움을 주시면 감사하겠습니다. (제 영어가 이해하기 어렵게 느껴지신다면 죄송합니다)

pfaffman · 4월 7, 2020, 5:41오후

비슷한 문제를 해결했던 코드의 일부입니다:

    ### WIN1252 인코딩
    win_encoded = ''
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
      win_encoded = ''
    end
    raw = win_encoded

chratec · 4월 8, 2020, 1:18오전

정말 큰 도움이 되었습니다.
간편한 방법을 찾아보려고 Migrate a phpBB3 forum to Discourse - #540 by gerhard 게시물의 변환 스크립트를 시도해 보았는데, 데이터베이스 문자 인코딩 문제를 빠르게 해결해 주셔서 지금은 완벽하게 작동하고 있습니다.
좋은 조언 주셔서 정말 감사합니다.

Canapin · 5월 25, 2020, 9:32오전

vbulletin5 가져오기를 사용하여 마이그레이션을 수행한 분이 계신가요? 나중에 이 도구를 사용할 계획인데, 이미 완벽하게 사용된 사례가 있는지 궁금합니다.

pfaffman · 5월 25, 2020, 12:37오후

방금 vBulletin5를 가져와서 몇 가지 기능을 추가했습니다(영구 링크, 일부 서식, 그리고 기억나지 않는 다른 것들). PR을 제출할 예정인데 아직 진행하지 못했습니다.

Canapin · 8월 14, 2020, 12:40오후

첨부 파일이 포함된 vb5 데이터베이스 덤프가 있습니다. 이 첨부 파일을 Discourse에 가져올 수 있나요, 아니면 모든 첨부 파일을 파일 형태로 가져와야 하나요?

이 부분도 헷갈립니다. 정확히 어떤 위치에 첨부 파일들을 복사해야 하나요?

Canapin · 8월 18, 2020, 8:43오후

다시 인사드립니다.
제가 이해한 바로는, 데이터베이스의 첨부파일은 아바타와 같은 방식으로 처리되는 것 같아서 정상적으로 작동할 것 같습니다.

가져오기(import)는 잘 진행되고 있지만, 가져온 게시글의 91% 지점에서 오류가 발생했습니다.

importing posts...
  1425149 / 1564573 ( 91.1%)  [1040 items/min]  Traceback (most recent call last):
        14: from script/import_scripts/vbulletin5.rb:726:in `<main>'
        13: from /home/canapin/discourse/script/import_scripts/base.rb:47:in `perform'
        12: from script/import_scripts/vbulletin5.rb:49:in `execute'
        11: from script/import_scripts/vbulletin5.rb:300:in `import_posts'
        10: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `batches'
         9: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `loop'
         8: from /home/canapin/discourse/script/import_scripts/base.rb:863:in `block in batches'
         7: from script/import_scripts/vbulletin5.rb:320:in `block in import_posts'
         6: from /home/canapin/discourse/script/import_scripts/base.rb:508:in `create_posts'
         5: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         4: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
         3: from /home/canapin/discourse/script/import_scripts/base.rb:509:in `block in create_posts'
         2: from script/import_scripts/vbulletin5.rb:321:in `block (2 levels) in import_posts'
         1: from script/import_scripts/vbulletin5.rb:450:in `preprocess_post_raw'
script/import_scripts/vbulletin5.rb:450:in `gsub': invalid byte sequence in UTF-8 (ArgumentError)

vBulletin 데이터베이스에서 해당 게시글의 내용이 어떻게 보이는지 확인하려면, 해당 게시글을 올바르게 식별하는 방법은 무엇일까요?

pfaffman · 8월 18, 2020, 9:32오후

누군가 rescue를 사용하여 이 문제를 해결하는 방법을 제안했는데, 해당 내용을 다시 찾아보시는 것이 좋을 것 같습니다(이 토픽에서였는지 다른 곳에서였는지 기억이 나지 않습니다). rescue 안에 put을 넣어 문제를 일으킨 id와/또는 텍스트를 출력할 수 있습니다.

인코딩 문제가 있습니다.

비슷한 가져오기 작업에서 저는 이것을 사용했습니다(preprocess_post_raw에 넣으실 것 같습니다)

    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
      win_encoded = ''
    end

Canapin · 8월 19, 2020, 7:59오전

안녕하세요,

임포터(importer)를 수정하고 다음과 같이 스크립트를 추가했습니다:

  def preprocess_post_raw(raw)
    return "" if raw.blank?
    begin
      win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
                            invalid: :replace, undef: :replace, replace: ""
                           ).force_encoding('utf-8').scrub
    rescue => e
      puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
      win_encoded = ''
    end
    # decode HTML entities
    raw = @htmlentities.decode(raw)

    # fix whitespaces
    raw = raw.gsub(/(\\r)?\\n/, "\n")
      .gsub("\\t", "\t")

UTF-8에서 잘못된 바이트 시퀀스 오류는 이 부분에서 발생합니다: raw = raw.gsub(/(\\r)?\\n/, "\n") .gsub("\\t", "\t").

그 후 다시 임포터를 실행했습니다. 이미 가져온 데이터는 건너뛰지만, 오류를 발생시키는 게시글에 도달하는 데 약 6시간이 걸렸고, 게시글 내용을 확인하기 위해 예상했던 정보가 추가되지 않았습니다. 이유가 무엇일까요?

수정:

아래가 오류를 유발하는 게시글의 원본(raw) 내용일 가능성이 높습니다:

I wonder if Billy is enjoying the parade.

Qwertyuiopasdfghjklzxcvbnm&#55356;&#57174;

이전 140만 개의 게시글을 (진정으로) 건너뛰도록 임포터 스크립트를 수정해 보겠습니다. 행운을 빕니다.

pfaffman · 8월 19, 2020, 12:58오후

최근 데이터만 가져올 수 있도록 import_after 설정을 포함하도록 다른 여러 가져오기를 수정했습니다. 어떻게 했는지 확인하려면 다른 가져오기들을 살펴보세요.

Canapin · 8월 19, 2020, 10:48오후

안녕하세요,
거의 모든 게시글을 가져오는 데 성공했습니다! 몇십 개를 수동으로 수정하고, utf-8 오류가 발생할 때마다 가져오기를 다시 시작했습니다…

이제 첨부 파일(이것들은 VBulletin 데이터베이스에 저장되어 있음)을 가져와야 하는데, 작동하지 않습니다:
프로세스가 시작되면 약 10~20초 동안 RAM 사용량이 급격히 증가하고 다음과 같은 오류가 발생합니다:

importing attachments...
Failed to create upload: Cannot allocate memory - grep
Fail

제 RAM 상태:

저는 Windows 10의 Ubuntu 18 서브시스템에서 Discourse 개발 버전을 사용 중이며, RAM은 16GB입니다.

첨부 파일은 13GB짜리 VBulletin 데이터베이스 중 7GB를 차지합니다.
vbulletin5 가져오기 도구를 사용한다는 점에 유의하세요.

문제는 이 쿼리에서 발생합니다:

    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid

이 쿼리를 mysql에서 실행하면 몇 초 안에 남은 RAM이 모두 차오릅니다.

(문제를 파악하고 우회 방법을 제시하는 중이라, 쓸모없는 정보와 질문을 제거하기 위해 게시글을 수정합니다)

우회 방법:

가져오기 SQL 쿼리에 limit와 offset을 추가했습니다. 매번 20,000개씩 선택하여 첨부 파일을 가져왔습니다:

    uploads = mysql_query <<-SQL
    SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
      FROM #{DB_PREFIX}attach a
      LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
      LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
      LIMIT 20000 OFFSET 0
    SQL

또한 uploads.each do |upload| 루프 끝에 exit를 추가하여 20,000개의 업로드를 가져온 후 가져오기 스크립트가 계속 실행되는 것을 방지했습니다.

10,000개의 업로드가 가져와지면, 스크립트를 편집하여(nano +353 ./scripts/import_scripts/vbulletin5.rb를 사용하여 올바른 줄에서 파일을 열었습니다) SQL 쿼리의 OFFSET을 10,000씩 증가시키고 가져오기를 다시 시작합니다… 그리고 이 과정을 65,000개의 첨부 파일에 대해 반복했습니다.

첨부 파일 가져오기 과정에서 다음과 같은 여러 오류와 경고에 직면했습니다:

W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Bad date/time value "0000:00:00 00:00:00": mon out of range
Post for 490451 not found (추측컨대 고아된 오래된 첨부 파일일까요?)
EXIF 데이터 오류로 보이는 것들
Fail 이 오류는 저를 혼란스럽게 했고 가져오기 스크립트를 중단시켰습니다. 받은 첫 번째 "Fail"을 확인해 보니 게시판 첨부 파일이 약간 깨져 있거나(파일명 없음) 상태였습니다. 그래서 가져오기 도구가 "실패"할 때에도 계속 작업을 진행할 수 있도록 exit 지시문을 주석 처리했습니다. 그렇게 하면 아무것도 깨지지 않기를 바랐습니다.

       puts "Fail"
       #exit

또한 가져오기를 중단시킨 더 귀찮은 오류도 있었습니다:

1: from /usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:53:in `save!'
/usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:80:in `raise_validation_error':
Validation failed: Body is limited to 32000 characters; you entered 32323. (ActiveRecord::RecordInvalid)

다행히 드문 오류였으며, 동일한 오류가 다시 나올 때까지 해당 첨부 파일을 건너뛰었습니다. 65,000개의 첨부 파일 중 약 10번 정도 발생했습니다. SQL 쿼리 offset을 변경하여 가져오기 스크립트를 다시 시작하기만 하면 되었습니다.

Canapin · 8월 22, 2020, 9:38오전

안녕하세요,
나머지 27,000명의 사용자 중 약 400명의 사용자에게 사용자 지정 필드 import_pass가 누락되어 있음을 확인했습니다. (비활성 사용자 154,000명은 정리했습니다.)

이유에 대해 혹시 추측이 있으신가요?

이 포럼은 5월에 phpBB에서 vBulletin으로 마이그레이션되었습니다. 이 마이그레이션과 관련이 있을 수 있을까요?

이 400명의 사용자에게 비밀번호를 가져와서 이 문제를 '수정’하려 하지는 않을 것입니다(쉬운 방법이 있다면 모르겠지만…?). 그리고 큰 문제가 되지는 않으므로, 단순히 궁금해서 물어본 것입니다.

Canapin · 8월 22, 2020, 6:10오후

여러분,

게시물을 가져오면 재구축(rebake)을 하지 않는 한 이미지의 가로/세로 비율이 잘못 표시됩니다. 재구축 없이 올바른 비율을 유지하는 방법(예: 가져오기 과정에서)을 찾고 싶습니다.

문제에 대한 더 자세한 설명:

제 이해로는, Discourse가 해당 게시물을 생성할 때 가져온 게시물은 “baked”(구축 완료) 상태가 아닙니다(다만 cooked 필드는 어떤 방식으로든 생성됩니다). 그래서 기존 Discourse 게시물을 구축하는 것보다 게시물을 가져오는 속도가 훨씬 빠른 것입니다.

제 문제는 가져온 이미지의 가로/세로 비율이 잘못되어 있다는 것입니다.

가져온 이미지와 관련된 Discourse 원시(raw) 텍스트 예시:

![SH-MUniFrame.JPG|600x800](upload://6Li1nnjbA8zDz6YJ3FqeYHV5zXK.jpeg)

“cooked” 필드의 내용:
<img src="https://global.discourse-cdn.com/meta/original/3X/0/3/0379f53ed8221730ccb31807238e9c46e9fe1d37.jpeg" alt="SH-MUniFrame.JPG" data-base62-sha1="6Li1nnjbA8zDz6YJ3FqeYHV5zXK" width="517" height="500" class="d-lazyload">

게시물에서 이미지가 표시되는 모습:

원본 이미지는 여기 있습니다: https://global.discourse-cdn.com/meta/original/3X/f/7/f73a0ae8594219dd5a1620e59b3c17f9b02b1583.jpeg

vBulletin 데이터베이스의 원본 이미지 크기는 다음과 같습니다:

select width, height from filedata where filedataid = 76237
+-------+--------+
| width | height |
+-------+--------+
|   600 |    800 |
+-------+--------+

제 이해로는, Discourse 설정에서 최대 높이를 500px으로 제한하기 때문에 <img>의 height 속성 값이 500으로 고정된 것입니다. 그런데 <img>의 width는 600에서 517로 다소 변경되어 있는데, 어떻게 그리고 왜 그런지 파악하지 못하고 있습니다.

가로와 세로 vBulletin 첨부 파일 필드에 모두 0이 저장된 오래된 이미지에서도 동일한 문제가 발생합니다. 이들도 가로/세로 비율이 잘못되어 있습니다. 이러한 값이 가져오기 과정에서 실제로 사용되는지 알 수 없습니다.

게시물을 재구축(HTML 재빌드)하면 문제가 해결됩니다. 그러면 이미지가 올바르게 리사이즈되고 이미지 뷰어도 추가됩니다. 하지만 제게는 160만 개의 게시물이 있어 모두 재구축하는 것을 피하고 싶습니다.

간단한 해결책으로 제 Discourse에 다음 CSS를 사용할 수 있습니다:

.cooked img:not(.emoji) {
    height: auto;
    width: auto;
}

하지만 이렇게 하면 이미지를 업로드할 때 임의의 크기를 선택할 수 없게 되며, 제가 인지하지 못하는 부수적 효과도 있을 수 있습니다.

가져온 첨부 파일의 이미지 가로/세로 비율을 올바르게 유지하는 방법에 대해 아이디어가 있을까요?

pfaffman · 8월 22, 2020, 7:37오후

가져오기 이후에 ‘cook’ 처리를 하지 않았기 때문인 것 같습니다. 게시물을 다시 'bake’하지 않고 이 문제를 해결하는 방법은 상상할 수 없습니다. 모든 게시물이 아니라 손상된 게시물만 다시 'bake’하는 것을 고려해 보시는 건 어떨까요?

Canapin · 8월 22, 2020, 7:47오후

가져오기 이후 시간이 지남에 따라 자동으로 조리(cook)되도록 설정되어 있나요? 마지막에 생성된 게시글부터 시작하나요, 아니면 처음 생성된 게시글부터 시작하나요?

다행히 큰 문제는 아니지만, 자동으로 조리되지 않는다면 모든 게시글에 대해 재조리(rebake)를 시작하고 인내심을 갖고 기다릴 것 같습니다. 다만 며칠 전에 이 게시글을 읽고 조금 무서웠던 점은 인정합니다: My journey into a massive posts rebake job. 이 게시글에 대해서도 궁금한 점이 있지만, 적절한 주제에서 질문하겠습니다.

michaeld · 8월 22, 2020, 8:10오후

음, 네. 제 코드인 것 같습니다. 죄송합니다.

다음 패턴을 따르는 것이 좋습니다:

   batches(BATCH_SIZE) do |offset|
       (Sql code)
        LIMIT #{BATCH_SIZE}
        OFFSET #{offset}
        (Other code)
    end

michaeld · 8월 22, 2020, 8:13오후

가져오기 전에 최대 게시글 길이 사이트 설정을 높이면 됩니다.

글		댓글	조회수
Migrate a phpBB3 forum to Discourse Migrating to Discourse how-to	464	108199	9월 4, 2025
phpBB 3 Importer (old) Feature	89	18347	10월 8, 2014
How to convert vBulletin 4 database to Discourse? Product Support	35	8620	9월 22, 2016
Migrating vBulletin 5 database - Import script errors Migration vbulletin5	46	3352	3월 8, 2023
Migrate a bbPress WordPress plugin forum to Discourse Migrating to Discourse how-to	33	13556	1월 10, 2024

Migrate a vBulletin 4 forum to Discourse

우회 방법:

문제에 대한 더 자세한 설명:

Related topics