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 10382 게시물 읽기
No. 10382
ERROR: uncommitted xmin 4194661 from before xid cutoff 62528296 needs to be frozen 관련 문의 사항
작성자
반지현(bjih)
작성일
2023-01-12 01:22
조회수
211

안녕하세요 PostgreSQL 12.10 유지보수 하는 엔지니어 입니다.


고객사 DB에서 아래와 같은 에러가 발생했는데요 


(24948)] ERROR: uncommitted xmin 4194661 from before xid cutoff 12528296 needs to be frozen

(24971)] CONTEXT: automatic vacuum of table userdb.pg_catalog.pg_shdepend


위 두 메시지가 autovacuum 실행될 때마다 표시가 되고 있습니다.


문의 1: 위 에러를 보면 xid 값 문제 같은데 vaccum freeze나 vacuum full로 해결할 수 있나요?


문의2: 먼저 확인해야할 설정값은 정확히 무엇인가요?


문의3: 당장 DB 운영에는 문제가 없는 상황인데 그대로 놔두면 어떻게 되나요?


문의4: 해결방법이 어떻게 되는지 궁금합니다.

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

데이터베이스가 깨지면 다음 사용할 트랜잭션 번호가 왕창 커지게 되면서

autovacuum freezing 작업을 하는 일이 발생합니다.

그런 상황인 것 같네요.


이 경우 그 문제의 테이블이 사용자 테이블이고, 해당 테이블에서 그 자료를 지워도 되는 상황이면  참 다행인데,

지금 질문의 경우는 하필이면, 전역 테이블입니다. 제 생각으로는 dump & restore 방법 밖에는 없어보입니다.


1. vacuum full 로도 될까싶은데, 한번 해보세요. freeze로는 안풀릴겁니다.

2. 트랜잭션 로그 관련 설정값은 대부분 기본값일 터이니 따로 보아야할 것은 없습니다. 

3. 가만 놔두면, 사용할 수 있는 트랜잭션 번호를 다 사용해서 db가 읽기전용으로 바뀝니다.

4. 극단적인 상황은 새로운 디비 인스턴스를 만들고 (새로운 데이터베이스 서버를 만들고) 기존 자료를 dump해서 새 인스턴스에 부어넣어야할 것 같네요. pg_shdepend 테이블은 전역 테이블이라서 해당 xmin 또는 xmax 값의 자료를 찾아서 정리하는 것이 우선인것 같습니다.


 

김상기(ioseph)님이 2023-01-12 17:08에 작성한 댓글입니다.

김상기님

이런 경우 레플리케이션을 운영으로 전환하는게 나을 것 같은데 

레플리케이션이 있다면, 그 레플리케이션DB 도 마스터 전환하면 같은 문제가 나올까요? 

(문제가 없을 것이라 생각합니다만) 


예전에 다른 테이블이 비슷한 메시지 나왔는데 해당 테이블만 freezing 이 

되어서, 리네임 방식으로 그 테이블을 지우고 다시 만드니 해결되었습니다. 

당시에도 원인을 알 수 없다고 했는데, postgresql 에서 이런 점은 약간 걱정이 되네요. 


pg 전역 테이블이 문제가 되고 있고, DB가 깨진 상황도 될 수 있다는데서

운영하는 입장에서 많이 걱정이 됩니다. 

레플리케이션 구성상태에서 이상 없다면, 주기적으로 교체하고 다시 레플리케이션을 만드는 방안도 고려해야겠네요. 

 

나그네님이 2023-01-13 08:52에 작성한 댓글입니다. Edit

그러게 말입니다. 이 불안한 DB를, 원인 분석도 어려운 이런 데이터베이스를 왜 쓰나 모르겠어요.

김상기(ioseph)님이 2023-01-13 10:02에 작성한 댓글입니다.

답변 감사합니다

여기가 replication 상태인 곳이라 standby 서버를 primary로 변경해서 해보려고 했으나 standby도 같은현상이 발생하네요​​​​


결국 pg_dump로 전체 재복구 하는걸로 방향을 잡긴 했는데..엔진 업데이트로 이런 문제 나오지 않을거라는 보장이 있을까요...?

반지현(bjih)님이 2023-01-18 13:46에 작성한 댓글입니다.

pg 설치시에 표준 설치(yum, 설치파일 실행) 방식으로 하셨는지, 

아니면 컴파일 방식으로 하셨는지 여쭈어 봐도 될까요? 


DB 정지 후

pg_shdepend 테이블 백업 후 재생성은 안되는지요? 


vauum DB명 - 작업을 주기적으로 하시는지 궁금합니다. 

 

나그네님이 2023-01-18 14:43에 작성한 댓글입니다.
이 댓글은 2023-01-18 14:53에 마지막으로 수정되었습니다. Edit

1. rpm으로 설치했습니다

2. 테이블 재생성 작업은 해보지 않았습니다

3. vacuum을 정기적으로 하고 있지는 않습니다

반지현(bjih)님이 2023-01-18 22:33에 작성한 댓글입니다.

관련 내용에 대해 찾아보니 

pg_shdepend 테이블이 bloting 사례가 보입니다. 

해결 방안은 vacuum 을 하라는 것이지요. 


관련이 있는줄은 모르겠지만, 인덱스 rebuild 에 대해서는 

다음과 같은 문장이 있습니다. 

(standalone server 모드를 어떻게 하는줄은 모르겠습니다) 


standalone server must be used to repair it.


https://www.postgresql.org/docs/8.1/sql-reindex.html

If corruption is suspected in the indexes of any of the shared system catalogs (which are pg_authidpg_auth_memberspg_databasepg_pltemplatepg_shdepend, and pg_tablespace), then a standalone server must be used to repair it. REINDEX will not process shared catalogs in multiuser mode.


트랜잭션이 깨진 이유는 모르겠지만, 

이전에 비슷한 경험을 했었는데 


1) 테이블 리네임 및 문제 테이블 제거 

서비스의 테이블 접속  - 해당 테이블 데이터 백업(vacuum full 로 해결 안됨) -

신규 테이블 생성 - 신규 테이블에 데이터 migration - 원본 테이블 삭제 - 테이블 리네임 


2) vacuum analyze DB명 : 일주일 2회 이상 수행 or 1일 1회 수행 


으로 처리하였습니다. 이후로는 문제가 생기지 않았습니다. 


 

나그네님이 2023-01-19 09:13에 작성한 댓글입니다. Edit

답변 감사합니다

​​​저도 검토 해봐야 겠네요

반지현(bjih)님이 2023-01-19 12:47에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
10385pgpass 에 패스워드를 md5 로 저장하는 방법 문의
나그네
2023-01-30
16
10384똠양꿍 저장시 한글깨짐 증상 문의 [1]
설영기
2023-01-27
35
10383[질문] logical replication 구성에서, 복제 time-stamp를 확인하고 싶습니다. [1]
이창규
2023-01-26
37
10382ERROR: uncommitted xmin 4194661 from before xid cutoff 62528296 needs to be frozen 관련 문의 사항 [8]
반지현
2023-01-12
211
10381Postgresql Auto Failover (PAF) 관련 질문 [1]
카비
2023-01-02
423
10358[디린이] Postgresql13 DB계정 권한 변경하는 방법 [1]
디린이
2022-12-26
386
10356데이터 분석함수(집계, 그룹, 윈도우, ..) 중복 사용법 질문 [2]
포스트그레스
2022-12-14
494
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2022 DSN, All rights reserved.
작업시간: 0.063초, 이곳 서비스는
	PostgreSQL v14.2로 자료를 관리합니다