안녕하세요,
서버 마이그레이션을 수행하는 중이라 새 Discourse 인스턴스에 백업을 복원하려고 하고 있습니다. 불행히도 다음 오류가 발생합니다:
아래 내용을 확인하고 인덱스를 삭제했습니다:
이제 다음을 실행하면:
[2] pry(main)> IncomingReferer.where(path: "/m/search")
=> []
결과가 아무것도 나오지 않습니다.
이 상태에서 백업을 받아 다른 서버에 복원해도 괜찮은가요?
감사합니다.
Sam
불행히도 이 방법은 도움이 되지 않았고, 복원 시에도 여전히 이 메시지가 표시됩니다:
[2021-07-03 16:53:41] ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
[2021-07-03 16:53:41] DETAIL: Key (path, incoming_domain_id)=(/search, 4502) is duplicated.
[2021-07-03 16:53:41] EXCEPTION: psql failed: DETAIL: Key (path, incoming_domain_id)=(/search, 4502) is duplicated.
이를 어떻게 수정해야 하는지 명확하지 않습니다.
IncomingReferer.where("path LIKE '%/m/search%'")로 중복 항목을 더 찾아냈고, 해당 인덱스에서도 destroy를 사용했습니다. 이제 제 인스턴스는 전혀 작동하지 않는 것 같습니다 – 오래된 서버에서도 마찬가지라, 다시 구축해 보겠습니다.
Sam
아직 문제가 남아 있습니다. 다음 오류가 발생하고 있습니다:
[2021-07-03 17:28:53] ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
[2021-07-03 17:28:53] DETAIL: Key (path, incoming_domain_id)=(/osmc/osmc, 2939) is duplicated.
[2021-07-03 17:28:53] EXCEPTION: psql failed: DETAIL: Key (path, incoming_domain_id)=(/osmc/osmc, 2939) is duplicated.
새 백업을 복원하려고 할 때 이 오류가 나옵니다.
하지만 콘솔을 확인해 보니 실행 중인 서버(재구축 후 현재 정상 작동 중)의 인스턴스들을 정리했다는 것을 알 수 있습니다:
[1] pry(main)> IncomingReferer.where(path: "/m/search")
=> []
[2] pry(main)> IncomingReferer.where("path LIKE '%/m/search%'")
=> []
다른 기계에 이를 복원할 수 있도록 데이터베이스를 수정하려면 무엇을 해야 하는지 조언해 주실 수 있나요?
감사합니다
Sam
Can't restore due to corrupt indexes (with some clues on how to deal with corrupt indexes) 에서는 몇 가지 힌트를 얻을 수 있습니다.
감사합니다.
해당 내용을 읽었지만 제 문제를 해결하기 위해 어떤 명령어나 쿼리를 실행해야 하는지 모르겠습니다.
Sam
결국, 인덱스를 다시 구축하고 재인덱싱이 가능할 때까지 문제를 일으키는 항목을 계속 삭제해야 합니다. 현재 진행 중인 작업은 올바른 방향이지만, 중복된 항목에 대해 이 과정을 반복해야 합니다.
예산이 있다면 Marketplace 채널에 게시물을 올릴 수 있습니다.
Jay, 안녕하세요.
영국에서는 이러한 문제를 해결하기 위해 데이터베이스를 제3자에게 공개하는 것이 불법입니다. 설령 합법적이라고 해도, 사용자 프라이버시 보호를 위해 그렇게 할 의사는 전혀 없습니다.
저 역시 오픈소스 유지보수자로서, 이 문제를 Marketplace 채널로 가져가는 것은 실망스럽습니다. 특히 Discourse가 Docker 컨테이너에 번들링한 Postgres 업데이트로 인해 문제가 발생했다는 점이 암묵적으로 인정되고 있는 상황에서 더욱 그렇습니다. 우리는 밀접하게 결합된 의존성을 이해하고 있으며, 버전 및 의존성 관리를 Discourse 팀의 전문성에 위임하고자 Docker 컨테이너를 통해 Discourse를 사용하고 있습니다.
이것이 Postgres 12의 회귀(regression) 문제라는 점에는 동의하는 분위기이며, 몇 가지 잠재적인 완화 방안도 있습니다. 그러나 첫 보고가 1년 이상 전에 이루어졌고, 향후 백업을 복원하려는 사용자들이 더 발생할 것으로 확신합니다.
저는 이 문제를 Discourse 상류(upstream)에서 수정하기 위해 개발 시간을 후원하는 쪽을 선호합니다. 그러면 다른 사용자들도 이 수정의 혜택을 볼 수 있을 것입니다. 그 동안 우리 포럼은 기능이 정지된 상태이며, Postgres DBA 지식을 가진 전문가의 도움을 구해야 할 것입니다.
감사합니다.
Sam
샘, 안녕.
네가 직접 문제를 해결할 수 있도록 충분한 설명을 드리지 못해서 죄송해. 하지만 네가 그렇게 들렸어. 포럼을 다시 온라인으로 되돌릴 수 있는 다른 방법들이 있다는 게 실망보다는 안도감이 될 것 같다고 생각했어.
감사합니다
제이, 안녕
전혀 그렇지 않습니다. 제게 무언가를 빚진 것도 아니지만, 게시글 히스토리를 고려할 때 빠른 해결책이 있을 거라고 기대했고, 게시글들이 결정적인 답변처럼 보였으며 해당 주제가 닫혀 있었다는 점을 들어 제가 뻔한 것을 놓쳤다고 가정했습니다.
진행 상황을 알려드리겠습니다.
감사합니다
샘
불행히도 이 문제는 우리에게 여전히 남아 있으며, 서버를 이전할 수 없어 상당히 우려스럽습니다.
이 문제를 해결해 줄 사람에게 비용을 지불하는 데에는 기꺼이 동의하지만, 이 문제와 관련하여 포럼에서 여러 차례 인정을 받았음에도 명확한 해결책이 제시되지 않은 점을 고려할 때, Discourse보다 기능이 많지는 않더라도 LAMP 기반이라 웹 개발자가 아닌 제가 직접 관리할 수 있는 Flarum 같은 다른 포럼 소프트웨어로 이전하는 것을 진지하게 고려하고 있습니다.
Discourse Docker 컨테이너를 사용할 때 우리는 지원이 제공될 것이라고 기대했습니다. 만약 모든 것을 개별적으로 배포하고 자체 Postgres 버전을 사용했다면 그런 반응을 이해할 수 있었을 것입니다. 하지만 지금까지 우리는 여러분이 권장하고 직접 제공한 환경을 그대로 사용해 왔으며, 이제 새로운 서버로 이전하는 데 큰 어려움을 겪고 있습니다(가까운 시일에 기한이 다가오고 있습니다).
현재로서는 제 최선의 선택은 Docker 볼륨 백업 및 복원입니다. Discourse의 백업은 사용할 수 없기 때문입니다. 이것 또한 우려스러운 점입니다. 매일 백업이 생성되고 있지만, 실제로는 새로운 Discourse 환경에 복원할 수 없습니다. 가까운 미래에 이러한 문제를 겪게 될 다른 사용자가 얼마나 될지 궁금합니다.
Sam
Postgres에는 손상된 인덱스를 유발할 수 있는 버그가 실제로 꽤 많았습니다. 대부분은 Postgres 13.x에서 해결된 것으로 보입니다.