Re: phpBB3 포럼을 Discourse로 이전하기

안녕하세요,

phpBB 3.3.3이 지원되는지, 아니면 3.3.0만 엄격하게 지원되는지 궁금합니다. 1.5단계인 다음 명령을 실행할 때:

/var/discourse/launcher enter import

(phpBB3 포럼을 Discourse로 마이그레이션 - 문서 / sysadmin - Discourse Meta 링크: Migrate a phpBB3 forum to Discourse)

두 번 시도해 보았지만 다음과 같은 응답을 받고 있습니다:

x86_64 arch detected.
Error response from daemon: No such container: import

/var/discourse/launcher enter import.yml

을 사용하면 다음과 같은 응답이 나타납니다:

x86_64 arch detected.
ERROR: containers/import.yml.yml does not exist or is not readable.
Available configs ( app, import )

이 문제가 해결될 가능성이 있을까요?

감사합니다.

안녕하세요, 환영합니다!

처음부터 가이드를 따르셨을 것으로 생각되는데, /var/discourse/containers/import.yml 파일이 실제로 존재합니까?

설정 파일이 삭제된 것으로 보입니다.

네, 위의 메시지처럼 ‘containers’ 디렉토리에 app.yml과 import.yml이 모두 있습니다.

제 이해가 맞다면, 이전 단계들을 따르는 데는 문제가 없었고, app.yml 옆에 import.yml을 생성/편집했으며, import 컨테이너를 다시 빌드했는데, 지금은 그 컨테이너에 진입조차 할 수 없다는 말씀이시죠? 맞나요? 정말 이상하네요!

이 명령어는 어떤 결과를 반환하나요? ls -l /var/discourse/containers

여전히 동일합니다: app.yml과 import.yml (그리고 app.yml의 “bak” 파일).

Lightsail 1GB (초기에는 940MB, Ubuntu 업데이트 후에는 "921MB"가 됨)에 이 프로그램을 설치하려고 시도해 왔기 때문에 "문제"가 있을 수 있습니다. 공식 설치 방법을 사용했으며, 설치된 버전은 3.2가 최신 안정 버전이라는 위키 표시와 달리 3.3.* 베타 어딘가였습니다. 4GB 스왑을 사용했을 때 설치에는 1시간 15분에서 1시간 20분이 걸렸고, "launcher rebuild import"에는 약 2시간이 걸렸습니다.

낮은 메모리 조건으로 인해 무언가가 잘못 종료되었을 수 있을까요?

참고로, 2GB 설정에서 생성된 백업 파일은 1GB 설정에서도 읽을 수 있을까요?

성공적이었나요? 재빌드 후 컨테이너가 시작되어야 합니다.
컨테이너가 시작되지 않으면 진입할 수 없습니다(./launcher start import)

그럴 가능성이 높습니다. 여기에는 메모리/스왑 부족과 재빌드 실패에 관한 여러 주제가 있습니다 – 보통 RAM/스왑을 늘리는 수밖에 없습니다.

저는 이 분야의 전문가가 아니지만, 누군가 더 나은 통찰을 주기를 바랍니다.

RAM이 실제로 문제가 되는 것 같습니다. Lightsail 2GB/2GB 환경에서 클린 설치는 약 3.5~4배 빠르고, import 컨테이너 재빌드는 약 10배(심지어 그 이상) 빨랐습니다.

다만, import 스크립트가 phpBB 3.3.3에서는 작동하지 않을 수도 있다는 우려가 있습니다. 어쨌든 두 번 시도했지만 결과는 동일했습니다: 약 10개의 카테고리 이름 중 단 하나의 단어만이 빈 “category” 하나로만 가져와졌습니다. MySQL 텍스트 덤프는 2.66MB로 꽤 작은 편입니다. 모든 테이블 접두사는 요구사항에 맞게 설정되어 있습니다. 이미지, 이모티콘 등은 없습니다.

결론적으로, 포럼, 포럼 카테고리, 게시글은 하나도 가져와지지 않았지만, 사용자(수백 명)와 해당 통계는 모두 올바르게 가져와졌습니다.

phpBB 3.3.3 업데이트에서 사용된 MySQL 버전에 관한 무언가가 변경된 것 같지만, 여기서는 덤프 파일이므로 결국은 중요하지 않을 것 같습니다.

다른 무엇인지 확인해 볼 수 있는 아이디어가 있을까요?

최소 4GB의 RAM을 권장합니다.

오류가 있나요? 한 카테고리를 가져온 후 스크립트가 종료된 것 같습니다.

2.6MB 텍스트 파일을 열어서 읽거나 파싱하는 데 4GB가 필요하다는 뜻인가요? 혹시 Discourse 개발자이신가요? 그 덤프를 읽고 Discourse에서 사용하는 모든 데이터를 추출해서 다른 형태로 저장하는 바이너리 실행 파일은, 이 단순한 작업을 위해 MariaDB 전체를 포함하는 것까지 신경 쓰지 않는다면, 100KB 버퍼를 기준으로 약 200KB 정도가 적당하다고 생각합니다.

개인적으로 RAM 문제가 아니라고 봅니다. 프로세스는 빠르게 진행되었고, 가져온 테이블에 대해 가져오기 진행 상황을 표시했습니다. "종료"되지도 않았습니다. 사용자 테이블은 덤프의 맨 끝에, 주제 등 다른 테이블 뒤에 위치합니다.

저는 이 작업을 다시 시도해 보려고 했는데, 사용자 테이블을 맨 위로 복사/붙여넣고 위에서 언급한 매뉴얼/페이지의 동일한 단계를 수행해 보기 위해서였습니다(phpBB 대신 phpMyAdmin으로 생성한 덤프를 사용). 하지만 이제 Discourse는 원격 연결을 시도하면서 프로세스 시작을 거부하는데, 연결 정보는 추가하지도 않았습니다.

