PostgreSQL 2.5 TB 백업 없이 복구

PostgreSQL 백업 없이 복구: 2.5 TB 클러스터 사례 연구

포스트그레스 프로페셔널 (Postgres Professional) 의 2.5 TB PostgreSQL 클러스터가 백업 없이 가상 머신에서 3 년 동안 운영되었습니다. 공간 예약 없이 구성된 디스크는 호스트의 물리적 크기를 초과하여 카피 온 라이트 (copy-on-write) 방식으로 확장되었습니다. 1C 를 포함한 10 개의 활성 데이터베이스가 새로운 정보 베이스를 로드한 후 충돌했습니다. WAL 로그가 하이퍼바이저 디스크를 가득 채웠고 체크포인트가 완료되지 않았습니다.

관리자는 수동으로 WAL 파일을 삭제하고 빠른 모드에서 포스트마스터 (postmaster) 를 중지하려고 시도했지만 실패했습니다. 강제 SIGKILL 중지는 대규모 shared_buffers 로 인해 데이터 손상을 초래했습니다. pg_resetwal 을 통한 시작은 WAL 복구를 비활성화했으며, 간단한 쿼리는 작동했지만 복잡한 쿼리는 작동하지 않았습니다.

진단 및 초기 패치

무료 포스트그레스 프로페셔널 빌드에서 제공되는 crash_info 유틸리티를 SIGRTMIN+6 신호를 통해 사용하여 시스템 카탈로그의 btree 인덱스에서 _bt_moveright 에서 중단된 것을 확인했습니다. ignore_system_indexes 매개변수를 활성화하거나 시스템 인덱스를 우회하는 패치를 적용했습니다. REINDEX SYSTEM 은 하룻밤 사이에 완료되지 않았습니다.

pg_dump 는 누락된 인덱스로 인해 테이블 목록을 검색하는 동안 중단되었습니다. --data-only 매개변수도 도움이 되지 않았습니다. 유틸리티가 확장 통계를 요청했기 때문입니다. pg_dump 용 패치는 시스템 카탈로그에 대한 불필요한 쿼리를 제외했습니다.

데이터 내보내기 및 결과

24 시간 후 주요 데이터베이스의 데이터가 새 클러스터로 내보내졌습니다. 손상된 인덱스가 있는 pg_dump 문제를 강조하는 패치 (버전 13–17 용) 가 PostgreSQL 커뮤니티에 버그 보고서로 제출되었습니다. 커뮤니티는 이를 버그로 분류하는 것을 거부했습니다. 백업 없이 복구는 우선순위가 아니기 때문입니다.

클라이언트는 포스트그레스 프로페셔널에서 엔터프라이즈 지원을 구매했습니다. pg_dump 의 대안은 시스템 카탈로그에 액세스하지 않고 스크립트로 생성한 1C 의 테이블 목록 (데이터베이스에 50,000 개 테이블) 을 통한 COPY 였습니다.

주요 관리자 실수

• 백업 및 복제본 부재.
• WAL 로그 수동 삭제.
• SIGQUIT 대신 SIGKILL 로 포스트마스터 중지.
• 디스크 예약 권장 사항 무시.
• 백업 확인 없이 '가이드'에 의존.
• 카탈로그 손상을 고려하지 않은 pg_dump 잘못된 선택.

중요한 포인트

• 백업 (덤프, 복제본) 이 없으면 2.5 TB 클러스터의 전체 복구는 불가능합니다.
• ignore_system_indexes 는 손상된 시스템 인덱스를 우회할 수 있게 합니다.
• crash_info 는 콘솔 액세스 없이 상태 덤프에 유용합니다.
• pg_dump 는 카탈로그 손상에 취약합니다. 패치와 함께 --data-only 를 사용하거나 COPY 를 사용하세요.
• shared_buffers 가 클 때 포스트마스터를 SIGKILL 하면 데이터가 파괴됩니다.

DBA 를 위한 교훈

1C 클러스터는 WAL 정리, 디스크 공간 모니터링 및 복제가 필요합니다. 거대한 shared_buffers 는 재앙이 닥칠 때까지 문제를 숨깁니다. 50,000 개 테이블의 경우 1C 메타데이터에서 COPY 스크립트를 생성하세요.

— Editorial Team