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 9379 게시물 읽기
No. 9379
postgresql 백업 복구 관련 문의
작성자
이성필(splee75)
작성일
2013-12-03 18:08
조회수
12,031
안녕하세요. 다시 도움을 받고자 질문을 드리게 되었습니다.
 
문제의 원인은 아래 링크에서 확인하시면 됩니다.
http://database.sarang.net/index.php?inc=read&aid=9377&criteria=pgsql&subcrit=qna&id=&limit=20&keyword=&page=1
 
위 사항에 관한 진행 경과를 말씀드립니다.
 
예상대로 vacuum으로 해결이 안되었습니다. vacuum analyze 를 실행하여 남은 트랜잭션 수를 줄여 0까지 만들었지만.. 다음 vacuum에서 다시 40억으로 늘어난 숫자를 메시지로 보여 줍니다.
vacuum은 포기하고, 물리백업 (pg_start_backup, pg_stop_backup, rsync를 이용하여 백업)을 복구했습니다.
결과는 실패(동일한 메시지를 내보내며 dml, ddl 이 안됨)... 
 
눈물을 흘리며 논리백업(pg_dump 했던 파일)으로 데이터베이스를 재생성 합니다.
1. $PGDATA 의 파일을 제거
2. 다른 테이블스페이스의 파일 제거
3. initdb 
4. 논리백업(pg_dump 했던 파일)을 psql을 이용하여 실행.
반쯤... 실행되며... 거의 성공할 듯 합니다. 스키마 별로 백업을 했는데, 30여개의 스키마 중 2/3 가 성공했고... 나머지 크기가 큰 넘들만 남은 상태입니다.
 
현재 상황을 좀 자세히 기술하자면 아래와 같습니다.
CentOS 6.3 (64bit)
Postgresql-9.2
데이터베이스 크기는 약 4TB~5TB
데이터베이스 1개 아래에 30~40개 정도의 스키마.
autovacuum 은 실행중.
default_with_oids 는 off 로 설정되어 있음.
insert 이외의 dml은 극히 적은 상황.
이런 상황에서도 vacuum을 메뉴얼하게 해야 하는 걸까요?
크기가 좀 커져서 autovacuum으로는 부족하고 full vacuum을 주기적으로 실행해야 할 필요가 있는지 궁금합니다.
혹시 그런 판단을 할 만한 작업이 있는지도 궁금합니다.
 
또 한가지는... 
현재 만일의 상황에 대비해서 일주일에 한번 논리백업(pg_dump), 하루에 한번 물리백업(pg_start_backup, pg_stop_backup, rsync를 이용하여 백업)을 수행했습니다.
보다 빠른 복구를 위해서 혹시 더 나은 백업정책이나 방법이 있을가요?
 
위의 오류가 발생했을 당시의 물리백업으로는 정상적인 복구가 안되는 것으로 판단되었습니다. 
제 짧은 생각으로는 해당 데이터베이스 파일에 문제가 발생했던 것인데... 문제가 발생한 상태를 백업한 것을 그대로 복구했으니 정상적인 데이터베이스 상태를 만들지 못한것이라 예상됩니다.
제 생각이 맞는 걸까요?
 
선배님들의 조언 부탁드립니다.
 
이 글에 대한 댓글이 총 1건 있습니다.

 죄송합니다. 

제가 지난 번 글을 그냥 너무 쉽게 읽었네요, 

oid overflow 문제가 아니라, 트랜잭션 id overflow 문제였네요. 

이것은 commit 되지 않은, commit 되어도 checkpoint 작업이 정리가 덜 된 자료들이 한 테이블 안에 너무 많이 있으면 생기는 문제이기도 하고, 

빈번한 update, delete 작업이 있었는데, vacuum 작업이 일어나지 않아서 발생하는 문제이기도 합니다. 

 

autovacuum 작업 관련 로그를 남겨서, 해당 테이블의 vacuum 작업에 문제가 없는지 살펴보는 것이 첫번째 일인것같네요. 

문제가 있다면, 어디서 문제가 생겼는지 - 일반적으로 너무 잦은 dml 작업으로 vacuum 작업이 계속 지연 되어서 발생합니다. - 살펴보고 그 문제를 피해가거나(수동 vacuum) 다른 해결방법을 찾아야겠죠.

 

vacuum full 작업은 디스크 공간이 부족해서 최악의 상황일때 하는 작업입니다. 

디스크 공간이 넉넉하다면, 그냥 vacuum 만으로 충분합니다. 

 

일반적인 pg_start_backup을 이용한 데이터클러스터 백업은 

베이스백업가 아카이브 백업을 분리해서 생각하는데, 

대부분의 기업에서는 일주일에 한번 정도 베이스백업을, 매일또는 매시간 아카이브백업을 진행합니다. 

잦은 아카이브백업을 하면 백업량을 줄이는 효과가 있겠지만, 복구도 그 아카이브 조각 파일들을 다 반영해야하는 시간이 걸리겠죠. 

이런 저런 것들을 감안해서 최적의 백업정책은 해당 시스템에 맞게 스스로 찾으셔야할 것 같습니다.

 

 

김상기(ioseph)님이 2013-12-07 02:04에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
9382select시 질문입니다. [1]
한동율
2013-12-07
10482
9381맥에서 Pgsql 한국어 인터페이스 설정 방법? [1]
souler
2013-12-06
10500
9380postgresql 8.3 dblink 문의 [1]
김주왕
2013-12-05
10869
9379postgresql 백업 복구 관련 문의 [1]
이성필
2013-12-03
12031
9378현재사용하고있는 port 알수있을까요? [1]
강성구
2013-11-28
10329
9377To avoid a database shutdown, execute a database-wide VACUUM in that database [3]
이성필
2013-11-27
11433
9376복제 문의 [2]
남동균
2013-11-17
10814
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.048초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다