2010-01-20 4 views
0

누군가 WAL 배송 및 웜 대기 문제를 도와 줄 수 있기를 바랍니다. 내 대기 시스템은 몇 주 동안 행복하게 작동하고, 갑자기 모든 존재하지 않는 .history 파일을 찾기 시작합니다. 그런 다음 쓰레기가 나면 대기 모드를 다시 구축하지 않고 성공적으로 다시 시작할 수 없습니다.Postgres HA (WAL 배송 기준) 실패

두 시스템 모두 CentOS 4.5와 Postgres 8.4.1을 실행 중입니다. 이들은 NFS를 사용하여 프로덕션의 WAL 파일을 대기 서버에 저장합니다. 내 의견

로그의 관련 덩어리 :

[** Recovery is running normally **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001000000830000005B 
WAL file path   : /var/tafkan_backup_from_db1/00000001000000830000005B 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 00000001000000830000004D and later 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
running restore   : OK 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001000000830000005B 
WAL file path   : /var/tafkan_backup_from_db1/00000001000000830000005B 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 000000000000000000000000 and later 
running restore   : OK 

[** All of a sudden it starts looks for .history files **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000002.history 
WAL file path   : /var/tafkan_backup_from_db1/00000002.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
not restored 
history file not found 
Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000001.history 
WAL file path   : /var/tafkan_backup_from_db1/00000001.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000001.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory 
not restored 
history file not found 

[** I stopped Postgres, renamed recovery.done to recovery.conf, and restarted it. **] 

Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 00000002.history 
WAL file path   : /var/tafkan_backup_from_db1/00000002.history 
Restoring to   : pg_xlog/RECOVERYHISTORY 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY" 
Keep archive history : 000000000000000000000000 and later 
running restore   :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory 
not restored 
history file not found 
Trigger file   : /tmp/pgsql.trigger 
Waiting for WAL file : 0000000200000083000000A2 
WAL file path   : /var/tafkan_backup_from_db1/0000000200000083000000A2 
Restoring to   : pg_xlog/RECOVERYXLOG 
Sleep interval   : 2 seconds 
Max wait interval  : 0 forever 
Command for restore  : cp "/var/tafkan_backup_from_db1/0000000200000083000000A2" "pg_xlog/RECOVERYXLOG" 
Keep archive history : 000000000000000000000000 and later 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 
WAL file not present yet. Checking for trigger file... 

[** This file is not present. All WAL files start with 00000001. **] 

어떤 아이디어가? 나는 .history 파일이 무엇인지 알지 못하며 (대부분 우수함)이 문서에서는 그다지 명확하지 않습니다.

추신. 을 사용할 수 있고이 애플리케이션 수준의 HA 넌센스에 대해 걱정할 필요가 없도록 VM을 실행하고 싶습니다.

업데이트 : 다음은 현재 대기 서버의 일부 로그입니다. 서버가 복구를 멈추고 온라인 상태가되는 것처럼 보이지만 무엇이 있는지 모르겠습니다. 나는 아무것도 트리거 파일을 만들 수 없다는 것을 확신합니다.

2010-01-20 03:30:15 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005A" from archive 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005B" from archive 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: record with zero length at 83/5BFA2FF8 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: redo done at 83/5BFA2FAC 
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG: last completed transaction was at log time 2010-01-20 03:28:04.594399-05 
2010-01-20 03:30:25 EST 4b3a5c63.401b LOG: restored log file "00000001000000830000005B" from archive 
2010-01-20 03:30:37 EST 4b3a5c63.401b LOG: selected new timeline ID: 2 
2010-01-20 03:30:49 EST 4b3a5c63.401b LOG: archive recovery complete 
2010-01-20 03:30:59 EST 4b3a5c62.4019 LOG: database system is ready to accept connections 
+0

안녕하세요 sbleon, 대체 위치에 WAL 파일을 백업하고 싶습니다. 대기 상태가 필요하지 않습니다. 도움이 될만합니까? –

+1

@indyaah, 해당 버전의 [우수한 PostgreSQL 문서] (http://www.postgresql.org/docs/)를 확인하십시오. – sbleon

+0

도움 주셔서 감사합니다. !! : D –

답변

1

두 개의 PostgreSQL 서버에서 CentOS 운영 체제를 업데이트하여이 문제를 해결할 수있었습니다. 따라서이 문제는 근본적인 네트워킹 버그의 증상이라고 생각합니다.

1

HA에 대한 전혀 다른 접근 방법은 두 컴퓨터 사이에 공유 DRBD 장치의 PG 데이터베이스를 호스팅 할 수 있습니다.

+0

제안에 감사드립니다! WAL-shipping이 안정적으로 작동하지 못하면 아마 내가 할 수있는 일입니다. – sbleon

1

복구 스크립트/프로그램을 직접 사용 했습니까? 그렇다면 -하지 마십시오. PostgreSQL contrib의 pg_standby를 사용하십시오.

그렇지 않으면 .history 파일을 무시하십시오.

+0

저는 pg_standby를 사용하고 있습니다. recovery.conf에는 다음이 포함됩니다. "restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger/var/tafkan_backup_from_db1 % f % p % r 2 >> standby.log'". .history 파일을 pg_standby가 검색하기 시작하면 복구가 실패하고 recovery.conf가 recovery.done으로 이동하고 WAL 파일이 빠르게 쌓이기 때문에 .history 파일을 무시할 수 없습니다. – sbleon

1

복제본이 어느 시점에서 온라인 상태가되었습니다. "00000002.history"는 타임 라인 00000002의 내역 파일을 찾고 나머지 로그는 원래 타임 라인 인 00000001로 시작합니다.

PostgreSQL 로그가 내역 파일을 찾기 직전에 데이터베이스가 잠시라도 온라인 상태가되었음을 알 수 있습니다.

+0

고마워, 매튜. 내 질문에 일부 로그를 추가했습니다. 당신이 뭔가를 온라인으로 만들었지 만 무엇이 왜 그 이유인지 상상할 수 없습니다. – sbleon

+0

소스 측에서 어떤 일이 발생 했습니까? "83/5BFA2FF8에 길이가 0 인 레코드"항목은 복원하려고했던 부분 WAL 로그 일뿐입니다. IIRC는 WAL에서 유효하지 않은 레코드로 실행되면 해당 WAL의 마지막 * good * 레코드로 롤백 한 다음 트리거 파일의 존재 여부와 상관없이 온라인 상태가됩니다. 2010-01-20 03 : 28 : 04.594399-05 전후에 두 시스템 로그를 살펴보고 Postgres, OS 또는 네트워크에 오류가 있는지 확인합니다. –

+0

그 행동은 의미가 있습니다. 백업에서 주 (Primary) 장애와 같은 것으로 보이는 경우, 주 (Primary)가 사망했으며 여유를 찾아야한다고 가정합니다. 네트워크 문제가있을 수 있습니다. 저는 그 각도를 들여다 볼 것입니다. 감사! – sbleon