PostgreSQL 오류: 복구와의 충돌로 인해 문을 취소합니다.
Postgre에서 쿼리를 실행할 때 다음 오류가 발생합니다.SQL db가 대기 모드에 있습니다.오류를 발생시키는 쿼리는 1개월 동안 정상적으로 작동하지만 1개월 이상 쿼리하면 오류가 발생합니다.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed
해결 방법에 대한 제안이 있습니까?감사해요.
없음 질없 음요hot_standby_feedback다른 사람들이 언급했듯이, 다음과 같이 설정합니다.on캔 블롯 마스터.노예에서 거래를 열고 닫지 않는다고 상상해 보세요.
대, 설을 합니다.max_standby_archive_delay그리고.max_standby_streaming_delay어떤 제정신의 가치로:
# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s
이렇게 하면 900초 미만의 지속 시간을 가진 슬레이브에 대한 쿼리가 취소되지 않습니다.워크로드에 더 긴 쿼리가 필요한 경우 이러한 옵션을 더 높은 값으로 설정하면 됩니다.
핫 스탠바이 서버에서 쿼리를 실행하는 것은 다소 까다로운 작업입니다. 쿼리하는 동안 필요한 일부 행이 기본적으로 업데이트되거나 삭제될 수 있기 때문에 실패할 수 있습니다.Primary는 쿼리가 Secondary에서 시작되었음을 모르기 때문에 이전 버전의 행을 정리(진공)할 수 있다고 생각합니다.그런 다음 보조는 이 정리를 재생하고 이 행을 사용할 수 있는 모든 쿼리를 강제로 취소해야 합니다.
더 긴 쿼리는 더 자주 취소됩니다.
이 문제를 해결하려면 기본에서 더미 쿼리를 수행한 다음 실제 쿼리가 보조에서 실행되는 동안 유휴 상태로 유지되는 반복 가능한 읽기 트랜잭션을 시작합니다.기본 행에 이전 행 버전이 진공 상태가 되는 것을 방지합니다.
이 주제 및 기타 해결 방법에 대한 자세한 내용은 문서의 핫 스탠바이 - 쿼리 충돌 처리 섹션에서 설명합니다.
마스터에서 유휴 트랜잭션을 시작할 필요가 없습니다.postgresql-9.1에서 이 문제를 해결하는 가장 직접적인 방법은 다음과 같습니다.
hot_standby_feedback = on
이렇게 하면 마스터가 장기간 실행 중인 쿼리를 인식할 수 있습니다.문서에서:
첫 번째 옵션은 hot_standby_feedback 매개 변수를 설정하여 VACUM이 최근에 죽은 행을 제거하지 못하도록 하여 정리 충돌이 발생하지 않도록 하는 것입니다.
기본값이 아닌 이유는 무엇입니까?이 매개 변수는 초기 구현 후 추가되었으며 대기 상태가 마스터에 영향을 줄 수 있는 유일한 방법입니다.
에 대하여 여기에 기술된 바와 같이hot_standby_feedback = on:
흠, 그것의 단점은 대기자가 마스터를 부풀릴 수 있다는 것인데, 이것은 몇몇 사람들에게도 놀랄 수 있습니다.
그리고 여기:
max_standby_streaming_delay 설정은 무엇입니까?기본 hot_standby_feedback on보다는 -1로 기본 설정하고 싶습니다.그런 식으로 대기 상태에서 수행하는 작업은 대기 상태에만 영향을 미칩니다.
그래서 추가했습니다.
max_standby_streaming_delay = -1
그리고 더이상은pg_dump 오류, :) 리를위오류한우, 마블롯:)터스또는▁error:)블.
AWS RDS 인스턴스에 대해서는 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html 을 참조하십시오.
장기 실행 쿼리가 실행되는 동안 핫 스탠바이 슬레이브 서버의 테이블 데이터가 수정됩니다.솔루션(Postgre)SQL 9.1+)에서는 테이블 데이터가 수정되지 않도록 복제를 일시 중단하고 쿼리 후 다시 시작합니다.
select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume
위의 @max-malysh의 훌륭한 답변에 몇 가지 업데이트된 정보와 참조를 추가하려고 합니다.
즉, 마스터에서 작업을 수행할 경우 슬레이브에서 복제해야 합니다.Postgres는 이에 대해 WAL 레코드를 사용하며, 이 레코드는 마스터에서 기록된 모든 작업 후 슬레이브로 전송됩니다.그런 다음 슬레이브가 작업을 실행하고 두 작업이 다시 동기화됩니다.여러 시나리오 중 하나에서 WAL 작업에서 마스터로부터 수신되는 내용과 슬레이브에서 충돌할 수 있습니다.대부분의 경우 노예에게 일어나는 거래가 있는데, 이는 WAL의 행동이 변경하고자 하는 것과 상충됩니다.이 경우 두 가지 옵션이 있습니다.
- 슬레이브가 충돌하는 트랜잭션을 완료할 수 있도록 WAL 작업 적용을 잠시 지연한 다음 작업을 적용합니다.
- 슬레이브에서 충돌하는 쿼리를 취소합니다.
우리는 #1과 두 가지 가치에 관심이 있습니다.
max_standby_archive_delay현재 데이터가 아닌 WAL 아카이브에서 데이터를 읽을 때 마스터와 슬레이브 간의 오랜 연결 끊김 후 사용되는 지연입니다.max_standby_streaming_delay스트리밍 복제를 통해 WAL 항목을 수신할 때 쿼리를 취소하는 데 사용되는 지연입니다.
일반적으로 서버가 고가용성 복제용인 경우 이 숫자를 짧게 유지해야 합니다.인 " 기설정본의"30000(단위가 지정되지 않은 경우 밀리초)이면 충분합니다.그러나 보관, 보고 또는 읽기 복제본과 같이 매우 오랫동안 실행되는 쿼리를 포함할 수 있는 항목을 설정하려면 이 값을 더 높은 값으로 설정하여 쿼리가 취소되지 않도록 해야 합니다.되는 된천900s위의 설정은 좋은 출발점인 것 같습니다.무한한 가치를 설정하는 것에 대한 공식 문서에 동의하지 않습니다.-1버그 코드를 숨기고 많은 문제를 일으킬 수 있는 좋은 생각입니다.
쿼리를 장시간 실행하고 이러한 값을 더 높게 설정할 때 주의해야 할 점은 WAL 작업을 지연시키는 장시간 실행 쿼리와 병렬로 슬레이브에서 실행되는 다른 쿼리는 긴 쿼리가 완료될 때까지 오래된 데이터를 볼 수 있다는 것입니다.개발자는 이를 이해하고 동시에 실행해서는 안 되는 쿼리를 직렬화해야 합니다.
방법에 대한 자세한 설명은max_standby_archive_delay그리고.max_standby_streaming_delay일을 하고 왜, 여기로 가.
답변하기에는 너무 늦었을 수도 있지만, 우리는 같은 종류의 생산 문제에 직면해 있습니다.이전에는 RDS가 1개뿐이었고 앱 측에서 사용자 수가 증가함에 따라 RDS용 Read Replica를 추가하기로 결정했습니다.Read replica는 스테이징에서 제대로 작동하지만 프로덕션으로 이동하면 동일한 오류가 발생합니다.
따라서 Postgres 속성에서 hot_standby_feedback 속성을 활성화하여 이 문제를 해결합니다.우리는 다음 링크를 참조했습니다.
https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/
도움이 되길 바랍니다.
마찬가지로, 위의 @max-malysh의 훌륭한 답변에 대한 @Artif3x의 두 번째 경고가 있습니다.
마스터에서 트랜잭션을 지연 적용하면 팔로워는 오래된 오래된 데이터 보기를 갖게 됩니다.따라서 max_standby_archive_delay 및 max_standby_streaming_delay를 설정하여 팔로워에 대한 쿼리가 완료될 시간을 제공하는 동안 다음 두 가지 주의 사항을 모두 기억하십시오.
백업용 팔로워의 값이 호스팅 쿼리와 너무 충돌하는 경우 하나의 솔루션은 하나 또는 다른 하나에 대해 최적화된 여러 팔로워가 될 수 있습니다.
또한 연속된 여러 쿼리로 인해 벽 항목의 적용이 계속 지연될 수 있습니다.따라서 새 값을 선택할 때는 단일 쿼리를 위한 시간이 아니라 충돌하는 쿼리가 시작될 때마다 시작되고 월 항목이 최종적으로 적용될 때 종료되는 이동 창입니다.
언급URL : https://stackoverflow.com/questions/14592436/postgresql-error-canceling-statement-due-to-conflict-with-recovery
'programing' 카테고리의 다른 글
| Android:서비스에서 현재 전경 활동을 얻으려면 어떻게 해야 합니까? (0) | 2023.08.05 |
|---|---|
| 바이온 도커 컨테이너를 실행하는 방법은 무엇입니까? (0) | 2023.07.31 |
| 모델 가져오기 시 1을 true로 또는 0을 false로 변환하는 방법 (0) | 2023.07.31 |
| iOS - 지연 후 여러 인수와 함께 performSelector를 구현하는 방법은 무엇입니까? (0) | 2023.07.31 |
| Swagger에서 Spring의 로그인/로그아웃 API 문서화 (0) | 2023.07.31 |