Zimbra 메일함 로그의 "DB 오류: DB 실패/손상" 문제 해결: 안전한 진단 및 복구

Zimbra 사서함 로그에 "DB 오류: DB 실패"라는 메시지가 나타나는 것은 증상일 뿐 진단은 아닙니다. 이 오류는 데이터베이스 중지, 연결 실패, 디스크 공간 부족, 과도한 연결 또는 테이블이나 InnoDB 손상과 같은 문제를 나타낼 수 있습니다. 안전한 해결 방법은 주변 로그 라인과 영향을 받는 서버에 따라 다릅니다. 먼저 읽기 전용 검사를 수행하고 데이터를 보호하며, "손상"이라는 단어가 나타났다고 해서 일반적인 복구 명령을 실행하지 마십시오.

이 가이드에서는 Zimbra 기술 센터에 문서화된 일반적인 Zimbra 경로 및 명령어를 사용합니다. 관련 위키 페이지 중 일부는 보관되었거나 미완성 상태로 표시되어 있으므로, 공식 Zimbra 문서 색인을 사용하여 사용 중인 Zimbra 버전 및 릴리스에 맞는 모든 명령어와 복구 절차를 확인하십시오 . 아래 예제는 특정 릴리스를 가정하지 않습니다.

mailbox.log에 기록된 DB 오류는 실제로 무엇을 의미하나요?

Zimbra의 사서함 데이터베이스에는 폴더, 태그, 메시지 상태, 메시지 파일 포인터와 같은 사서함 메타데이터가 저장됩니다. 검색 인덱스는 별도로 저장되며, 메시지 내용은 메시지 저장소에 저장됩니다. 따라서 데이터베이스 오류가 발생했다고 해서 모든 이메일 파일이 손상된 것은 아닙니다. 또한 인덱스 오류 자체만으로는 데이터베이스 손상을 입증할 수 없습니다. Zimbra는 서버 아키텍처 참조 문서 에서 이러한 개별 저장소에 대해 자세히 설명합니다 .

결정적인 단서는 일반적으로 사서함 예외 근처, 특히 에 나타나는 기본 데이터베이스 오류입니다 /opt/zimbra/log/mysql_error.log. Zimbra의 문제 해결 노트에서는 mailbox.log와 를 mysql_error.log유용한 시작점으로 제시하며, 는 zmmailboxd.out사서함 서비스 시작 세부 정보를 제공합니다. Zimbra 로그 문제 해결 참조를 확인하세요 .

해결 방법을 시도하기 전에 무엇을 해야 할까요?

• 최초 발생 시간, 시간대, 서버 호스트 이름, 영향을 받은 계정, 전체 예외 메시지 및 주변 줄을 기록하십시오. 로그를 공유하기 전에 암호, 메시지 내용 및 개인 정보는 삭제하십시오.
• 범위를 결정하십시오. 단일 사서함, 하나의 스토어에 있는 여러 사서함 또는 여러 스토어에 걸쳐 있는 사용자일 수 있습니다. 단일 계정에서 발생하는 증상만으로는 클러스터 전체 데이터베이스를 재시작할 필요가 없습니다.
• 최근에 생성된 사용 가능한 백업이 있는지 확인하고 릴리스별 복원 절차를 파악하십시오. 오류가 반복되거나 사용자에게 영향을 미치는 경우, 데이터베이스 상태를 파악할 때까지 반복적인 재시작 및 쓰기 작업을 피하십시오.
• 데이터베이스 테이블을 검사하는 검사에는 유지 관리 기간을 활용하세요. 무결성 검사조차도 I/O 부하를 증가시켜 사서함 서비스 속도를 저하시킬 수 있습니다.

어떻게 안전하게 진단할 수 있을까요?

1. 서비스 상태를 확인하세요

