첫 번째
2~3회 시도 후 (./launcher stop 또는 Portainer stop을 통해 정지하는 방식에 관계없이) 컨테이너가 다시 시작을 거부하고 “rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory” 메시지에 계속 멈춰 있습니다. (방금 소켓이 “shared” 디렉토리가 아니라 "shared/standalone"에 있다는 것을 알게 되었습니다. 이는 단순히 메시지 오류일까요?)
아직 원인이 명확하지 않지만, 이 소켓이 정지 후 어딘가에서 디렉토리로 변하고, 템플릿은 소켓을 삭제할 수는 있지만 디렉토리를 삭제할 수는 없어 삭제에 실패하는 것 같습니다. 수동으로 삭제해도 아무 변화가 없으며, 매번 다시 나타납니다.
두 번째
"./launcher rebuild app"을 실행하면 첫 번째 “PANIC could not locate a valid checkpoint record” 오류 이후 “FATAL: the database system is starting up” 단계에서 멈춥니다. 이 문제에 대해 찾을 수 있는 모든 것을 읽고 시도해 보았지만, 제가 찾은 유일한 작동하는 "해결책"은 discourse 디렉터리와 그 안의 모든 것을 삭제하고 모든 것을 처음부터 다시 설정하는 것이었습니다… 물론 이는 진정한 해결책이 아닙니다!
때때로 Discourse 컨테이너를 정지하면 데이터베이스가 불량한 상태로 남고, “is starting up” 상태이므로 진행할 수 없는 것 같습니다. 아마도 무언가를 수정하려는 시도 중일 것입니다. 하지만 이 문제가 일부 정지 및 시작 후 발생하는 이유와 해결 방법을 아직 찾지 못했습니다.
어떤 단서를 얻을 수 있을까요? Postgres가 스스로 문제를 해결하도록 하는 방법이 있을까요?
아니요, 실수가 아닙니다. 이 파일은 컨테이너에 마운트되는 볼륨 안에 있으므로, 컨테이너 내부인지 외부인지에 따라 경로가 다르게 표시됩니다.
이 문제는 컨테이너가 제대로 종료되지 않았을 때 발생합니다. PostgreSQL은 정상적으로 종료되려면 시간이 필요하며, 우리는 런처 명령으로 서비스를 중지할 때 이를 처리합니다. 하지만 인스턴스가 충분히 크거나 실행 중인 트랜잭션이 너무 많으면, 주어진 시간 내에 데이터베이스가 정상적으로 중지되지 못할 수 있습니다.
하지만 호스트 파일 시스템의 "shared/standalone"에 생성된 “nginx.http.sock” 파일도 발견했습니다. 처음에는 소켓이므로 핑크색으로 표시되지만, 잠시 후(아마도 중지 과정 중에) 디렉터리가 되어 파란색으로 바뀌고, 컨테이너는 소켓을 삭제하려는 시도에 막혀 시작을 거부합니다… 소켓이 디렉터리가 된 것이죠.
그렇다면 이를 수정하기 위해 무엇을 할 수 있을까요? 지금까지는 단순히 실험만 해왔지만, 수백 명의 사용자가 연결되고 수십만 개의 게시물이 있는 상태에서 온라인으로 운영할 때, Postgres가 갑작스러운 중단을 처리하지 못한다고 해서 모든 것을 잃을 위험이 있을까요? 손상된 데이터베이스를 수정하기 위해 해야 할 일이 있는 것 같습니다. Discourse 컨테이너가 시작되지 않을 경우 우리가 관리할 수 있는 외부 Postgres에서 Discourse를 실행할 수 있을까요? 간단히 말해, “PANIC” 또는 “FATAL” 오류가 발생하는 경우, 이를 해결할 수 있는 방법이 있어야 합니다…
실제로 문제를 (미래를 위해) 해결하기 위해, 컨테이너화된 Postgres를 설정하고 Discourse에 연결하는 방식을 시도하고 있습니다. 이렇게 하면 Discourse를 중지할 때 데이터베이스에 손상을 입히지 않거나, 적어도 Discourse가 다운되어 있더라도 일부 유지보수를 수행할 수 있기를 기대하고 있습니다.