재 실행해야할 미리쓰기로그(write ahead log)조차 깨졌나봅니다.

1. 백업 받은 것으로 복구(백업 시점까지만 자료를 구할 수 있겠죠)

2. 미리쓰기로그를 다 버리고, reset (마지막 체크포인트 시점까지만 자료를 구할 수 있겠죠)

둘 중 하나를 선택해야할 시점 같네요.

첫번째 방법은 데이터베이스 관리자로 연습해둔 백업과 복구 능력을 발휘할 때고,

두번째 방법은 pg_resetwal OS 명령어로 처리합니다. (충분히 데이터베이스가 망가질 수 있음으로 잘 진행하셔야합니다. 이미 망가진것 어떻게든 살려보는데까지 살려보자는 심정으로 진행하는 작업입니다.) 물론 이렇게 해서 데이터베이스가 정상 실행되었다고 해도 믿으면 안됩니다. 데이터베이스 전체 vacuum 명령으로 전체 자료가 잘 저장 되었고 접근이 가능한지 파악해야하고, 각종 오류 메시지가 보이면 그에 맞는 적절한 조치를 취해야합니다.  워낙 다양한 경우가 발생할 가능성이 있어, 하나 하나 꼼꼼히 조치 방법을 알려드리기가 참 그렇네요. 나만의 노하우라고 꽁꽁 숨기는게 아니라, 게을러서 그 상황별 대처 방법을 다 기록해서 공개하지 못한 탓입니다.

이곳 게시판을 뒤져보시면 혹 힌트가 될 만한 글들을 발견하실 수 도 있습니다.
그 때 그때 구체적인 상황 수습에 대해서는 대부분 답변이 달려있을테니까요.

결국  pg_resetwal 진행하였는데 감이 안옵니다 .. 

현재 상태 입니다. 

2020-09-24 23:09:12.869 KST [24149] 로그:  IPv4, 주소: "0.0.0.0", 포트 9432 번으로 접속을 허용합니다

2020-09-24 23:09:12.869 KST [24149] 로그:  IPv6, 주소: "::", 포트 9432 번으로 접속을 허용합니다

2020-09-24 23:09:12.870 KST [24149] 로그:  "/tmp/.s.PGSQL.9432" 유닉스 도메인 소켓으로 접속을 허용합니다

2020-09-24 23:09:12.944 KST [24150] 로그:  데이터베이스 시스템 마지막 가동 중지 시각: 2020-09-24 23:08:28 KST

2020-09-24 23:09:12.947 KST [24149] 로그:  이제 데이터베이스 서버로 접속할 수 있습니다

 done

server started

[postgres@trep1 bin]$ 2020-09-24 23:09:13.012 KST [24158] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:13.091 KST [24159] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:13.095 KST [24160] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:13.095 KST [24161] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:13.326 KST [24162] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:18.189 KST [24168] 치명적오류:  cache lookup failed for index 2662

2020-09-24 23:09:18.905 KST [24169] 치명적오류:  cache lookup failed for index 2662

어떻게 자료를 살리면서 인덱스 다시 만드는 방법

https://stackoverflow.com/questions/47704816/postgres-pg-dump-cache-lookup-failed-for-index

궁금한게 있는데요, 
정전과 같은 상황, 아니면 백그라운드 프로세스 등이 내려간 상황 등에서 
pg 가 자동 셧다운 후 스타트업이 되는데 

사용자는 아무것도 하지 않았다는 가정하에서, 

이런 경우 지금과 같이 
ahead wal 이 커럽션, 유실 되는 케이스가 있나요? 

그래서, fsync = on , synchronous_commit = on 설정이 기본값입니다.

이 말은 데이터베이스 서버에서 할 수 있는 것은 다 했다. 그 나머지 몫은 OS와 하드웨어의 몫이다.

이 말입니다.

즉, 이 기본 설정을 했음에도 불구하고, 특정 파일이 깨졌는 경우는 데이터베이스의 문제 범위를 벗어났다는 것을 의미합니다.

또 다시 원래 질문으로 가서,

정전이나, 예상치 못한 장애로 디스크에 있는 파일이 깨질 수 있는가? 라는 아주 원론적인 질문과 같게 됩니다.
답은 이미 잘 알고 계실 거라고 믿습니다. :)

그럼 디스크에 쓰여진 파일이 어떤 상황에서도 안 깨지게 보호 할 수 있는가?

이런 지극히 하드웨어적인 이야기로 넘어가게 됩니다. 몇가지 전통적인 방법(아주 오래전부터 컴퓨터 장비 팔아서 먹고 사는 동네에서 해 오던 방법)들이 있고,

요즘은 이런 복잡한 문제를 고민하기 싫으니, 돈만 내고 대형 클라우드를 사용해서 디스크 깨지는 문제는 난 돈을 냈으니 니가 알아서 해라. 이런 식일 수도 있습니다.

마지막으로 가장 저렴하고, 손이 많이 가는 방법은 윗 모든 보호 기법들을 스스로 다 공부해서 스스로 열심히 자기자료를 지키는 방법일 것이고요.

아무튼

데이터베이스 서버 입장에서는 , fsync = on , synchronous_commit = on 이 설정이라면 데이터베이스 차원에서 자료를 보호하는 것은 다했다. 입니다.