메일함 서버에서 Zimbra 계정으로 전환하여 서비스 상태를 확인하십시오. 각 프롬프트에 표시된 계정으로 명령을 실행하십시오. $명령에 와 같은 프롬프트 기호를 붙여넣지 마십시오.

su - zimbra
zmcontrol status

사서함이 실행 중인지, 그리고 보고된 문제가 특정 사서함 서버에만 국한된 문제인지 확인하십시오. 사서함 프로세스가 중지되었다고 해서 데이터베이스가 손상되었다고 단정할 수는 없습니다. Zimbra의 사서함 문제 해결 페이지에는 서비스 상태와 데이터베이스 로그인/구성 확인 절차가 별도로 나와 있습니다. 해당 페이지는 보관용으로 표시되어 있으므로 참고 자료로 활용하고, 사용 중인 릴리스의 문서를 참조하십시오.

2. 사서함 로그와 데이터베이스 로그를 동시에 비교합니다.

두 로그에서 동일한 시간대를 읽으십시오. 일련의 오류 중 첫 번째 오류가 마지막 "시스템 오류" 줄보다 더 유용한 경우가 많습니다.

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

기본 데이터베이스 메시지, 데이터베이스 또는 사서함 그룹 이름, 반복되는 타임스탬프, 시작 실패 또는 일치하는 운영 체제 오류를 찾으십시오. 이러한 문구는 단서로 활용하고 자동 수정 사항으로 간주하지 마십시오.

3. 디스크 용량 및 운영 체제 오류를 확인하십시오.

데이터 또는 로그 볼륨이 가득 차거나, inode가 고갈되었거나, 스토리지에 오류가 발생하면 데이터베이스 오류처럼 보일 수 있습니다. 저장소 호스트에서 비파괴 검사를 실행하십시오.

df -h /opt/zimbra
df -i /opt/zimbra

운영 체제 저널 또는 시스템 로그에서 동일한 시간 범위 내에 디스크 I/O, 파일 시스템 또는 메모리 부족 오류가 발생했는지 확인하십시오. 볼륨이 가득 찬 경우, 일반적인 스토리지 절차에 따라 공간을 확보하거나 추가하십시오. 공간 확보를 위해 데이터베이스 파일, InnoDB 로그 또는 활성 Zimbra 로그를 삭제하지 마십시오. 복구가 어려워지거나 증거가 손상될 수 있습니다.

4. 영향 분석을 완료한 후에만 무결성 검사를 실행하십시오.

Zimbra 데이터베이스 서비스에 접속 가능하고 로그에 명확한 연결 또는 스토리지 문제가 나타나지 않는 경우, 관리자는 트래픽이 적은 유지 관리 기간 동안 표준 무결성 보고서를 검토할 수 있습니다.

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

Zimbra의 무결성 보고서 참조 문서에서는 이를 데이터베이스 검사로 설명하며, 이로 인해 I/O가 증가하고 사서함 지연 시간이 늘어날 수 있다고 경고합니다. 또한 -r자동 테이블 복구를 시도하는 옵션도 안내하고 있지만, 이 옵션을 다음 단계로 추가하지 마십시오 -r. 해당 페이지는 현재 작업 진행 중이며, 올바른 조치는 데이터베이스 엔진, 테이블 유형, 제품 릴리스 및 백업 상태에 따라 달라집니다. 알려진 무해한 로그 테이블 잠금 메시지만 언급하는 보고서는 해당 페이지의 참고 사항에 따라 해석해야 하며, 모든 "데이터베이스 오류 발견" 헤더를 동일하게 취급해서는 안 됩니다.

어떤 해결책이 증거와 일치합니까?

