Messaging Server 배포는 LDAP 디렉토리, MTA(메시지 전송 에이전트), MMP(Messaging Multiplexor) 및 백엔드 메시지 저장소를 비롯하여 여러 종류의 기능으로 구성되어 있습니다. 단일 호스트 또는 여러 호스트를 사용할 수 없는 경우를 대비하여 여분의 LDAP 디렉토리, MTA 및 MMP를 설계할 수 있습니다. 그에 따라 최종 사용자에게는 중요한 성능 중단 없이 서비스가 계속 지속됩니다. 백엔드 메시지 저장소 계층은 메시지 저장소를 사용할 수 없는 경우 해당 저장소에 있는 사용자가 중단을 경험한다는 점에서 다릅니다. 따라서 오류 발생 시 서비스를 복원하려면 메시지 저장소 문제를 처리할 수 있는 절차를 계획하고 문서화해야 합니다.
메시지 저장소에는 특정 Messaging Server 인스턴스용 사용자 메일함이 들어 있습니다. 메일함, 폴더 및 로그 파일 수가 증가할수록 메시지 저장소 크기도 증가합니다. 메일함 크기(디스크 할당량)에 대한 제한과 허용된 전체 메시지 수에 대한 제한을 지정하고, 저장소에 있는 메시지의 시간 경과 정책을 설정하여 저장소 크기를 제어할 수 있습니다.
메시지 저장소 자체는 다수의 메일함 데이터베이스와 사용자 메일함으로 구성되어 있습니다. 메일함 데이터베이스는 사용자, 메일함, 파티션, 할당량 및 기타 메시지 저장소 관련 데이터로 구성되어 있으며, 사용자 메일함에는 사용자 메시지와 폴더가 들어 있습니다. 메일함은 메시지 저장소 파티션, 엄밀히 말하면 메시지 저장소 저장을 전담하는 디스크 파티션 영역에 저장되어 있습니다. 메시지 저장소 파티션은 디스크 파티션과 같지 않습니다. 하지만 쉽게 유지 관리할 수 있도록 각 메시지 저장소 파티션별로 디스크 파티션을 한 개씩 사용하십시오.
INBOX와 같은 메일함은 store_root 디렉토리에 있습니다. 예를 들어 샘플 디렉토리 경로는 다음과 같습니다.
store_root/partition/primary/=user/53/53/=mack1
메시지 저장소 아키텍처에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 관리 설명서의 메시지 저장소 디렉토리 레이아웃을 참조하십시오.
메시지 저장소 백업 및 복원 정책 구현
메시지 저장소 백업 및 복원은 사용 중인 메시지 저장소 배포에서 가장 중요한 관리 작업 중 하나입니다. 사용 중인 메시지 저장소에 대한 백업 및 복원 정책을 구현하여 다음과 같은 문제가 발생하는 경우 데이터가 손실되지 않았는지 확인해야 합니다.
시스템 충돌
하드웨어 오류
메시지 또는 메일함의 우발적 삭제
시스템 재설치 또는 업그레이드 시 문제
자연 재해(예: 지진, 화재, 태풍)
사용자 마이그레이션
메시지 저장소를 백업하고 복원하기 위한 옵션은 다음과 같습니다. 이러한 솔루션의 찬반을 이해하여 배포에 적절한 선택을 해야 합니다.
명령줄 유틸리티 imsbackup 및 imsrestore. 이러한 유틸리티는 CPU 사용 및 IOP와 관련하여 비용이 많이 듭니다. 하지만 이 유틸리티를 사용하면 백업 프로세스를 병렬화하고, 여러 개의 백업 채널용 파티션을 분리할 수 있습니다. 기본값은 백업 채널 한 개이며, 이 채널을 사용하여 백업 채널을 10개까지 변경할 수 있습니다. 이러한 유틸리티를 선택하는 가장 보편적인 이유는 시스템이 실행 중일 때 서비스를 복원할 수 있기 때문입니다. 예를 들어 확실한 치명적 오류의 경우 빈 메시지 저장소를 제시하고, 사용자가 읽을 수 있는 새 메일을 수신하는 것을 허용한 다음 몇 시간 또는 몇 일 동안 기존 메일을 복원할 수 있습니다.
"스냅샷 만들기" 또는 기타 블록 기반 백업 솔루션. 이러한 솔루션은 imsbackup 유틸리티보다 서버에 훨씬 적은 영향을 미칩니다. 하지만 서비스 복원 시 전체 복원을 수행해야 서비스를 실행 중으로 설정할 수 있습니다.
사용 중인 사이트의 메시지 저장소 백업 및 복원 정책 개발에 대한 자세한 내용은 Sun Java System Messaging Server 6.3 관리 설명서의 메일함 백업 정책 만들기를 참조하십시오.
메시지 저장소 문제 해결
메시지 저장소 데이터가 매우 견고하더라도 메시지 저장소 데이터 문제가 드물게 발생할 수 있습니다. Messaging Server는 메시지 저장소 문제를 나타내는 오류 메시지를 기본 로그 파일에 기록합니다. Messaging Server 6.3부터 소프트웨어는 거의 항상 메시지 저장소 데이터 문제를 분명하게 해결합니다. 드문 경우지만 reconstruct 유틸리티를 실행해야 할 때 로그 파일에 오류 메시지가 기록되기도 합니다.
메시지 저장소의 문제를 해결하기 위한 일반 접근 방식의 일환으로 다음 기술을 사용하십시오.
stored 프로세스가 다시 시작될 때마다 오류 메시지의 기본 로그 또는 지침을 확인하여 저장소 복구 명령(예: reconstruct-m)을 실행합니다. 로그 파일은 별도로 구성하지 않은 한 /opt/SUNWmsgsr/data/log 디렉토리에 있습니다. 오류 메시지는 메시지 저장소를 중지하고 시작할 때 표시될 가능성이 많습니다. 로그에 표시되는 지침에 따라야 합니다. 자세한 내용은 Sun Java System Messaging Server 6.3 관리 설명서의 메일함 및 메일함 데이터베이스 복구를 참조하십시오.
문제를 단일 메일함, 특정 파티션, 전체 호스트 또는 종속성으로 분리합니다. 그런 다음 필요한 경우 다음 메시지 저장소 문제 복구 섹션의 절차를 수행할 수 있습니다.
Messaging Server 호스트, 파티션 레이아웃, Messaging Server 소프트웨어에 대한 디렉토리 경로 등을 비롯한 사용자 고유의 메시지 저장소 배포 및 구성
hashdir 명령을 사용하여 디스크에서 사용자 계정 찾기
Messaging Server 명령(예: reconstruct, mboxutil, start-msg, stop-msg 등)
Messaging Server 및 운영 체제 로그 확인
Sun Java System Messaging Server 6.3 관리 설명서의 메시지 저장소 시작 및 복구에 설명된 메시지 저장소 작업 이론
참고 - Messaging Server 6.0부터 사용자가 로그인했는데 사용자의 메일함이 folder.db 파일에 없는 경우 시스템은 folder.db 파일에 메일함과 기타 복구된 데이터를 입력합니다. store.idx 파일이 손상되었다고 생각되면 이 때 폴더에서 reconstruct-r 명령을 실행할 수 있습니다. 그렇지 않으면 폴더는 예상한 대로 작동합니다. Messaging Server 6.0부터는 오류 수정 기능이 추가되어 단지 사용자가 로그인하기만 하면 store.idx 파일이 수정됩니다. 그렇지만 reconstruct 명령을 실행하여 심각한 문제를 복구할 수도 있습니다.
개인 메일함 복구
이 작업에서는 reconstruct 명령을 사용하여 개인 메일함을 복구하는 방법 및 Messaging Server 6과 iPlanet Messaging Server 5 사이의 차이점에 대해 설명합니다.
Messaging Server 6.0부터는 메시지 저장소를 바로 시작할 수 있습니다. 그리고 백그라운드에서 reconstruct 명령이 실행 중인 경우에도 사용자가 로그인할 수 있습니다. stored 프로세스는 로그 누적 등에 필요한 데이터베이스를 확인하여 필요한 작업을 수행합니다. 문제가 있는 경우 stored 프로세스는 데이터베이스를 스냅샷으로 바꾸거나, 데이터베이스를 제거하여 관리자는 이 데이터베이스를 처리하지 않아도 됩니다.
iPlanet Messaging Server 5 배포가 있는 경우 문제가 있는 메일함을 해결하기 전에 시스템에서 사용자를 허용할지 여부를 고려하여 개인 메일함이나 소량의 메일함을 복구해야 합니다. 대부분의 경우 이는 소량의 메일함이 "고장"나더라도 상당한 수의 사용자가 작업할 수 있도록 허용함을 의미합니다. 처음에는 이 작업이 바람직한 것으로 보이지만 개인 계정에 대한 문제로 인해 대규모의 중단이 반복될 수 있는지 여부와, 이 위험이 다수의 사용자가 복구를 완료하기 전에 시스템에 액세스할 수 있다는 이점보다 중요한지 여부에 대해 고려해봐야 합니다.
시작하기 전에
메시지 저장소가 실행 중이어야 합니다. 사용자가 로그인하여 메시지 저장소를 사용 중일 수도 있습니다.
문제가 있는 계정을 식별하고 재구성합니다.
reconstruct -r
여기서
-r
옵션은 사용자 파티션 디렉토리 내에 있는 모든 메일함의 스풀 영역을 복구합니다.
다음 명령은 전체 저장소에 걸쳐 실행되고 불일치를 검색하지만 변경 작업을 수행하지는 않습니다. 단일 파티션 또는 패턴을 지정하려면 다음 예를 참조하십시오.
두 번째 예에서 각 문자에 대해 reconstruct 명령을 실행합니다. 이렇게 하면 받은 편지함만 확인됩니다.
mboxutil 명령을 사용하여 메일함이 메일 시스템 데이터베이스에서 누락되었는지 확인합니다.
누락된 경우 3단계를 진행하고, 그렇지 않으면 다음 명령을 실행합니다.
reconstruct -m -p partition -u userid
메시지 저장소는 이제 제대로 작동할 수 있어야 합니다(이 사용자에 대한 작동 포함).
메일함이 메일 시스템 데이터베이스에서 누락된 경우에는 다음을 수행합니다.
메일함을 만듭니다.
mboxutil -c user/userid/INBOX
비시스템 폴더를 만듭니다.
mboxutil -c user/userid/foldername
이렇게 하면 빈 store.idx 및 데이터베이스 항목이 만들어집니다.
다음 명령을 실행하여 store.idx 파일을 채웁니다.
reconstruct -rf user/userid
-f 옵션으로 인해 reconstruct가 인덱스 수 오류를 무시하게 됩니다.
메시지 저장소는 이제 제대로 작동할 수 있어야 합니다(이 사용자에 대한 작동 포함).
단일(또는 전체) 파티션에서 여러 메일함 복구
시작하기 전에
사용자에게 메시지 저장소를 중지하고 다시 시작해야 한다고 알려야 합니다.
메시지 저장소와 기타 모든 메일 작업을 종료하고 DB 잠금을 해제합니다.
stop-msg
메시지 저장소를 다시 시작합니다.
start-msg store
메시지 저장소는 초기화를 시도하고 트랜잭션 로그 처리를 시작합니다. 메시지 저장소에서 작업이 진행되면 나머지 Messaging Server 데몬을 시작할 수 있습니다(start-msg 또는 start-msg imap, start-msg http 등의 명령 사용). 하지만 이 작업은 서서히 수행하십시오.
메시지 저장소가 제대로 초기화될 수 없는 경우에는 가장 좋은 저장소 백업 후보(DB 및 트랜잭션 로그)로 자동 롤백되며, 사용자는 reconstruct-m 명령을 실행하라는 알림을 받습니다.
이 단계는 롤백에 의해 덤프된 트랜잭션에 대해 설명할 때 필요합니다. 롤백 버전에 트랜잭션 로그가 여러 개 있으면 Messaging Server 프로세스를 점차적으로 시작하기 전에 몇 분 정도 시간이 소요됩니다. 그런 다음 reconstruct 명령을 실행합니다.
여러 파티션(또는 전체 메시지 저장소 호스트)에서 여러 메일함 복구
여러 개의 파티션을 복구하는 작업은 한 번에 모든 파티션을 복원할지 또는 각 파티션에 별도의 명령을 실행할지 선택해야 하는 점을 제외하고는 단일 파티션을 복구하는 작업과 비슷합니다.
첫 번째 옵션은 프로세스 한 개만 모니터하면 된다는 장점이 있습니다. 두 번째 옵션은 여러 프로세스가 동시에 실행될 수 있기 때문에 프로세스 한 개만 실행할 때보다 시간이 적게 소요된다는 장점이 있습니다. 하지만 지금 실행하고 모니터해야 할 프로세스가 여러 개 있는 상태입니다.
여러 메시지 저장소 호스트에서 여러 메일함 복구
여러 개의 호스트에 문제가 있는 경우 문제는 주로 기본 인프라에서 발생합니다. 기본 인프라는 다음과 같습니다(이에 국한되지는 않음).
엔터프라이즈 저장소
LDAP 디렉토리
전원 또는 환경
네트워크
운영 체제 및 패치
메일 시스템 로그를 확인합니다. 로그는 기본적으로 /opt/SUNWmsgsr/data/log 디렉토리에 있습니다.
오류 메시지에 기본 문제가 있는 위치가 나타날 수 있습니다.
그렇지 않으면 시스템 로그를 확인합니다 (Solaris OS의 경우 /var/adm/messages에서 시작).
트랜잭션 로그 축적은 중지된 프로세스를 비롯하여 예상외로 존재하는 프로세스에 의해 만들어진 고아 잠금 또는 과도한 교착 상태로 인해 중단된 데이터베이스의 증상 중 한 가지입니다.
Messaging Server 6.2부터 로그 파일 축적이 모니터되고 경고 메시지가 인쇄됩니다. 감시자 프로그램은 고아 잠금 상태로 유지될 수 있는 중지된 프로세스를 등록하고 보고합니다. 자동 재시작 옵션을 사용할 수도 있습니다.
참고 - 추후 계획된 제품의 기능을 사용하면 메시지 저장소를 즉시 시작하며, reconstruct-m이 실행되기 전에 사용자 고유의 폴더를 찾을 수 있게 됩니다.
Messaging Server 6.3에는 스냅샷을 검증하는 프로그램이 새로 추가되었습니다. 이 프로그램은 데이터베이스 손상이 활성 데이터베이스에서 스냅샷까지 전파되는 문제를 해결합니다. Messaging Server 6.3을 실행 중인 경우 데이터베이스 스냅샷이 imdbverify 유틸리티를 통해 자동으로 구성되어 있습니다. 이 방식으로 데이터베이스 복구를 자동화합니다. 원하는 경우 좀 더 자주 실행되도록 imdbverify를 구성할 수 있습니다.
주의 - 데이터베이스는 거의 손상되지 않습니다. 데이터베이스에서의 수동 작동은 최후의 수단일 경우를 제외하고는 시도하지 마십시오. 데이터베이스를 수정하기 위해 수동으로 작업을 마치면 문제에 대해 작업할 때 이에 대해 Sun 지원 센터에 보고해야 합니다.
중단된 데이터베이스 식별
다음 증상 중 나타나는 증상이 있습니까?
한 개의 메시지 저장소에만 문제가 있습니다.
메시지가 ims-ms 채널에 축적되었습니다. 시스템에서 발생하는 내용을 보려면 imsimta qm summarize 명령을 사용하십시오.
메시지 저장소 한 개에 중단된 사용자가 있습니다. 진행 정보를 표시하는 로그를 검토하십시오.
메시지 저장소 작업(예: 사용자당 검사점 지정 및 야간 만료)이 완료되지 않았습니다.
메시지 저장소 DB와 잠금 정보를 확인합니다.
Messaging Server 6.3: imcheck -s 명령을 실행하여 메시지 저장소 DB와 잠금 정보를 확인합니다.
Messaging Server 6.3 이전 버전: db_stat 명령을 실행합니다. 먼저 configutil -o store.dbtmpdir 명령을 사용하여 /var/path/store/tmp 디렉토리의 위치를 확인합니다. 이 값이 설정되어 있지 않으면 저장소 데이터베이스 디렉토리인 msg_path/data/store/mboxutil/이 기본값으로 설정됩니다. store/tmp 디렉토리의 위치를 설정하고 나면 Messaging Server 사용자(예: mailsvr)로 처음 전환하는 db_stat 명령을 실행합니다.
su msg_usermsg_path/lib/db_stat -t -h /var/path/store/tmp
이렇게 하면 양식이 log.000000xxxx인 여러 개의 트랜잭션 로그 파일이 표시됩니다.
고아 잠금을 나타낼 수 있는 지속성 DB 잠금을 확인합니다. 여러 번 실행하여 잠금이 지워지지 않는지 확인하십시오.
추가 정보
메시지 저장소 백업, 복구 및 문제 해결에 대한 자세한 내용은 다음 항목을 참조하십시오.
Sun Java System Messaging Server 6.3 관리 설명서의 메시지 저장소 백업 및 복원
Sun Java System Messaging Server 6.3 관리 설명서의 메시지 저장소 시작 및 복구
Print-friendly Version
