복원 작업을 수행했는데, 내부 링크들이 모두 테스트 URL 도메인을 가리키고 있어서 모든 링크가 깨졌습니다. 왜 올바른 사이트 URL이 적용되지 않았는지는 모르겠습니다. 코드나 데이터베이스에 직접 들어가서 대량 검색 및 치환을 하지 않고, 다른 방법으로 이 문제를 해결할 수 있는 방법이 있을까요?
재복원(Re-Restore)을 해보는 건 어떨지 생각하고 있습니다.
데이터베이스에 들어가서 대량 검색 및 치환을 수행해야 합니다.
이를 위한 도구가 있습니다:
RAILS_ENV=production discourse remap //old.domain //new.domain
설명된 대로 수정할 수는 있지만, 이런 일은 일어나지 않아야 합니다.
/admin/backups를 사용하여 백업을 생성하고 복구했나요?
두 시스템 모두 호스트명이 올바르게 설정되어 있나요?
감사합니다. 그렇게 어려운 일은 아닌 것 같아서 앱을 열고 해당 명령어를 실행해 보았는데, 게시물의 URL 인스턴스가 변경된 것 같지 않습니다.
다음과 같은 리맵을 실행했습니다:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
이 명령어는 “default” DB에서 실행되어 몇 분 정도 걸린 후 오류 없이 "done"이라고 보고되었습니다.
몇 가지 게시물을 확인해 보았는데, 게시물 링크의 URL에 아무런 변화가 보이지 않았습니다.
테스트를 위해 몇 개를 다시 빌드(rebuild)해 보았는데, 링크에서 라이브 환경의 domain.com 대신 dev.domain.com이 표시되었지만, 여전히 동일했습니다.
그런 다음 https://를 빼고 같은 명령어를 실행해 보니 다음과 같은 오류가 발생했습니다.
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
DB에 채팅 메시지가 있어 프로세스가 중단되는 것 같지만, 그 이유는 정확히 모르겠습니다. 말씀하신 대로 저는 평소 디스코러스(Discourse) 관리 시 DB에 직접 접근해 본 적이 없으므로, 어떻게 하면 DB에서 해당 내용을 확인할 수 있는지 파악해야 할 것 같습니다.
마지막으로, 원래의 리맵 명령어를 다시 실행해 보았는데, 몇 분 정도 걸린 후 오류 없이 "done"이라고 보고되었습니다:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
결실을 보려면 게시물을 다시 베이킹(rebake)해야 하는 걸까요?
게시물 재빌드(post rebuild)가 개별 게시물 단위로 동일한 작업인 줄 알았습니다.
아니면 앱을 재빌드해야 하나요?
다음과 되어야 합니다.
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
//를 사용하는 이유는 http://, https:// 및 프로토콜이 없는 URL을 일치시키되, 이메일 주소의 도메인에는 일치하지 않기 때문입니다.
그렇게 하면 어떻게 되나요?
네, 알겠습니다. 그런데 또 같은 오류가 발생했어요:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
적어도 올바른 쓰기 명령을 사용하고 있는 건 확실하니, 상황은 좋아지고 있는 것 같아요! 
더 이상 아이디어가 없나요?
이 rails remap이 막힌 상황을 제외하고, DB를 백업한 후 다시 복원하면 복원 과정에서 Link-URL이 올바르게 remap될 수 있지 않을까 생각했습니다.
아직 발생하고 있는 에러는 여기에서 수정이 필요했던 stop 에러와 동일하거나 매우 유사해 보입니다:
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=...
리맵을 시도할 때:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
@david 님이 이 문제에 대해 통찰을 주실 수 있을까요?
이건 더 버그처럼 보이나요?
해당 테이블에는 두 도메인 모두에 대한 링크가 포함되어 있어, 리맵을 시도하면 중복 키가 발생합니다. 이는 버그가 아닙니다. 중복 키를 생성하려는 시도이기 때문입니다.
해당 테이블에서 아펙스 도메인을 가진 항목을 삭제할 수 있습니다. 더 나은 방법은 아펙스 도메인 대신 www를 사용하는 것입니다.
감사합니다. 제 유일한 우려는 이 디스코urs 배포 환경에서도 non-www / SSL 문제가 발생한다는 점입니다. 예를 들어 How to add ssl to non-www domain? 링크를 참고해 주세요. 하지만 제안해 주신 리맵을 시도해 보겠습니다. 만약 작동한다면 non-www 문제도 해결해야 할 상황이 될 테니까요!
Remap 재구상이 @pfaffman이 제안한 대로 작동했지만, 실제로는 해결책 그 자체라기보다 해결의 촉매제 역할을 했습니다. 제가 어디를 잘못하고 있었는지 파악하는 데 도움을 주었고, 마치 제 눈을 다시 매핑해준 셈이죠.
만약 에러 메시지를 제대로 읽었다면, 즉 주의를 기울였다면, 핵심 정보가 에러 메시지에 들어 있다는 것을 알아채고 훨씬 전에 이 문제를 해결했을 것입니다.
해야 할 일은 stop 에러로 표시된 게시글 번호 …/p/123456789를 URL에 포함시켜 해당 페이지로 직접 이동한 뒤, 각 게시글을 수동으로 수정하는 것이었습니다.
대부분의 문제는 www를 처음 remap에서 apex non-www URL로 변환하기 위해 두 번째 remap을 실행할 때 발생했습니다. 이는 원래의 필요 사항이기도 했습니다.
이제 내부 URL은 apex 링크만 포함해야 합니다.
이것은 이전의 많은 legacy www 내부 링크로 인해 발생했던 www SSL 리다이렉션 문제를 일부 해결합니다. 사용자가 주소창에 www를 직접 입력하거나 WWW 자체에서 링크백을 사용하는 경우는 해결하지 않지만, 내부에서 생성되는 링크들은 모두 처리할 수 있을 것입니다. 이 문제가 구글 인덱싱에 어떤 영향을 미치는지 지켜본 후 추가 조치를 결정할 예정입니다.
개발자분들에게 흥미로울 수 있는 내용입니다.
duplicate key value violates unique constraint “unique_post_links”라는 stop 에러가 많이 발생했습니다. 이는 게시글이 이동될 때 discourse가 “Continued from …. “ 텍스트와 함께 핫링크를 포함시켰을 때 발생했으며, 분할된 게시글들이 동일한 위치를 인용 블록으로 포함하고 있으면 remap이 중단되었습니다.
이것이 stop 에러의 대부분을 차지했습니다.
해결 방법은 중복된 내부 링크백이나 코드 브래킷 중 하나를 제거하는 것이었습니다(항상 성공하지는 않았습니다). 이렇게 하면 remap을 다시 실행했을 때 진행되었습니다.
다른 stop 에러들은 사용자가 같은 게시글 조건을 수동으로 생성할 때 발생했습니다. 같은 링크를 다시 게시하면서 인용(Quote)도 자동으로 링크백을 생성한다는 사실을 인지하지 못했기 때문입니다. 아마도 과거의 습관이나 스타일 등이 작용한 것 같으며, 이는 여전히 많은 사용자가 discourse가 얼마나 많은 링크를 자동으로 처리하여 사용성을 높여주는지 인식하지 못하고 있음을 시사합니다. 아이러니하죠!
Remap 이후 편집을 되돌릴 수도 있었지만, 차이가 크지 않을 정도로 개수가 적었고, 게시글 또는 인용의 내부 discourse 소스로의 올바른 링크백이 하나 남아 있었기 때문에 그대로 두었습니다.
이로 인해 구글에서 인덱싱이 해제된 수백에서 수천 페이지가 비인덱싱된 회색 무법지대로 밀려드는 현상을 대거 되돌릴 수 있기를 바랍니다.
조금 아는 것이 위험할 수 있습니다! 