• 데이터베이스 서비스가 중지되었지만 손상 흔적은 발견되지 않았습니다. 먼저 특정 시작 오류, 구성 오류, 자격 증명 오류 또는 리소스 오류를 해결하십시오. 오류가 수정되면 릴리스 및 배포 토폴로지에 맞는 서비스 복구 절차를 따르십시오. 반복적인 무작정 재시작은 피하십시오.
• 연결 수가 너무 많습니다. 부하, 클라이언트 오류 및 서비스 용량을 조사하십시오. 데이터베이스 손상으로 단정짓거나 최신 크기 조정 및 릴리스 지침을 확인하지 않고 이전 권장 사항을 따라 제한을 늘리지 마십시오.
• 디스크 또는 파일 시스템 문제: 스토리지를 안정화하고 파일 시스템의 정상 상태를 확인하십시오. 데이터베이스에 쓰기 실패 또는 InnoDB 오류가 기록된 경우, 공간 복원 후에도 이를 데이터 무결성 문제로 간주해야 합니다.
• 무결성 보고서에서 문제가 있는 테이블을 표시하는 경우, 정확한 출력 내용, 테이블/데이터베이스 이름, 타임스탬프 및 관련 로그를 저장하십시오. 쓰기 작업을 수행하기 전에 지원되는 방법을 사용하여 데이터베이스 볼륨을 백업하거나 스냅샷을 생성하십시오. 관리자에게 설치된 Zimbra 버전에 대한 공급업체에서 지원하는 복구 또는 복원 절차를 따르도록 하십시오.
• 데이터베이스 엔진은 정상인데도 계정 하나에 문제가 남아 있는 경우, 해당 계정의 사서함 메타데이터, 메시지 저장소 또는 인덱스를 개별적으로 조사하십시오. SQL 행을 수동으로 편집하거나 파일을 삭제하여 계정을 "재구축"하는 것은 피하십시오.

InnoDB 손상이 의심되는 경우, 가장 안전한 복구 방법은 일반적으로 검증된 백업을 사용한 릴리스별 복구 또는 지원팀의 안내에 따른 복구이며, 일반적인 REPAIR TABLE데이터베이스 재초기화 또는 명령 시퀀스를 복사하는 것은 권장하지 않습니다. 일부 오래된 Zimbra 위키 복구 문서에는 시스템 손상을 초래하는 단계가 포함되어 있으므로, Zimbra 지원팀의 직접적인 확인과 검증된 백업 없이는 현재 시스템에 적용하지 마십시오.

문제가 해결되었는지 어떻게 확인할 수 있나요?

승인된 시정 조치를 완료한 후, 데이터베이스 및 사서함 서비스가 정상적으로 작동하는지, 새 항목에 동일한 데이터베이스 오류가 더 이상 표시되지 않는지, 그리고 해당 계정으로 일반적인 메일 작업을 수행할 수 있는지 확인하십시오. 사용 중인 시스템 부하 및 버전에 적합한 경우에만 표준 무결성 보고서를 다시 실행하십시오. 백업 작업이 완료되고 로그 및 복구 기록이 보존되었는지 확인하십시오. 문제가 다시 발생하면 정확한 Zimbra 버전/빌드, 단일 서버 또는 다중 서버 구성, 사서함 범위, 최초 오류 발생 시간, 관련 로그 발췌, 디스크 상태, 무결성 보고서 출력 및 백업 타임스탬프를 관리자 또는 Zimbra 지원 채널에 보고하십시오.

핵심 요점: 데이터를 변경하기 전에 사서함 예외의 원인이 되는 데이터베이스 오류를 진단하십시오. "DB 오류"라는 메시지만으로는 자격 증명 수정, 용량 변경, 스토리지 복구 또는 데이터베이스 복구 중 어떤 조치가 필요한지 알 수 없습니다.

주요 참조 자료: Zimbra 문서 색인 , Zimbra 서버 아키텍처 , Zimbra 로그 문제 해결 , Zimbra 데이터베이스 무결성 보고서 참조 , Zimbra MySQL 오류 1040 참조 , Zimbra 사서함 문제 해결 참조 . 일부 기술 센터 페이지는 문서에 명시된 대로 보관되었거나 작업 진행 중으로 표시되어 있습니다.