데이터베이스를 사랑하는 사람들의 모임 데이터베이스 사랑넷

PostgreSQL Q&A 9673 게시물 읽기

No. 9673

Replication failover 관련 질문드립니다.
작성자	황하진	작성일	2016-06-30 11:27	조회수	8,709

pacemaker+replication 으로 이중화 구성 후 failover 테스트 중인데

테스트 진행 중간 중간 아래와 같은 에러로 동기화가 깨지네요..

< 2016-06-30 11:05:08.031 KST >LOG: entering standby mode

cp: cannot stat `/var/lib/pgsql/9.4/pg_archive/00000073.history': 그런 파일이나 디렉터리가 없습니다

cp: cannot stat `/var/lib/pgsql/9.4/pg_archive/000000730000000300000083': 그런 파일이나 디렉터리가 없습니다

< 2016-06-30 11:05:08.075 KST >LOG: redo starts at 3/83000028

< 2016-06-30 11:05:08.196 KST >LOG: consistent recovery state reached at 3/8340B2B8

< 2016-06-30 11:05:08.199 KST >LOG: database system is ready to accept read only connections

위와 같은 상황이 발생하면 그냥 slave 재 설정했는데

다른 방법이 없을까요? 저 상황을 좀 해결하고 싶네요..

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

스트리밍 복제에서 대기 서버 쪽이 비록 늦더라도 꼭 자료가 모두 복제 되어야 하는 상황이라면,

postgresql.conf 파일의 설정값 가운데 두 개는 수정 되어야 합니다.

max_standby_streaming_delay = -1

hot_standby_feedback = on

또한 take over 작업도 고려한다면,

recovery.conf 파일에,

recovery_target_timeline = 'latest'

설정도 포함되어야 합니다.

그럼에도 불구하고, 복제 실패가 일어난다면,

9.5 버전으로 올리면, pg_rewind 명령을 이용해서 좀 더 편하게 대기 서버를 구축할 수도 있습니다.

9.4 이하 버전이면, vmware 에서 만든, github에 있는 pg_rewind 확장 프로그램을 이용해서

이 작업을 진행할 수 있습니다.

김상기(ioseph)님이 2016-06-30 14:34에 작성한 댓글입니다.

김상기님 답변 감사합니다.

말씀해주신 설정은 Replication 구성 시 설정한 상태입니다.

위 문제는 말씀해주신 설정을 한 상태에서 발생해서 재 동기화하는 방법이나

다른 해결방안이 혹시 있는지 알 수 있을까요?

현재는 위와 같은 문제가 발생하면 Slave를 다시 설정하는 방법으로 하고있긴 하지만

비효율적이라..

황하진님이 2016-07-01 11:48에 작성한 댓글입니다. Edit Ｘ

3/8340B2B8

이후 트랜잭션 로그를 더 이상 못 받고 있는 상황이고,

운영 서버쪽에서는 이미 그 트랜잭션 로그는 버린 상태라면 해결책이 없습니다.

이런 문제의 가장 근본적인 해결책은 아주 오래된 트랜잭션 로그까지 운영 서버가 가지고 있으면 되겠지요.

이 부분의 대안이 복제 슬롯입니다.

http://postgresql.kr/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS

페이지를 보시고 복제 슬롯을 사용하고 있지 않다면, 사용해 보시는 것도 도움이 되지 않을까싶습니다.

복제 슬롯 기능를 이용한 pg를 pacemaker랑 붙혀 보지는 못했습니다.

그 부분은 직접 해결 하셔야 할듯싶네요.

김상기(ioseph)님이 2016-07-01 13:58에 작성한 댓글입니다.

김상기님 답변 감사합니다

현재 아래와 같은 문제로 Slave와 동기화가 안되는거 같습니다.

< 2016-07-05 10:32:17.167 KST >DETAIL: Latest checkpoint is at 0/4A9EE30 on timeline 24, but in the history of the requested timeline, the server forked off from that timeline at 0/4A9EE30.

위와 같이 timeline이 달라질때 문제를 해결하는 방법을 알 수 있을까요?

황하진님이 2016-07-05 10:34에 작성한 댓글입니다. Edit Ｘ

일반적으로 타임라인 증가에 따른 자동 타임라인 계산은

recovery.conf 파일에

recovery_target_timeline = 'latest'

이 설정이 포함되어 있으면 되는데요.

이 설정에도 불구하고, history 파일이 없다면, 운영 서버 쪽 history 파일을 보관하고 있지 못했던 원인을 찾아야합니다.

첫번째 원인은

대기 서버의 promote 작업이 기존 운영 서버 정상 중지 되기 전에 있었고,

이제 더이상 운영 서버가 아닌 서버를 대기 서버로 사용하기 위해서 대기 서버 구축 작업 없이 그대로

recovery.conf 파일만 가지고 대기서버로 운영 하려고 하려고 하면, 트랜잭션 번호랑 타임라인이 맞지 않다고 오류를 냅니다.

이 경우는 pg_rewind 명령으로 새 운영 서버 기준으로 동기화 작업을 해야 합니다.

pacemaker 에서 resource take over (switch over라고도 함)를 한다면,

반드시 기존 운영 서버가 정상 중지 되어야 take over 다음 옛 운영 서버를 대기서버로 기동하는 작업을 별 다른 작업 없이 가능합니다.

다음 원인은

복제 슬롯 없이 복제환경을 구축했고, 운영 서버와 대기 서버의 트랜잭션 차이가 너무 심한 상태에서

운영 서버는 트랜잭션 로그를 아카이브쪽으로 보내버린 경우입니다.

이 경우는 운영 서버의 아카이브 조각 파일들을 수동으로 대기서버 쪽으로 보내주어야 계속 진행하겠지요.

이들 말고 또 다른 원인이 다양하게 있을겝니다.

고가용성 이라는게 워낙 다양한 상황이 있어서.

일단 왜 히스토리 파일이 없어졌는지에 대한 원인을 찾으셔야합니다.

김상기(ioseph)님이 2016-07-05 14:52에 작성한 댓글입니다.

[Top]

No.	제목	작성자	작성일	조회
9676	query [1]	학생	2016-07-19	7841
9675	pgday.seoul 2016 발표자 모집	김상기	2016-07-14	9096
9674	테이블 접근 기록 [3]	꿈나무	2016-07-05	8133
9673	Replication failover 관련 질문드립니다. [5]	황하진	2016-06-30	8709
9672	Postgres Database와 WebPage를 연동할 수 있나요? [2]	JungHo Kim	2016-06-22	7987
9671	PGDay.Seoul 2016 행사 날짜 투표해주세요.	김상기	2016-06-21	9004
9670	declare에서 syntex error가 나는데 이유를 모르겠네요...도와주세요 [1]	늅늅이	2016-06-10	8538