|
| |
| Sun Java System Calendar Server 6 2005Q1 관리 설명서 | |
22장
문제 해결이 장에서는 시스템에 문제가 있는지 여부와 문제의 원인을 확인하는 데 사용할 수 있는 몇 가지 문제 해결 기술에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.
디버깅 정보 설정전체 시스템을 "디버그 모드"로 실행하는 ics.conf 매개 변수는 없지만 이 절에서는 유용한 디버그 정보를 가져오는 몇 가지 방법에 대해 설명합니다.
로깅 수준 올리기
로깅의 상세 표시 수준을 높이려면 표 22-1에 표시된 매개 변수를 사용합니다.
표 22-1 디버그 모드 설정을 위한 ics.conf 매개 변수
매개 변수
설명 및 기본값
logfile.loglevel
CRITICAL, ALERT, ERROR, WARNING, NOTICE 및 INFORMATION을 포함하여 모든 수준을 기록하려면 DEBUG로 설정합니다. 이 설정은 모든 로그에 적용됩니다.
사용 가능한 다른 로그에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.
LDAP 캐시에 대한 액세스 로깅 활성화
LDAP 데이터 캐시에 대한 모든 액세스를 기록하고 로그(보고서)를 출력하려면 표 22-2에 표시된 ics.conf 매개 변수를 설정합니다.
Calendar Server 유틸리티를 사용하여 시스템
모니터시스템을 모니터하려면 다음 Calendar Server 유틸리티를 사용합니다.
Calendar Server 유틸리티에 대한 자세한 내용은 부록 D, "Calendar Server 명령줄 유틸리티 참조"를 참조하십시오.
LDAP 문제 해결이 절은 LDAP 문제와 관련된 내용으로 구성되어 있습니다.
Calendar Server 유틸리티 작동 안 함
호스트된 환경을 처음으로 만드는 경우 도메인, 컨테이너, 사용자 및 자원에 대한 해당 항목을 추가하여 LDAP의 DC 트리를 만들어야 합니다. cscal과 같은 Calendar Server 유틸리티를 사용할 때 DC 트리가 없으면 "Initialization failed .... exiting"과 같은 오류 메시지가 표시됩니다.
DC 트리 루트에 최소한 하나(기본값)의 도메인이 있는지 확인합니다. 호스트된 도메인(Schema 1)을 추가하려면의 지침에 따라 DC 트리 구조를 만듭니다.
마이그레이션 유틸리티 문제 해결Calendar Server는 달력 데이터베이스 및 LDAP 디렉토리 마이그레이션을 위한 여러 가지 유틸리티를 제공합니다. 이 절은 다음 내용으로 구성되어 있습니다.
기술 지원부에 문의하기 전에 수행할 작업
일반적으로 마이그레이션 유틸리티 사용 문제가 있는 경우 다음과 같은 정보를 미리 수집한 상태에서 기술 지원부에 문의해야 합니다.
마이그레이션 유틸리티 위치
다음 목록에 표시된 위치에서 다양한 마이그레이션 유틸리티와 해당 설명서를 찾을 수 있습니다.
- 스키마 마이그레이션 유틸리티(commdirmig) – 이 유틸리티는 액세스 관리자가 설치될 때 함께 설치됩니다. 이 유틸리티는 LDAP 디렉토리를 Schema 1에서 Schema 2로 마이그레이션합니다. 이 유틸리티에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q1 Schema Migration Guide를 참조하십시오.
- Calendar Server 5.x를 Calendar Server 6.x로 마이그레이션하는 유틸리티(cs5migrate 및 cs5migrate_recurring) – 기술 지원부에서는 유틸리티와 유틸리티 설명서가 포함된 마이그레이션 번들을 제공합니다.
- csmig – 이 유틸리티는 Calendar Server와 함께 설치됩니다. 설명서는 4장, "데이터베이스 마이그레이션 유틸리티"에 있으며 문제 해결 절로 구성됩니다. 호스트된 도메인 및 LDAP CLD(달력 조회 데이터베이스) 플러그 인을 사용하는 경우 이 유틸리티를 실행해야 합니다.
- csvdmig – 이 유틸리티는 Calendar Server와 함께 설치됩니다. 설명서는 4장, "데이터베이스 마이그레이션 유틸리티"에서 참조할 수 있습니다. 이 유틸리티를 사용하여 호스트된 도메인에 대한 달력 데이터베이스와 LDAP 디렉토리 항목을 준비합니다.
- Calendar Server 2.x를 Calendar Server 6.x로 마이그레이션하는 유틸리티(ics2migrate) – 이 유틸리티는 Calendar Server와 함께 설치됩니다. 설명서는 4장, "데이터베이스 마이그레이션 유틸리티"에서 참조할 수 있습니다. 이 유틸리티를 사용하면 Calendar Server 5.x와 호환되도록 Calendar Server 2.x를 마이그레이션할 수 있습니다.
- Netscape Calendar Server 4.x를 Calendar Server 5.x로 마이그레이션하는 유틸리티(ncs4migrate) – 이 유틸리티는 기술 지원부에서만 사용할 수 있습니다. 설명서는 유틸리티 패키지에 포함되어 있습니다. 이 유틸리티는 Netscape Calendar Server 4.x를 Calendar Server 5.x로 마이그레이션합니다. 이러한 마이그레이션은 특별한 주의가 필요합니다. 전문가 서비스의 도움을 받아 마이그레이션을 계획할 수 있습니다.
Calendar Server 문제 해결이 절에서는 비데이터베이스 문제에 대한 다양한 문제 해결 정보를 제공합니다. 다음 항목에 대해 설명합니다.
달력 서비스 핑
달력 서비스가 지정된 포트 번호를 수신 중인지 확인하려면 cstool 유틸리티 ping 명령을 사용합니다. 서비스 핑으로 해당 서비스가 실제 실행 중인지 확인할 수는 없지만 소켓 연결을 받아들일 수 있는지 여부를 알려 줍니다.
Calendar Server 서비스 옵션은 다음과 같습니다.
cstool을 실행하려면 Calendar Server가 실행 중이어야 합니다.
예를 들어, 호스트 이름이 calserver인 시스템을 핑하여 cshttpd 서비스가 포트 80을 수신하는지 확인하려면 다음 명령을 사용합니다.
cstool -p 80 -h calserver ping http
기본적으로 cstool은 응답이 올 때까지 120초 동안 대기하지만 -t timeout 옵션을 사용하면 값을 변경할 수 있습니다.
전체적인 유틸리티 참조 자료를 보려면 Calendar Server 명령줄 유틸리티 참조를 참조하십시오.
start-cal 문제를 해결하려면
start-cal을 실행할 때 모든 달력 서비스가 시작되지 않은 경우 시작된 서비스를 중지한 다음 다시 시작해야 합니다. 예를 들어, enpd, csnotifyd 및 csadmind 서비스는 시작되고 cshttpd 서비스는 시작되지 않은 경우 enpd, csnotifyd 및 csadmind 서비스를 중지해야 합니다.
달력 서비스를 시작하려면 다음 작업을 수행합니다.
- Calendar Server가 실행되고 있는 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.
- start-cal을 사용하여 서비스를 중지한 다음 다시 시작합니다. 예를 들면 다음과 같습니다.
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal은 다양한 달력 서비스를 시작하기 전에 stop-cal 명령을 실행합니다.
- stop-cal이 중지되지 않는 경우 중지되지 않은 자식 프로세스가 있을 수 있습니다. 이 문제를 해결하려면 stop-cal 문제 해결을 참조하십시오.
stop-cal 문제 해결
Calendar Server가 종료될 경우에 고려해야 할 두 가지 사항이 있습니다.
자식 프로세스를 중지하려면
stop-cal을 실행한 후 일부 자식 프로세스가 중지되지 않았을 수 있습니다. 예를 들어, stop-cal은 cshttpd 부모 프로세스를 중지할 수 있지만 cshttpd 자식 프로세스는 중지할 수 없습니다. 이 경우 다음 절차를 사용하여 나머지 Calendar Server 프로세스를 개별적으로 중지해야 합니다.
- Calendar Server가 실행되고 있는 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.
- 각 서비스마다 ps 명령을 입력하여 나머지 Calendar Server 프로세스의 프로세스 아이디(PID)를 확인합니다.
ps -elf | grep cs-process
여기서 cs-process는 enpd, csnotifyd, csdwpd, csadmind 또는 cshttpd입니다. 예를 들면 다음과 같습니다.
ps -elf | grep cshttpd
- 아직 실행 중인 각 프로세스의 PID를 사용하여 kill -15 명령을 입력하여 프로세스를 종료시킵니다. 예를 들면 kill -15 9875입니다.
- 각 ps 명령을 다시 입력하여 모든 Calendar Server 프로세스가 중지되었는지 확인합니다.
Calendar Server 프로세스가 아직 실행 중이라면 kill -9 명령을 입력하여 종료합니다. 예를 들면 kill -9 9875입니다.
잘못된 종료 후 복구하려면
Calendar Server가 제대로 종료되지 않은 경우 다음 단계를 수행합니다.
- 이전 절차(자식 프로세스를 중지하려면)의 단계를 수행합니다.
- LDAP 데이터 캐시 데이터베이스 디렉토리에서 모든 파일을 수동으로 삭제합니다. 남아 있는 이러한 파일이 데이터베이스를 손상시킬 수 있습니다. 파일을 삭제하려면 다음을 수행합니다.
- Calendar Server를 다시 시작합니다.
cal_svr_base/SUNWics5/cal/sbin/start-cal
LDAP 데이터 캐싱 구성 방법에 대한 자세한 내용은 LDAP 데이터 캐시를 활성화하려면을 참조하십시오. 부록 E, "Calendar Server 구성 매개 변수"에는 LDAP 데이터 캐시를 구성하는 데 사용되는 ics.conf 매개 변수 목록이 있습니다. LDAP 데이터 캐시에 대한 자세한 내용은 Sun Java System Communications Services 6 2005Q1 Deployment Planning Guide를 참조하십시오.
백엔드 서버에 연결할 수 없음
프런트엔드 서버에서 백엔드 서버에 연결할 수 없다는 오류 메시지가 표시되면 다음 단계를 수행하십시오.
- 백엔드 서버를 핑하여 서버가 응답하는지 확인합니다.
응답하는 경우 단계 2를 계속합니다. 응답하지 않는 경우 실패의 원인을 확인하고 백엔드 서버가 다시 작동하는 경우 단계 3을 계속합니다.
- CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.
CLD 캐시 옵션을 사용하고 있으며 ics.conf 매개 변수의 서버 이름을 업데이트한 경우, 서버 이름을 제거하려면 CLD 캐시를 지워야 합니다. CLD 캐시에 이전 버전의 항목이 있으면 프런트엔드 서버가 정확한 백엔드 서버로 연결을 설정하지 못하게 되거나 Calendar Server가 옮겨진 후에 달력을 찾을 수 없게 됩니다.
- Calendar Server를 다시 시작합니다.
달력을 찾을 수 없음
CLD 캐시 옵션을 사용 중이고 하나 이상의 달력을 다른 백엔드 서버로 이동했거나 백엔드 서버의 이름을 변경한 경우 다음 단계를 수행합니다.
- 다음의 달력 이동 절차를 따라야 합니다.
- CLD 캐시를 지웁니다. CLD 캐시 지우기를 참조하십시오.
하나 이상의 달력을 다른 백엔드 서버로 이동한 경우 CLD 캐시가 이전 상태가 됩니다. CLD 캐시를 새로 고치려면 캐시를 지워 다시 작성해야 합니다.
완료되지 않는 검색 문제 해결
LDAP Directory Server 구성의 nsslapd-sizelimit 및 nsLookthroughLimit 속성은 검색이 제대로 완료될 수 있을 만큼 커야 합니다. nsSizeLimit이 부족할 경우 끝이 잘려나갈 수 있으며 결과가 표시되지 않습니다. nsLookthroughLimit이 부족할 경우 검색이 완료되지 않을 수 있습니다.
이 절은 다음 내용으로 구성되어 있습니다.
제한 속성에 해당 값이 있는지 확인하려면
- 이러한 속성 값이 제대로 설정되어 있는지 확인하려면 다음 명령을 사용합니다.
ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"여기서 base는 Calendar Server의 사용자와 자원 데이터가 있는 디렉토리 서버의 LDAP 기본 DN이며, user는 사용자가 Calendar Express 가입 -> 달력 검색 대화 상자에 입력할 수 있는 값입니다.
- LDAP 서버가 오류를 반환하면 nsSizeLimit 또는 nsLookthroughLimit 속성이 충분히 크게 설정되지 않았기 때문일 수 있습니다.
제한 속성을 적절한 값으로 설정하려면
이러한 속성의 DN은 다음과 같습니다.
dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config
- ldapmodify를 사용하여 nsLookthroughLimit 값을 동적으로 설정합니다. 즉, 이 속성을 변경하려고 Directory Server를 중지했다가 다시 시작할 필요가 없습니다.
기본값은 5000개입니다. 검색 결과가 보고되지 않는 경우 이 값을 늘릴 수 있습니다. 그러나, 그렇게 하면 LDAP 서버 속도가 느려질 수 있습니다.
제한이 사용되지 않게 하려면 제한을 -1로 설정할 수 있습니다. 그렇게 하면 시스템이 중단될 수 있으므로 주의하십시오.
- nsslapd-sizelimit을 더 높은 값으로 설정하려면 다음 단계를 수행해야 합니다.
csstored에서 성가신 일상 메시지 해제
start-cal 명령은 csstored 프로세스가 구성되어 있지 않더라도 기본적으로 이 프로세스를 시작합니다. 구성되지 않은 csstored 프로세스는 csstored가 실행 중인 모든 시스템에서 해당 프로세스가 구성되지 않았다는 메시지를 24시간마다 표시합니다.
csstored가 구성되지 않은 프로세스를 실행하지 못하게 하여 메시지를 비활성화합니다. csstored 프로세스가 실행되지 않게 하려면 메시지가 표시되는 각 시스템에 표시된 다음 ics.conf 매개 변수를 설정합니다.
service.store.enable="no"
자동 백업을 수행하도록 csstored를 구성한 시스템에서는 프로세스를 비활성화하지 않도록 주의하십시오.
데이터베이스 문제 처리이 절은 Calendar Server 데이터베이스를 포함하여 다양한 문제에 대해 설명합니다.
Berkeley 데이터베이스 도구 찾기
많은 문제 해결 단계를 수행하려면 Berkeley 데이터베이스 유틸리티 프로그램에 액세스해야 합니다. 이러한 유틸리티 프로그램의 한 버전을 Calendar Server 번들에서 사용할 수 있지만 유틸리티 프로그램이 지원되지 않습니다. 자세한 내용은 Sleepycat Software(www.sleepycat.com)에서 직접 참조할 수 있습니다.
이 절은 다음 내용으로 구성되어 있습니다.
Berkeley 데이터베이스 유틸리티에 액세스하려면
LD_LIBRARY_PATH 환경 변수를 설정하고 내보내어 다음 디렉토리를 반영합니다.
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/
사용 가능한 도구 목록
표 22-3에는 일반적으로 사용되는 Berkeley 데이터베이스 도구(유틸리티 프로그램)가 나열되어 있습니다.
데이터베이스 교착 상태 검색 및 수정하려면
Berkeley 데이터베이스가 교착 상태인 경우 데이터베이스를 재설정해야 합니다. 이러한 조건은 가능한 빨리 검색해야 합니다.
시스템에서 데이터베이스를 주기적으로 확인하여 교착 상태를 검색하고 관리자에게 알리게 하려면
데이터베이스 손상 검색
달력 데이터베이스 손상은 시스템 자원 경쟁, 하드웨어 오류, 응용 프로그램 오류, 데이터베이스 오류 그리고 물론 사람에 의한 실수 등 여러 가지 원인에 의해 발생할 수 있습니다. 이 절에서는 Calendar Database 손상을 검색하는 방법에 대해 설명합니다.
데이터베이스 손상 기본
누구도 손상 없는 데이터베이스를 보장할 수 없습니다. 데이터 손실과 작업 중단 시간을 최소화할 수 있습니다. 데이터베이스와 Calendar Server를 자세히 모니터하여 손상을 조기에 검색해야 합니다. 손상이 발견될 경우 복구할 수 있도록 전체 백업을 자주 수행해야 합니다.
달력 데이터베이스에는 다음과 같은 두 가지 수준의 손상이 발생할 수 있습니다.
로그 파일 모니터링
경보 로그를 포함하여 Calendar Server 로그 파일을 모니터하여 데이터베이스 손상을 나타내는 오류 메시지가 있는지 확인합니다. 로그 파일에 대한 자세한 내용은 Calendar Server 로그 파일 사용을 참조하십시오.
정기적으로 로그 파일에서 경고, 심각, 오류 및 경고 수준의 오류가 있는지 검사하고 그런 오류가 발견되면 해당 이벤트를 조사하여 Calendar Server 작업과 관련된 원인을 찾아야 합니다. 알림 및 정보 수준의 로그 이벤트는 정상적인 Calendar Server 작업 중에 발생하며 서버 작동을 모니터할 수 있도록 제공됩니다.
데이터베이스 디렉토리에서 어떤 트랜잭션 로그 파일도 제거하지 마십시오. 트랜잭션 로그 파일은 트랜잭션 업데이트(추가, 수정, 삭제)를 포함하고 있으므로 이 파일을 제거하면 복구 불가능한 달력 데이터베이스 손상을 발생시킬 수 있습니다.
csmonitor 사용
csmonitor 유틸리티를 사용하여 Calendar Server를 모니터합니다. 이 유틸리티는 여러 트랜잭션 로그 파일이 있거나 달력 데이터베이스의 디스크 공간 부족 등과 같은 문제가 검색될 경우 관리자에게 경고 전자 메일을 보냅니다. 자세한 내용은 csmonitor를 참조하십시오.
달력 데이터베이스 손상 검사
check 명령을 사용하여 달력 등록 정보(calprops) 및 이벤트와 할 일(작업)을 포함한 달력 데이터베이스에서 손상을 검색합니다. check 명령이 해결할 수 없는 비일관성 오류가 발견된 경우에는 출력으로 상황을 보고합니다.
check 명령은 경보나 그룹 예약 엔진(GSE) 데이터베이스의 손상을 확인하지 않습니다.
달력 데이터베이스 손상을 검사하려면
- Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.
- Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.
- 아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다. 데이터베이스(.db) 파일만 복사합니다. 공유(__db.*) 또는 로그(log.*) 파일은 복사할 필요가 없습니다.
- cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
- 달력 데이터베이스의 복사본에 check 명령을 실행합니다.
./csdb check dbdir > /tmp/check.out 2>&1
dbdir을 지정하지 않은 경우 check은 현재 디렉토리의 데이터베이스를 사용합니다.
check 명령은 많은 정보를 생성할 수 있으므로 이번 예와 같이 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.
- check를 마치면 출력 파일을 검토합니다. 데이터베이스가 손상된 경우 rebuild 명령을 실행합니다. 손상된 달력 데이터베이스 재구축을 참조하십시오.
데이터베이스가 손상된 경우 서비스 중단 방지(읽기 전용 모드)
이 절에서는 복구 모드에서 손상된 데이터베이스를 액세스 가능한 상태로 유지하는 방법에 대해 설명하며, 다음 내용으로 구성되어 있습니다.
읽기 전용 모드 사용
데이터베이스 손상이 발생할 경우 서비스 중단을 방지하는 한 가지 방법은 데이터베이스를 읽기 전용 모드로 전환하는 것입니다. 읽기 전용 모드에서는 최종 사용자가 데이터베이스 항목을 읽을 수 있지만 항목을 추가, 수정 또는 삭제할 수 없습니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.
주
읽을 수 없는 지점에서 데이터베이스가 손상된 경우 백업을 복원할 수 있을 만큼 충분한 시간 동안 서비스를 중단해야 합니다. 백업을 복원하는 가장 빠른 방법은 손상 없는 핫 백업을 사용하는 것입니다. 핫 백업을 복원하려면을 참조하십시오.
데이터베이스를 읽기 전용 모드로 전환하려면
- 필요하지 않은 경우 달력 서비스를 일시적으로 중지하여 데이터베이스의 추가 손상을 방지할 수 있습니다. 달력 서비스를 중지하려면 다음을 입력합니다.
cal_svr_base/SUNWics5/cal/sbin/stop-cal
- 명령줄에서 ics.conf가 있는 디렉토리로 변경합니다.
cd /etc/opt/SUNWics5/config
- 달력 데이터베이스에 대한 읽기 전용 모드를 지정합니다.
caldb.berkeleydb.readonly="yes"
- ics.conf 파일 편집이 완료되면 Calendar Server를 다시 시작합니다.
cal_svr_base/SUNWics5/cal/sbin/start-cal
ics.conf 변경 내용을 적용하려면 서비스를 다시 시작해야 합니다.
일반 데이터베이스 오류 처리
이 절에서는 일반적인 몇 가지 데이터베이스 오류에 대해 설명하고 치료 방법을 제안합니다. 이 절은 다음 내용으로 구성되어 있습니다.
csadmind가 시작되지 않거나 시작 중에 충돌함
csadmind는 그룹 예약 엔진(GSE)과 경보 디스패치 엔진을 모두 처리하는 서비스이기 때문에 GSE 대기열이나 경보 대기열의 위반 항목으로 인해 이러한 문제가 발생할 수 있습니다.
치료 방법:
- csadmind가 실행 중이 아닌 경우 stop-cal을 즉시 실행합니다.
달력 서버를 실행된 상태로 두면 트랜잭션 로그가 누적되므로 데이터베이스에 추가 손상이 발생하여 트랜잭션 로그 파일을 데이터베이스에 맞게 조정하는 데 더 많은 시간이 걸릴 수 있습니다.
- csadmind를 다시 시작해 보십시오(start-cal을 다시 실행).
성공적으로 시작되면 다음을 수행하여 두 대기열이 작동하는지 확인합니다.
- csschedule을 사용하여 GSE 대기열 검사
- dbrig를 사용하여 경보 대기열 검사
csschedule 및 dbrig 실행 지침은 부록 D, "Calendar Server 명령줄 유틸리티 참조"를 참조하십시오.
- csadmind가 덤프와 충돌하는 경우 pstack을 분석합니다.
추적 중에 GSE 관련 함수(GSE 문자가 포함되어 있음)가 발견되면 GSE 대기열의 첫 번째 항목과 이벤트 데이터베이스의 참조 항목을 조사합니다. 대부분의 경우 GSE 항목에서 참조되는 이벤트가 위반 항목입니다. 이 문제를 해결하려면 다음을 수행합니다.
- csschedule을 사용하여 GSE 항목을 제거합니다.
- cscomponents를 사용하여 데이터베이스에서 위반 이벤트를 제거합니다.
csschedule 및 cscomponents 실행 지침은 부록 D, "Calendar Server 명령줄 유틸리티 참조"를 참조하십시오.
- 항목이 손상되지 않은 경우 Calendar Server를 처리할 수 없는 특수한 경우일 수 있습니다.
다음 단계를 수행합니다.
- 손상된 데이터베이스의 달력 환경 스냅샷을 만든 다음 고객 지원부에 문의하십시오.
환경 백업을 만들려면
- 다음 위치에 있는 db_checkpoint 유틸리티를 사용합니다.
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint- db_archive -s를 실행하여 모든 데이터베이스 파일을 식별한 다음 CD, DVD, 테이프 등과 같은 이동식 매체에 복사합니다.
- db_archive -l을 실행하여 모든 로그 파일을 식별한 다음 적용되지 않은 파일을 이동식 매체 장치에 복사합니다.
- 서비스 중단을 방지하려면 다음 단계를 수행합니다.
- 달력 데이터베이스를 일시적으로 읽기 전용 상태로 전환합니다.
이 상태에서는 트랜잭션을 추가, 수정 또는 삭제할 수 없습니다. 최종 사용자가 달력 데이터를 추가, 수정 또는 삭제하려고 하면 오류 메시지가 표시됩니다. 또한, 데이터베이스가 읽기 전용 모드인 동안에는 달력 이벤트와 할 일을 추가, 수정 또는 삭제하는 관리자 도구가 작동되지 않습니다.
달력 데이터베이스를 읽기 전용 모드로 전환하려면 ics.conf 파일을 편집하고 다음 매개 변수를 "yes"로 설정합니다.
caldb.berkeleydb.readonly="yes"
- 핫 백업 복사본으로 되돌립니다.
csstored를 구성하여 활성화하면 몇 분 이내에 최신 상태의 핫 백업을 사용할 수 있습니다. 항상 핫 백업 복사본을 확인하여 복사본이 손상되지 않았는지 확인해야 합니다(db_verify 실행).
핫 백업 복사본을 복원하는 방법에 대한 지침은 핫 백업을 복원하려면을 참조하십시오.
- 기타 오류의 경우 덤프를 수행하고 절차를 다시 로드하여 데이터베이스를 복구할 수 있는지 확인합니다.
이 절차에 대해서는 덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구에서 설명합니다.
서비스가 중단되어 최종 사용자가 연결할 수 없음 – 비활성 잠금
이 문제는 Berkeley DB 데이터베이스 페이지 잠금을 보관하는 제어 스레드가 잠금을 해제하지 않고 종료되어 발생할 수 있습니다. 문제를 확인하려면 cshttpd 프로세스의 pstack 및 csadmind를 실행합니다(pstack는 /usr/bin/pstack에 있는 표준 UNIX 유틸리티임), 잠금을 위해 대기 중인 스레드가 표시됩니다.
문제를 해결하려면 다음과 같은 방법으로 Calendar Server를 다시 시작합니다.
csdb 재구축 완료 안됨 – 데이터베이스 루핑
데이터베이스 루핑은 일반적으로 데이터베이스 파일이 손상되어 발생합니다. 데이터베이스가 손상되었기 때문에 복구할 수 없습니다. 다음과 같은 여러 가지 옵션이 있습니다.
- 핫 백업으로 되돌립니다.
손상이 최근에 발생한 경우 핫 백업 중 하나를 사용할 수 있습니다.
- 재해 아카이브 복구 프로세스를 사용합니다.
제안되는 프로세스는 핫 백업을 복원하려면을 참조하십시오.
- 덤프를 사용하고 절차를 다시 로드합니다(덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구).
손상된 달력 데이터베이스 재구축
이 절에서는 csdb rebuild 명령 사용 방법에 대해 설명하고 다음 내용으로 구성되어 있습니다.
재구축 개요
rebuild 명령은 달력 데이터베이스를 검사하고 달력 등록 정보(calprops) 이벤트 및 수행할 작업(태스크)이 손상되었는지 확인합니다. rebuild 명령이 비일관성을 발견한 경우 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 달력 데이터베이스를 다시 만듭니다(.db 파일).
-g 옵션 없는 rebuild 명령은 그룹 예약 엔진(GSE) 데이터베이스를 제외하고 모든 데이터베이스를 재구축합니다. GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.
rebuild 명령을 사용하기 전에 GSE 데이터베이스에 항목이 있는지 확인하려면 csschedule -v list 명령을 실행한 다음 GSE가 항목 처리를 마치게 합니다.
달력 데이터베이스를 재구축하려면
- Calendar Server가 설치된 시스템에 대한 관리 권한이 있는 사용자로 로그인합니다.
- Calendar Server를 중지합니다.
- 달력 데이터베이스의 복사본을 만들어 /tmp/db 디렉토리에 넣습니다. 데이터베이스(.db) 파일과 로그(log.*) 파일을 복사합니다. 공유(__db.*) 파일은 복사할 필요가 없습니다.
- cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 기본 디렉토리에 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
- 달력 데이터베이스의 복사본에서 rebuild 명령을 실행합니다.
./csdb rebuild /tmp/db /tmp/
데이터베이스 경로를 지정하지 않은 경우 rebuild는 현재 디렉토리를 사용합니다. /tmp/ 매개 변수는 다시 작성된 데이터베이스의 대상 디렉토리를 지정합니다.
GSE 데이터베이스도 재구축하려면 -g 옵션을 포함시킵니다.
rebuild 명령은 많은 정보를 생성할 수 있으므로 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.
- rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다. 재구축을 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt
- 이전 단계에서 재구축이 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.
- 손상된 데이터베이스에 공유(__db.*) 또는 로그(log.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.
- Calendar Server를 다시 시작합니다.
샘플 재구축 출력
다음 예에서는 명령과 해당 출력을 보여 줍니다.
주
이전 샘플 출력에서는 이벤트와 할 일 데이터베이스가 각각 두 번씩 검색되었습니다. 이는 오류가 아닙니다. 첫 번째 검색에서 calprops 데이터베이스의 정보를 확인한 다음 두 번째 검색에서 데이터베이스에서 calprops를 액세스할 수 있는지를 확인합니다.
덤프 및 로드 절차를 사용하여 달력 데이터베이스 복구
이 절은 다음 내용으로 구성되어 있습니다.
덤프 및 로드 개요
덤프 및 로드 절차를 사용하여 손상된 데이터베이스를 복구합니다. 덤프 및 로드 절차는 Berkeley 데이터베이스 db_dump 및 db_load 유틸리티를 사용하며, Calendar Server는 이러한 유틸리티를 다음 디렉토리에 보관합니다.
cal_svr_base/SUNWics5/cal/tools/unsupported/bin
db_dump 유틸리티는 데이터베이스 파일을 읽고 그 데이터베이스 항목을 db_load 유틸리티와 호환되는 형식을 사용하여 출력 파일에 기록합니다.
db_dump 및 db_load 유틸리티에 대한 설명서는 다음 Sleepycat Software 웹 사이트를 참조하십시오.
http://www.sleepycat.com/docs/utility/index.html
db_dump 및 db_load 유틸리티를 사용한 데이터베이스 복구의 성공 여부는 데이터베이스 손상 정도에 따라 결정됩니다. 데이터베이스를 성공적으로 복구하려면 db_dump 옵션을 여러 차례 시도해야 하는 경우도 있습니다. 그러나 데이터베이스가 심각하게 손상될 경우 복구가 불가능하고 따라서 데이터베이스의 손상 없는 최신 버전 핫 백업 또는 아카이브 백업으로 되돌려야 할 수도 있습니다.
주
덤프 및 로드 절차를 수행하려면 달력 데이터베이스가 Berkeley DB 버전 3.2.9 이상이어야 합니다. 이전 버전인 경우에는 먼저 cs5migrate 유틸리티를 실행하여 달력 데이터베이스를 업그레이드합니다.
최신 버전의 cs5migrate를 구하려면 Sun 기술 지원에 문의하십시오.
덤프 및 로드 절차를 수행하려면
- Calendar Server가 실행되는 사용자 및 그룹(예: icsuser 및 icsgroup) 또는 수퍼유저(root)로 로그인합니다.
- 필요할 경우 Calendar Server를 중지합니다.
- csbackup, Sun StorEdge Enterprise Backup™ 소프트웨어 또는 Legato Networker와 같은 유틸리티를 사용하여 달력 데이터베이스를 백업합니다. 자세한 내용은 17장, "Calendar Server 데이터 백업 및 복원"을 참조하십시오.
- db_dump 유틸리티를 사용하여 각 손상된 데이터베이스 파일을 덤프합니다. 데이터베이스 파일은 ics50calprops.db, ics50journals.db, ics50alarms.db, ics50events.db, ics50todos.db 및 ics50gse.db입니다.
데이터베이스가 복구될 때까지(또는 데이터베이스가 복구 불가능함을 확인할 때까지) 다음 옵션을 순서대로 사용하여 db_dump를 실행합니다.
- db_load 유틸리티를 사용하여 출력 파일을 새 데이터베이스 파일로 로드합니다.
예를 들면 다음과 같습니다.db_load new.ics50events.db < ics50events.db.txt
db_load가 홀수 개수의 키나 데이터 항목을 보고할 경우 단계 4에서 db_dump 출력 파일을 편집하여 홀수 키나 데이터 항목을 제거합니다. 그런 다음 db_load를 다시 실행합니다.
- 손상된 달력 데이터베이스 재구축의 설명대로 csdb rebuild 명령을 사용하여 복구된 데이터베이스 파일을 재구축합니다.
재구축을 마치면 출력 파일에서 출력을 검토합니다. 재구축을 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt
csdb rebuild 명령이 성공하지 못한 경우 단계 4로 돌아가 다음 db_dump 옵션(-r 또는 -R)을 사용하여 데이터베이스를 덤프합니다.
db_dump -R 옵션이 손상된 데이터베이스를 복구하지 못한 경우 Sun Microsystems 기술 지원 또는 영업 담당자에게 연락하여 도움을 받으십시오. 그 사이에 손상 없는 최신 데이터베이스 백업으로 되돌려야 할 수도 있습니다.
자동 백업 복사본 복원
10장, "자동 백업 구성(csstored)"에 설명된 자동 백업 기능을 사용한 경우 활성 데이터베이스가 손상되었다면 백업 복사본을 복원할 수 있습니다.
이 절에서는 서로 다른 두 자동 백업 복원 방법에 대해 설명합니다.
복원하기 전에
백업을 복원하기 전에 다음을 확인해야 합니다.
핫 백업을 복원하려면
활성 데이터베이스가 손상된 경우 핫 백업을 가장 먼저 선택해야 합니다. 핫 백업을 복원하려면 다음 단계를 수행합니다.
- 적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.
- 쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.
- 새 (복구) 디렉토리를 만듭니다.
- 현재 핫 백업 복사본을 새 복구 데이터베이스 디렉토리에 복사합니다.
- 손상된 활성 데이터베이스 디렉토리의 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.
- 데이터베이스의 아카이브 복사본을 저장하는 경우 경우 활성 데이터베이스에 적용되지 않은 로그를 아카이브 디렉토리에 복사하여 아카이브 백업 복사를 완료합니다.
- 새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.
예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.
db_recover -c -h recoverydb
- log.* 파일을 새 복구 디렉토리에 그대로 둡니다.
db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 42부터 Berkeley DB는 로그 파일이 그대로 유지되는 것으로 기대합니다.
- 새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.
지침은 달력 데이터베이스 손상 검사를 참조하십시오.
- 새 복구 디렉토리에 대해 csdb -v list를 실행합니다.
- 새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.
- 새 스냅샷 역할을 하도록 새 활성 데이터베이스를 핫 백업 디렉토리에 복사합니다. 다음에 정기 스냅샷을 찍을 때까지 모든 새 로그가 이 복사본에 적용됩니다.
- Calendar Server를 시작합니다.
- 새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 핫 백업을 식별합니다.
- 핫 백업에 대한 역방향 작업을 통해 db_verify 및 csdb -v list를 하나씩 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다.
- 통과한 첫 번째 핫 백업 복사본을 활성 데이터베이스 디렉토리에 복원할 수 있습니다. 이 때 손상된 활성 데이터베이스를 손상 없는 핫 백업으로 대체합니다.
- 핫 백업과 아카이브 백업이 없는 경우 기술 지원부에 문의하십시오. 아카이브 백업이 있는 경우 다음 절차를 수행하십시오. 아카이브 백업을 복원하려면을 참조하십시오.
아카이브 백업을 복원하려면
손상되지 않은 핫 백업이 없지만 아카이브 백업과 해당 트랜잭션 로그가 있는 경우 다음 단계를 수행하여 손상되지 않은 최신 아카이브 데이터베이스 버전을 복원할 수 있습니다.
- 적용되지 않았거나 손상된 활성 데이터베이스 디렉토리에 쓰기 위해 열려 있는 로그 파일을 식별합니다.
- 쓰기 위해 열려 있는 로그를 닫습니다. 이 로그에는 최신 트랜잭션이 포함되어 있습니다.
- 새 (복구) 디렉토리를 만듭니다.
- 최신 아카이브 복사본과 해당 로그 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.
- 손상된 활성 데이터베이스 디렉토리의 적용되지 않은 log.* 파일을 새 복구 데이터베이스 디렉토리에 복사합니다.
- 새 복구 데이터베이스에 대해 지정된 -c -h 옵션과 함께 db_recover를 실행합니다.
예를 들어, 새 복구 디렉토리가 recoverydb인 경우 명령은 다음과 같습니다.
db_recover -c -h recoverydb
- log.* 파일을 새 복구 디렉토리에 그대로 둡니다.
db_recover 프로그램이 로그 파일을 새 복구 데이터베이스에 적용했지만 버전 4.2부터 Berkeley DB는 로그 파일이 해당 위치에 그대로 있는 것으로 기대합니다.
- 새 복구 디렉토리에 있는 데이터베이스 파일에 대해 db_verify를 실행합니다.
지침은 달력 데이터베이스 손상 검사를 참조하십시오.
- 새 복구 디렉토리에 대해 csdb -v list를 실행합니다.
- 새 복구 디렉토리가 앞의 세 복구 단계를 모두 통과한 경우 손상된 이전 활성 데이터베이스를 새 복구 데이터베이스로 대체합니다.
- 새 스냅샷 역할을 하도록 새 활성 데이터베이스를 핫 백업 디렉토리에 복사합니다.
- Calendar Server를 시작합니다.
- 새 복구 디렉토리에서 단계가 실패할 경우 다음과 같은 방법으로 손상되지 않은 이전 아카이브 백업을 식별합니다.
- 아카이브 백업 복사본 역방향 작업을 통해 각각에 대해 세 복구 프로그램을 차례로 실행하여 손상되지 않은 최신 복사본을 찾습니다.
db_recover -c-h, db_verify 및 csdb -v list- 통과한 첫 번째 핫 백업 복사본을 활성 데이터베이스 디렉토리에 복원할 수 있습니다. 이 때 손상된 활성 데이터베이스를 손상 없는 핫 백업으로 대체합니다.
- 핫 백업과 아카이브 백업이 없는 경우 기술 지원부에 문의하십시오. 아카이브 백업이 있는 경우 다음 절차를 수행하십시오. 아카이브 백업을 복원하려면을 참조하십시오.
사용자 정의 백업 스크립트 복구
이 절은 다음 내용으로 구성되어 있습니다.
Berkeley 도구가 동적 라이브러리에 컴파일됨
db_recover와 같은 Berkeley 데이터베이스 도구를 사용하여 사용자 정의 백업 스크립트를 만든 경우 Calendar Server 2004Q2 이상 버전으로 업그레이드하면 해당 스크립트가 더 이상 작동하지 않습니다. 이전 Calendar Server 버전에서는 정적 라이브러리를 사용하여 도구를 컴파일했기 때문입니다. 현재 버전에서는 도구를 동적 라이브러리 libdb-4.2.so에 컴파일합니다.
사용자 정의 백업 스크립트를 복구하려면
기존 사용자 정의 스크립트가 있는 새 동적 라이브러리를 사용하려면 다음 전역 변수를 설정합니다.
LD_LIBRARY_PATH=libdb-4.2.so