데이터베이스 종료 지연으로 인한 재빌드 문제

제품 지원 자체 호스팅
1

권장된 업그레이드가 실패하여 포럼이 손상된 후 복구되지 않았습니다. 현재 문제를 해결하기 위해 discourse-doctor를 실행 중이며, 이마저도 실패할 경우를 대비해 VM 스냅샷을 백업해 두었습니다.

출력 내용:

2023-04-19 18:28:31.298 UTC [42] LOG:  received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG:  shutting down
2023-04-19 18:28:33.974 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
2

베타 브랜치를 사용 중이신가요?

아래 명령어로 컨테이너를 재시작해 볼 수 있습니다:

 ./launcher start app

하지만 실제로는 discourse-doctor가 이 작업을 수행해야 합니다.

에러가 포함된 출력 내용보다 위에 위치해 있으므로, 더 많은 출력 내용을 공유해 주셔야 합니다.

3

네, 저희는 베타 브랜치를 사용하고 있습니다. 항상 nohup를 통해 실행하므로 전체 로그를 가지고 있습니다.

Discourse-doctor가 아직 처리 중이지만, 아직 실패하지 않았으니 희망이 있습니다.

https://pastebin.mozilla.org/iw2zc5zd

수정: Discourse-doctor 덕분에 다시 정상 작동하게 되었습니다.

솔직히 제가 이렇게 된 것입니다. 해당 알림을 받은 지 한 시간 후에 업그레이드를 진행했고, 가장 먼저 한 사람이었으니까요. 이전 스냅샷에 대해 큰 스트레스는 없었지만, 여기서는 팀을 위해 제발 한 번 겪어 보겠습니다.

4
  • 2023-04-19 18:28:26.755 UTC [45] LOG: database system was not properly shut down; automatic recovery in progress

데이터베이스가 60초 안에 안전하게 종료되지 않으면(느린 디스크를 가진 대규모 데이터베이스에서 발생할 수 있음) 이 상태에 진입하며, 5초 안에 복구하지 못하면(대규모/느린 환경에서 드물게 발생) 재빌드(rebuild)가 실패합니다.

이 문제는 여기에 나열된 변경 사항과는 무관하며, 최소 2016년부터 Discourse에서 존재해 온 문제입니다.

5

아, 감사합니다. 우리처럼 규모가 큰 포럼의 경우 더 오래 기다리는 것이 좋을 수도 있겠네요. DB 프로세스를 단순히 종료하면 다시 시작할 때 트랜잭션을 롤백해야 하며, 이 과정에는 매우 오랜 시간이 걸릴 수 있습니다.

베타 버전에 관한 용어가 다소 혼란스럽습니다. 관리자 대시보드에는 베타 버전을 실행 중이라고 표시되어 있는데, 다른 곳에 확인해야 할 것이 있나요? 제 이해로는 릴리스 공지에서 안정 버전(stable branch) 사용을 지양하고 있기 때문에, Discourse의 경우 베타 버전이 권장된다고 알고 있습니다.

6

기본값은 실제로 tests_passed이며, 이는 프로덕션 준비가 완료된 것으로 간주됩니다.

7

데이터베이스 크기가 어느 정도인가요? SSD에 저장되어 있나요? RAM 용량은 얼마인가요?

별도의 데이터 컨테이너를 사용하면 데이터베이스 재시작 횟수를 줄일 수 있습니다.

8

안전한 종료(shutdown)를 위한 60초 대기 시간은 언제 결정되었나요? 현재 당시의 일반적 규모보다 훨씬 더 큰 설치 환경이 얼마나 많나요?

이상적으로는 이 60초 대기 시간이 제한이 있는 폐쇄 루프(closed-loop) 대기 방식이어야 합니다. 현재 취약점이 노출된 인스턴스가 많이 존재한다면, 제한 시간은 더 높게 설정되어야 할 것 같습니다.

9

105GB, SSD, 16GB VM이고, postgres에 8GB 버퍼 풀을 설정했습니다.

10

최소 2016년쯤으로 거슬러 올라가는 것 같다는 걸 본 것 같습니다. 하지만 상황이 변했습니다. 수정: 여기 새로운 커밋이 있습니다.

표준 설치의 경우, 거의 처음부터 이렇게 되어 왔기 때문에 그렇게 많지 않을 것 같습니다.

아, 네. 꽤 큰 데이터베이스네요. RDS나 최소한 별도의 컨테이너에 있지 않은这么大的 데이터베이스를 가진 사람이 몇 없을 것 같습니다. 2컨테이너 설치로 전환하는 것을 고려해 보시는 것이 좋을 것 같습니다.

11

고려해 보겠습니다. 전환 방식이 문서화되어 있나요? 그리고 60초 타이머를 늘리는 것 외에 다른 이점이 있을까요?

12

어제 10분으로 늘렸습니다

13

아니, 2016년에 원본 커밋을 올린 줄 알았네. 그럼 우리한테는 이점이 전혀 없나?

14

Move from standalone container to separate web and data containers 를 확인해 보세요.

기존 컨테이너가 계속 실행되는 동안 새 컨테이너를 빌드할 수 있습니다. 새 컨테이너를 빌드하기 위해 데이터베이스를 종료할 필요가 없습니다.

지금 postgres를 종료할 수 있는 10분간의 시간이 확보되어, 현재 문제를 해결하는 데 도움이 될 것입니다. 한 번 더 재빌드하면 1분이 아닌 10분의 시간을 확보하게 됩니다.

15

아니, 그 사람이 완전히 새로운 2컨테이너 인스턴스를 구축한 다음 백업에서 복원했대. 좋은 이유가 없으면 절대 그렇게 안 해. 나야 2개월 전에 PG13 업그레이드 시 필요한 디스크 용량 문제를 피하려고 어쩔 수 없이 그렇게 한 거야.

16

PG13을 사용하고 있지 않다면, 그 문제를 해결해야 합니다.

새로운 서버를 설정하고 이쪽으로 이전하는 것이 좋습니다.

17

결국 그것은 피할 수 없었습니다! DB 외에도 더 이상 지원되지 않는 18.04LTS에서 업그레이드해야 했습니다.

19

이 정도 크기의 db라면 전용 컨테이너로 옮기는 것이 좋습니다.

재빌드 속도가 크게 빨라지고 모든 작업이 훨씬 단순해질 것입니다.

20

그 작업을 처음부터 완전히 다시 구축하지 않고 수행하는 방법에 대한 문서가 있다면, 백업 복구를 반드시 고려하겠습니다.

21

따라서 웹 컨테이너와 데이터 컨테이너로 빠르게 분리하여 마이그레이션하시려는 것이군요