가져오기 컨테이너를 다시 구축했는데, 혹시 먼저 삭제해야 할 것이 있을까요?

저는 디스커스(Discourse) 운영을 통해 생계를 유지하고 있으며, 셀 수 없을 정도로 많은 마이그레이션을 수행했습니다. 대략 100회 이상은 된 것 같습니다. 2GB는 충분히 작동할 가능성이 높으며, 특히 주제와 사용자가 몇 천 명에 불과한 경우 더욱 그렇습니다. 다만 일시적으로만 필요하신 것이라면, 더 많은 RAM을 사용하는 데 비용이 많이 들지 않으며 해를 끼칠 일도 없습니다. 저도 그것이 문제가 아닐 가능성이 높다고 생각합니다.

스크립트가 실행될 때 카테고리, 사용자, 주제, 게시물을 순서대로 카운트했나요?

이 스크립트는 가져온 데이터를 건너뛰고, 향후에도 해당 데이터를 건너뛰기 위해 커스텀 필드 데이터를 생성합니다. 따라서 스크립트를 다시 실행하려면 디스커스 데이터베이스를 초기화해야 합니다. 아무것도 가져오지 않았다고 하셨으니, 이것이 꼭 필요한지 명확하지 않습니다. 데이터를 가져왔지만 어떤 이유로 찾지 못하고 있는 경우이거나, 데이터를 찾지 못해 실패한 경우일 수 있으며, 이 두 가지 경우 모두에서 데이터베이스를 초기화할 필요는 없어 보입니다.

아무것도 가져오지 않았다고 하셨는데

정확히 말하면 그렇지 않습니다:
“모든 (몇백 명) 사용자는 통계 정보와 함께 올바르게 가져와졌습니다”

컨테이너를 다시 재구성해 보았습니다. 설정은 동일합니다. 아무것도 변경하지 않았고, 다음 단계 이후:
import_phpbb3.sh # Docker 컨테이너 내부에서
스크립트가 이제 다음과 같이 표시합니다:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/mysql2-0.5.6/lib/mysql2/client.rb:97:in `connect’: Unknown database ‘phpbb’ (Mysql2::Error)

아직 이전에 사용된 임시 파일들이 남아있어 삭제해야 하는 것일까요?

결국 phpMyAdmin에서 내보낸 덤프 파일을 사용했습니다. (import) settings.yml에서 매핑 섹션을 생성하는 방법에 대한 예시(또는 더 자세한 사양)가 있을까요?
제 php_forums 테이블은 다음과 같습니다:

forum_id, MEDIUMINT(8) ...	parent_id, MEDIUMINT(8) ...
3	0
8	3
7	3
9	3
10	3
11	0
12	11
13	11
14	11
15	11
17	3

어떤 ID를 사용하든, 그리고 “new_categories: ” 섹션도 지정하든, import 컨테이너가 생성하는 메시지는 정상적으로 보입니다:
creating new categories
11 / 11 (100.0%) [2803 items/min] n]
creating categories
11 / 11 (100.0%) [2704 items/min]

그러나 실제로 생성되는 것은 두 개의 메인 카테고리(phpBB에서 parent_id가 0이던 'forums’였던 것)와 각각의 하위 카테고리 하나(비어 있음)입니다. 이 절차는 모든 게시물을 가져오지만, 모두 ‘orphaned’(고아 상태)가 됩니다.

사용 중인 phpbb3 버전에서 무언가 변경된 것 같습니다.

음, 사실 제 실수를 수정하면서 한 단계 진전을 이뤘습니다. settings.yml 파일에 C/C++ 스타일의 주석을 줄 끝에 넣었는데, 이로 인해 하위 포럼이 "처리"되지 않는 것 같았습니다(다만 오류 메시지는 표시되지 않았습니다).

카테고리와 하위 카테고리를 “새로” 추가하고 이전 ID를 매핑했습니다.
하지만 여전히 모든 게시물이 어떤 카테고리에든 연결되어 있지 않습니다. 이런 게시물은 Postgres 테이블 하나로 저장되는 건가요? 어떻게 삭제할 수 있을까요?

phpbb_mysql.sql 파일에 몇 가지 수정 사항을 추가하여 최소한 스크립트가 원래의 모든 카테고리를 생성할 수 있도록 했습니다. 하지만 이것만으로는 충분하지 않습니다.

토픽/게시물을 처리할 때 다음과 같은 유형의 메시지가 긴 목록으로 출력됩니다.

Parent post [some id] doesn't exist. Skipping [some id]

물론 게시물이 가져와지지 않습니다.

기본 스크립트가 phpBB 3.3.3 테이블과 함께 작동하지 않는다는 것을 확인해 주실 수 있을까요?

결국 categories를 새로 정의하지 않고 settings.yml 파일의 매핑을 모두 제거한 상태로 phpBB3.3.3 덤프 파일을 사용할 수 있었습니다.

원본 phpBB_mysql.sql 덤프 파일을 사용하면 카테고리 로드 단계에서 마이그레이션 스크립트가 중단되고 "빈 카테고리 본문"에 대한 오류가 표시됩니다.
이는 “phpbb_forums” 테이블의 “forum_desc” 필드가 부모 카테고리가 없는 메인 포럼 카테고리에서 비어 있을 때 발생합니다.
해당 첫 번째 카테고리가 부분적으로만 가져와지면 나머지 데이터가 어긋나는 것 같습니다.
새로 설치한 환경에서 해당 테이블 필드에 텍스트를 입력하면 이 문제가 해결되는 것으로 보입니다.