데이터베이스 컨테이너가 정전으로 손상되었다는 경고 신호는 무엇인가요?

데이터베이스가 정상적인 충돌 복구를 완료하지 못하거나 이후 체크섬, 페이지, 로그 시퀀스, 테이블 또는 인덱스 불일치를 보고한다면 손상을 의심해야 합니다.

비정상적인 종료가 발생했다고 해서 데이터베이스가 자동으로 손상된 것은 아닙니다. PostgreSQL, MySQL, MariaDB 및 유사한 데이터베이스 엔진은 커밋된 상태를 복구하기 위해 저널 또는 미리 쓰기 로그를 사용합니다. 복구가 반복되거나, 엔진이 종료되거나, 동일한 쿼리에서 잘못된 페이지에 접근하거나, 체크섬 검증에 실패하거나, 테이블이 사라지거나, 인덱스와 테이블 데이터가 서로 일치하지 않거나, 백업 및 무결성 검사가 클러스터를 일관되게 읽지 못할 때 경고 단계에 도달한 것으로 볼 수 있습니다.

정상적인 충돌 복구와 복구 루프를 구분하세요

전원이 복구된 후 최초로 기록된 시작 로그를 보존하세요. 엔진이 로그를 한 번 재생한 뒤 준비 상태가 되는지, 아니면 반복적으로 재시작하거나 강제 복구에 진입하거나 동일한 레코드 또는 페이지에서 중단되는지 기록하세요.

InnoDB는 쓰기 작업이 중단된 후 반쯤 기록된 페이지로 추정되는 항목을 복원하고 있다고 보고할 수 있습니다. 이 메시지는 엔진이 안전한 충돌 복구를 시도하고 있음을 나타내지만, 반복적인 실패는 전원 장애 후 InnoDB 오류를 가리킬 수 있습니다.

복구가 한 번 성공하고 이후 정상적인 검사까지 통과했다고 해서 손상이 없다는 증거는 아닙니다. 루프, 치명적인 어설션, 반복되는 신호 또는 준비 상태에 도달하지 못하는 상황은 추가 쓰기가 발생하기 전에 원시 파일을 복사하고 백업을 테스트해야 한다는 중단 신호입니다.

체크섬 및 잘못된 페이지 오류를 확인하세요

로그에서 체크섬 불일치, 페이지 검증 실패, 블록의 잘못된 페이지, 손상된 페이지, 짧은 읽기, 잘못된 매직 넘버 또는 예상치 못한 파일 끝을 검색하세요. 표시된 릴레이션, 테이블, 블록 또는 테이블스페이스를 기록하세요.

pganalyze는 손상된 블록을 읽을 때 PostgreSQL 손상이 페이지 체크섬 실패에 이어 잘못된 페이지 오류로 나타날 수 있음을 보여줍니다.

증거를 보존하고 백업 범위를 확인하기 전에 오류를 숨기거나 손상된 페이지를 0으로 덮어쓰지 마세요. 재시작할 때마다 동일한 블록에서 실패한다면 한 번 발생한 애플리케이션 타임아웃보다 훨씬 강력한 손상 증거입니다.

특정 행이나 테이블에서만 실패하는 쿼리를 확인하세요

애플리케이션이 일반적으로 사용하는 테이블과 쿼리에 대해 읽기 전용 검사를 실행하세요. 손상은 스캔, vacuum, 백업 또는 요청이 손상된 특정 페이지에 접근할 때까지 드러나지 않을 수 있습니다.

PostgreSQL 분석 자료에 따르면 체크섬 불일치는 데이터베이스 하위 계층의 문제를 가리키는 반면, 체크섬 경고가 없는 잘못된 페이지도 스토리지, 메모리, 파일 시스템 또는 우발적인 파일 손상을 의미할 수 있습니다. 실제 증상은 일반 쿼리 실행 중 반복적으로 재현되는 잘못된 페이지 읽기입니다.

실패하는 쿼리와 객체를 정확히 기록하세요. 데이터베이스의 일부만 읽을 수 있는 상태에서 애플리케이션이 광범위한 쓰기를 계속하도록 두지 마세요. 새로운 상태가 복구와 백업을 복잡하게 만들 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

인덱스, 트랜잭션 및 메타데이터 불일치를 확인하세요

경고 신호로는 고유 인덱스 제약을 위반하는 중복 키, 한 접근 경로에서는 보이지만 다른 접근 경로에서는 누락되는 행, 잘못된 트랜잭션 ID, 손상된 TOAST 또는 대용량 값 청크, 검증에 실패하는 인덱스 등이 있습니다.

Credativ의 손상 검토 자료에 따르면 데이터 체크섬이 없는 클러스터에서는 잘못된 페이지, 트랜잭션 ID 문제, TOAST 불일치 또는 백엔드 충돌과 같은 저수준 오류를 통해 손상이 드러날 수 있습니다. 일부 파일 복사 백업은 손상된 페이지를 감지하지 못한 채 보존할 수 있습니다.

복사본 또는 통제된 유지 관리 시간에 지원되는 무결성 및 인덱스 검사를 실행하세요. 재인덱싱으로 손상된 파생 인덱스를 복구할 수는 있지만, 손상된 테이블 데이터나 하위 스토리지를 복구하지는 못합니다.

데이터베이스 오류를 파일 시스템 및 스토리지 경고와 연관 지어 확인하세요

장애가 발생한 시점 전후로 호스트 커널, 파일 시스템, 풀, 드라이브, 컨트롤러, UPS 및 컨테이너 런타임 로그를 확인하세요. I/O 오류, 리셋, 체크섬 오류, 읽기 전용 재마운트, 성능이 저하된 풀, 손실되거나 잘린 파일을 찾아보세요.

한 데이터베이스 복구 가이드에 따르면 전원 장애와 불량 메모리는 특히 스토리지 동작이 데이터베이스의 내구성 가정과 일치하지 않을 때 손상된 페이지 쓰기를 유발할 수 있습니다. 이러한 호스트 수준의 이벤트는 InnoDB 페이지 손상과 정상적인 애플리케이션 재시작을 구분하는 데 도움이 됩니다.

정상적인 데이터베이스를 해당 스토리지에 복원하기 전에 스토리지 경로를 먼저 수정하세요. 장애가 발생하는 미디어에 논리적 복원을 성공적으로 수행하더라도 동일한 문제가 재발하거나 교체된 시스템이 조용히 손상될 수 있습니다.

쓰기를 중지하고 정상 백업에서 복구되는지 확인하세요

손상 징후가 반복되면 종속 애플리케이션을 중지하고, 안전한 경우 영향을 받은 볼륨을 스냅샷하거나 복제하며, 로그와 구성을 보존하세요. 원래 클러스터를 수정하기 전에 별도의 스토리지에서 최신 백업을 테스트하세요.

ZimaSpace의 Docker 애플리케이션 상태 백업 체크리스트는 파괴적인 데이터베이스 복구를 시도하기 전에 반드시 확보해야 할 항목을 정의합니다.

복원된 데이터베이스가 정상적으로 시작되고, 무결성 검사를 통과하며, 대표적인 쿼리와 쓰기가 성공하고, 백업이 완료되며, 호스트 스토리지에 새로운 오류가 보고되지 않을 때만 시스템을 신뢰할 수 있습니다. 강제 복구 모드는 문서화된 복구 계획에 따른 데이터 구출을 위해 사용해야 하며, 정상적인 운영에 사용해서는 안 됩니다.