lock 을 살펴본 쿼리 입니다.

해당 작업은 디스크를 쓰는 작업입니다.

디스크 입출력에 문제가 생겼나봅니다.

장애가 더 확대되기 전에 먼저 데이터베이스를 중지하고,

해당 데이터가 보관디는 디스크 볼륨의 파일 시스템 검사를 해야 할 것 같습니다.

해당 작업 권한이 없다면,

create 작업을 하는 세션 프로세스의 프로세스 상태를 담당자에게 보여주세요.

아마 Ds (Dead Sleep) 상태일것입니다.

이 상태는 해당 프로세스가  데이터베이스 서버 작업을 떠나 OS 차원에서 중지되고 있는 것을 의미하거든요. 

네트워크 통신 오류나, 디스크 입출력 오류 때 주로 발생합니다.

 소중한 답변 감사합니다.

프로세스 상태는 Rs 입니다. cpu도.. 좀 쓰는 것 같고... 아래는 ps -aux 로 본 정보 입니다.

혹시 pg_log 이외에 참고할 만한 상태 정보를 알 수 있는 방법이 있나요?

lock 때문에 대기 상태면, 프로세스 상태가 Ss 로 바뀝니다.

R 상태라는게 이상하네요.

그렇다면, 트랜잭션 로그쪽 문제로 봐야하는데, 이도 DML 작업이 잘 일어난다고 하니, 아닐 것이고,

혹 참조키가 있어 그 참조하는 테이블 쪽에서 실마리를 찾아볼 수도 있겠네요.

( 그럼에도 불구하고, 저는 디스크 I/O 쪽으로 의심이 제일 많이 갑니다. OS dmesg 같은 OS 로그를 살펴보는 것도 좋을 것 같습니다.)

명확하게 DB문제로 보인다면, 디버그 모드로 재 컴파일하고, gdb attach 로 어느 부분에서 작업이 멈춰있는지 살펴보는 방법 밖에는 없어보입니다. (일단은 gdb 로 바로 attach 해서 backtrace  보는 것도 급하게 할 수 있는 조치입니다.)

 현재 데이터베이스의 물리 백업 을 다른 서버에 복구하여 동일한 상황을 만들고 이것 저것 테스트 중입니다.

일주일 전의 논리 백업 이 있기는 한데...  이것으로 복구하면, 데이터를 맞추어 줄 수없어서 pg_dump 가 사용 가능한지 확인 했지만... pg_dump 가 사용이 안되는 상황입니다.

다른 부분은 이상이 없고, 테이블 생성 등의 부분이 이상이 있으므로... reindex system [dbname] force; 를 실행하고 결과를 기다리는 중입니다만... 상당히 오래 걸리네요.. 문제는 이 구문이 실행되는 동안 데이터베이스의 다른 연결을 허용하지 않는 듯 합니다. 

ps -aux 로 프로세스 상태를 보면.. Rs 이고.. cpu 도 많이 쓰고.. 해서 놀고 있지는 않은데... 조급해서 그런지 실행시간이 상당히 오래 걸리는 것 같습니다.

혹시 다른 방법이 생각 나는 것이 있으면... 알려주셨으면 합니다.

김상기님께서 말씀해 주신 gdb 는... 저에게 너무 어려운 내용이라 ... 테스트 하다 끝을 보지 못했습니다. 그래도 시도의 방법을 알려주셔서 감사합니다.

 혹시나 해서 제가 gdb로 테스트한 내용을 올립니다.

-----------------------------------

 안녕하세요. 장애 원인이 밝혀져서 처리 및 후속조치에 들어가 결과를 공유하고자 글을 남깁니다.

원인은 공유 스토리지의 마운트가 잘못되어 있었던 것으로 밝혀졌습니다.

현재 두대의 postgresql에 하나의 스토리지를 영역이 다르게 NAS로 연결해서 데이터 디렉토리(테이블 스페이스)로 사용하고 있습니다. 이런 구성의 효율 및 안정성이 좋지 못하다는 것은 알고 있지만... 최초 프로젝트 출발시에는 이런 저런 환경을 따져서가면서 시작을 할 수 없는 상황이었지요. 구성에 대한 히스토리 및 우여곡절은 넘어가고...

두대중 한대는 항상 서비스 온 상태이고, 한대는 필요시만 서비스가 온 되는 상황입니다.

두대의 데이터베이스 인스턴스에서 각각 일부의 마운트 포인트를 공유하면서 다른쪽 데이터베이스가 서비스 온 상태이거나 해당 데이터 디렉토리에 무언가 작업을 할 때 다른 쪽 데이터베이스가 파일을 점유하고 있어서 대기 상태에 빠진것으로 추측됩니다. 그래서 제가 복구하려고 시도한 데이터베이스에서 테이블 을 생성하려고 하면 시스템 카탈로그를 갱신해야 하고 그럴러면 모든 테이블스페이스를 다 뒤지는 것 같은데... 그 때 대기상태로 계속 기다리는 것 같습니다.

다행히도 그쪽 테이블 스페이스에 직접적으로 데이터 변경행위를 한 것이 없어서 복구에 큰 문제는 없어보입니다.  복구 방법은 각각 독립된 데이터디렉토리로 다시 마운트되도록 설정하고, reindex system 으로 시스템 카탈로그를 리인덱스 했습니다. 그 후 테이블 생성이 잘 되었습니다. 혹시 몰라 해당 데이터디렉토리의 테이블 전체를 리인덱스 중입니다.

여러가지 방법을 제안해 주신 김상기(ioseph)님께 다시 한번 감사드립니다.

 전통적으로 DB의 자료는 NAS에 저장하지 않습니다. 

처음부터 디스크 I/O쪽이다고 말씀드렸는데, 그 부분부터 출발했다면, 디스크 I/O 쪽 설계부터 살펴보았다면 빨리 찾았을텐데 말이죠.

NAS 장애쪽은 OS 입장에서 찾기가 참 힘듭니다. 증상이 그 장치쪽으로 접근 할 때, 그 접근하는 프로세스만 딱 먹통이 되거든요. 그래서 OS 입장에서는 아무런 오류가 없는 것 처럼 보입니다.

여튼 잘 푸셨다니 다행이네요. 여건이 되면 DB 스토리지 관련을 정리하셔야겠네요.

 디스크 I/O 쪽이라고 언급을 주셔서 그나마 찾은 것이라 생각되어 김상기님께 정말 고맙게 생각합니다.  저도 NAS에서 Database를 운영하는 것은 처음이라서 이래저래 어려움이 있습니다. 다시한번 정말 감사드립니다.