database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 10185 게시물 읽기
No. 10185
데이터베이스 pg_ctl reload 후 아래와 같이 시작이 되지 않습니다. 도움 부탁드립니다.
작성자
db초급
작성일
2020-09-24 20:58
조회수
2,411

 

재시작 이후 아래와 같이 복구진행, 시스템만 새롭게 가동되고 시작은 되지 않습니다. 

정확한 원인도 찾기 힘들게 되었는데 의견 부탁드립니다. 

 

 

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

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

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

2020-09-24 20:46:18.825 KST [14374] 로그:  복구 중 데이터베이스 시스템 마지막 가동 중지 시각: 2020-09-24 20:44:00 KST

2020-09-24 20:46:18.825 KST [14374] 로그:  데이터베이스 시스템이 정상적으로 종료되지 못했습니다, 자동 복구 작업을 진행합니다

2020-09-24 20:46:18.827 KST [14374] 로그:  93/4A0859B8에서 redo 작업 시작됨

2020-09-24 20:46:19.209 KST [14375] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

2020-09-24 20:46:19.229 KST [14376] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

2020-09-24 20:46:19.238 KST [14377] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

......2020-09-24 20:46:24.793 KST [14382] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

.2020-09-24 20:46:26.009 KST [14392] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

2020-09-24 20:46:26.014 KST [14393] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

.2020-09-24 20:46:26.933 KST [14395] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

2020-09-24 20:46:27.077 KST [14396] 치명적오류:  데이터베이스 시스템이 새로 가동 중입니다.

..^C2020-09-24 20:46:29.130 KST [14373] 로그:  fast 중지 요청을 받았습니다.

[postgres@trep1 bin]$ 2020-09-24 20:46:29.148 KST [14399] 로그:  서비스를 멈추고 있습니다

 

이 글에 대한 댓글이 총 5건 있습니다.

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

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

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

 

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

 

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

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

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

 

김상기(ioseph)님이 2020-09-24 21:50에 작성한 댓글입니다.

결국  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

 

db 초급님이 2020-09-24 23:15에 작성한 댓글입니다. Edit

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

 

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

김상기(ioseph)님이 2020-09-25 02:25에 작성한 댓글입니다.
이 댓글은 2020-09-25 02:26에 마지막으로 수정되었습니다.

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

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

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

lucky님이 2020-09-25 17:00에 작성한 댓글입니다. Edit

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

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

이 말입니다.

 

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

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

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

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

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

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

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

아무튼

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

김상기(ioseph)님이 2020-09-25 22:14에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
10195Win10에서 설치 에러 [2]
전상도
2020-10-19
1928
10188Function 내의 검색 값 적용 시키기. [1]
레인버그
2020-10-09
1444
10187이곳 데이터베이스 서버 업그레이드 작업이 있었습니다 [1]
김상기
2020-10-02
1554
10185데이터베이스 pg_ctl reload 후 아래와 같이 시작이 되지 않습니다. 도움 부탁드립니다. [5]
db초급
2020-09-24
2411
10184postgres polygon질문 [1]
익이
2020-09-22
1832
10183리눅스 centos5 버전에 설치할수있는 모듈이젠 구할수없나요? [1]
이기자
2020-09-21
1576
10182인코딩 오류 이유를 알고계신분 잇나요 [1]
김철중
2020-09-21
2655
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.052초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다