Postgresql 인덱스 손상 원인 - postgresql 버그 또는 하드웨어 오류

Question

인덱스에 심각한 문제가있는 postgresql 9.5.2 프로덕션 서버가 있습니다. 그 주장을 뒷받침하는 감사 증거의 가장 강한 부분은 일부 쿼리 사이의 불일치입니다 :

select count(*) from x inner join y on x.a = y.a 
select *  from x inner join y on x.a = y.a 

카운트 (*) 쿼리 그냥 행을 반환 선택 * 쿼리에 의해 반환되는 행의 수보다 다른 번호를 반환합니다. 내가 시도한 첫 번째 일은 진공 분석 이었지만 문제를 해결하지는 못했습니다. 결국 서버를 다시 작동 시키려면 모든 인덱스를 삭제하고 다시 작성해야하며 결과가 select * 및 select count (*) 쿼리간에 일관되게 나타납니다.

어느 테이블에도 트리거가 없습니다. 표 x는 170 만 개의 행을 가지며 표 y는 690 만 개의 행과 600,000 개의 삭제 된 행을 가지며 표는 표 x의 기본 키인 외래 키 필드 a와 표 b의 null이 아닌 외래 키 제약 조건을 사용하여 링크됩니다 . 데이터베이스 서버는 가상 시스템에서 호스팅됩니다. 서버가 유일한 노드이며 다른 서버로의 복제가 없습니다. 시스템이 충돌 한 적이 없으므로 충돌하는 서버 또는 포스트그레스 서비스가 인덱스를 손상시킬 수 있다는 것을 알고 있지만, 나는 포스트 그레스 서비스가 결코 사용 가능하지 않았기 때문에 이러한 문제가 발생했다고 믿을 이유가 없다. 이 문제가 나타나기 훨씬 전에 오랫동안 일어났습니다.

이 데이터는 모두 색인이 제대로 작동하지 않는다는 것을 나타냅니다. 손상된 색인에 대한 나의 연구는 일반적으로 postgresql 또는 하드웨어 오류의 두 가지 원인을 지적합니다.

하드웨어 고장 및 데이터베이스 자체의 버그에 대한 솔루션은 근본적으로 다른 기술을 사용하여 해결됩니다. 즉 하드웨어 구입과 인덱스 무결성 검사 및 필요한 경우 적절한 조치를 취하는 프로그램 작성이 있습니다. 문제.

각 이론 (하드웨어 오류 vs. 소프트웨어 버그)에 대한 찬반으로 어떤 증거를 수집 할 수 있습니까?

Answer 1

하드웨어 문제를 방지하는 가장 좋은 방법은 클러스터를 만들 때 initdb의 --data-checksums 옵션을 사용하여 페이지 체크섬을 사용하는 것입니다.
그러나 이는 과거의 문제를 조사하는 데 도움이되지 않으며 데이터베이스 클러스터의 덤프/재로드가 필요합니다.

물리적 백업 (pg_basebackup 또는 pg_start_backup() 및 pg_stop_backup)을 사용하는 경우 문제가있는 마지막 백업을 찾는 것이 좋습니다. 지루할 수도 있지만 문제를 찾기 위해 창을 좁 힙니다.

fsync = off 또는 full_page_writes = off이 있습니까? 아니면 unreliable storage을 사용하고 있습니까? 그러면 버그가없고 하드웨어가 정상이라도 데이터베이스가 충돌로 손상 될 수 있습니다. 데이터베이스 로그에서 크래시를 확인하십시오.

하드웨어 문제가 있는지 확인하려면 운영 체제 로그 파일을보고 하드웨어 테스트를 수행하십시오.

알려진 소프트웨어 문제가 있는지 확인하려면 release notes을 확인하십시오. 손상된 색인이있는 경우 pgsql-hackers mailing list에게 도움을 요청할 수 있습니다.