Calendar Server는 여러 디렉토리에 많은 데이터베이스 파일을 유지합니다. 10 장, 자동 백업 구성(csstored)에 설명된 자동 백업 프로세스를 구현하거나 백업 시스템을 직접 구현하여 데이터베이스 파일을 보호해야 합니다. csdb 유틸리티를 사용하여 데이터베이스 파일을 관리할 수 있습니다.
이 장에서는 csdb를 사용하는 Calendar Service 데이터베이스 관리 방법을 설명하며, 다음 내용으로 구성되어 있습니다.
데이터베이스 파일을 관리하려면 Calendar Server 유틸리티 csdb 를 사용합니다. 이 절은 다음 내용으로 구성되어 있습니다.
달력 데이터베이스 유틸리티 csdb는 데이터베이스 파일을 3개의 논리적 데이터베이스로 처리합니다.
caldb는 데이터베이스 디렉토리에 있는 모든 .db 파일 및 _db.* 파일로 구성됩니다. 다음은 달력 데이터베이스 파일(cld_cache 및 ldap_cache 하위 디렉토리 포함)에 대한 기본 위치입니다.
/var/opt/SUNWics5/csdb
원할 경우 Calendar Server 구성 프로그램(csconfigurator.sh) 실행 시 다른 디렉토리를 지정할 수 있습니다. 구성 프로그램에 대한 자세한 내용은 3 장, Calendar Server 구성 프로그램(csconfigurator.sh) 을 참조하십시오.
다음 표에서는 달력 데이터베이스(caldb) 파일에 대해 설명합니다.
표 16–1 Calendar Server 데이터베이스 파일
파일 |
설명 |
---|---|
ics50calprops.db |
모든 달력용 달력 등록 정보. 달력 아이디(calid ), 달력 이름, 액세스 제어 목록(ACL) 및 소유자를 포함합니다. |
ics50events.db |
모든 달력용 이벤트 |
ics50todos.db |
모든 달력용 수행할 작업(태스크) |
ics50alarms.db |
모든 이벤트 및 수행할 작업(태스크)의 경보 |
ics50gse.db |
그룹 예약 엔진(GSE)에 대한 예약 요청 대기열 |
ics50journals.db |
달력 저널. 현재 릴리스에서는 저널이 구현되지 않습니다. |
ics50caldb.conf |
데이터베이스 버전 아이디 |
ics50recurring.db |
반복 이벤트 |
ics50deletelog.db |
삭제된 이벤트 및 수행할 작업(태스크). 18 장, 삭제 로그 데이터베이스 관리을 참조하십시오. |
세션 데이터베이스는 /opt/SUNWics5/cal/lib/admin/session/ 및 /opt/SUNWics5/cal/lib/http/session/ 디렉토리에 있는 모든 파일로 구성됩니다.
통계 데이터베이스는 counter 디렉토리에 있는 모든 파일로 구성됩니다.
/opt/SUNWics5/cal/lib/counter/
csdb 유틸리티 -t 옵션을 사용하여 대상 데이터베이스를 지정할 수 있습니다.
-t caldb – 달력 데이터베이스
-t sessdb – 세션 데이터베이스
-t statdb – 통계 데이터베이스
-t 옵션을 포함하지 않은 경우 csdb는 세 가지 데이터베이스 모두에서 실행됩니다. 단, check 및 rebuild는 달력 데이터베이스에서만 실행됩니다.
이 절에서는 csdb 유틸리티를 사용하여 다음 관리 작업을 수행하는 방법을 사용합니다.
csdb 유틸리티를 실행하려면 Calendar Server가 실행되고 있는 시스템에 대해 관리 권한을 가진 사용자로 로그인해야 합니다. 자세한 내용은 부록 D, Calendar Server 명령줄 유틸리티 참조 를 참조하십시오.
데이터베이스 그룹(caldb, sessdb, statdb)의 상태를 보려면 csdb 유틸리티 list 명령을 사용합니다.
데이터베이스 상태를 나열하려면
Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.
Calendar Server는 실행 중이어도 되고 중지해도 되지만 가능하면 Calendar Server를 중지하는 것이 좋습니다.
/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin |
하나 또는 모든 데이터베이스 그룹에 대해 list 명령을 실행합니다. 예를 들어, 세 데이터베이스 그룹 모두의 상태 및 통계를 나열하려면 다음 명령을 사용합니다.
./csdb list
다음 코드는 샘플 출력을 나타냅니다.
Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) Calendar database version: 3.0.0 [BerkeleyDB] Total database size in bytes: 57344 Session database version: 1.0.0 [BerkeleyDB] Total database size in bytes: 0 Counter database version: 1.0.0 [Memory Mapped Files] Total database size in bytes: 118792 |
또는 세부 정보 표시 모드를 사용할 수 있습니다. 예를 들면 다음과 같습니다.
./csdb -v list
다음 샘플 코드는 세부 정보 표시 출력을 나타냅니다.
Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) Calendar database version: 3.0.0 [BerkeleyDB] Total database size in bytes: 57344 Total number of calendars: 2 Total number of events: 0 Total number of tasks: 0 Total number of alarms: 0 Total number of gse entries: 0 Total number of master component entries: 0 Total number of deletelog entries: 0 Total logfile size in bytes: 5779919 Session database version: 1.0.0 [BerkeleyDB] Total database size in bytes: 0 Total logfile size in bytes: 0 Counter database version: 1.0.0 [Memory Mapped Files] Total database size in bytes: 118792 |
또는 -t 옵션을 사용하여 하나의 대상 데이터베이스 그룹(caldb, sessdb 또는 statdb)을 지정합니다. 예를 들어, 달력 데이터베이스의 데이터베이스 상태 및 통계만 보려면 다음 명령을 사용합니다.
csdb -t caldb list
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 명령을 실행하여 손상된 복사본을 재구축할 수도 있습니다.
손상된 달력 데이터베이스(caldb)를 복구하려면 csdb 유틸리티 rebuild 명령을 사용합니다. rebuild 명령은 손상이 있는지 모든 달력 데이터베이스를 스캔합니다. rebuild 명령이 비일관성을 발견한 경우 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 달력 데이터베이스를 재구축합니다(.db 파일).
rebuild 명령은 많은 정보를 생성할 수 있으므로 stdout 및 stderr을 포함한 모든 출력을 파일로 재지정하는 것도 바람직합니다.
다음 지침에서 rebuild 명령은 그룹 예약 엔진(GSE) 데이터베이스를 재구축하지 않습니다.
GSE 데이터베이스 없이 달력 데이터베이스를 재구축하려면 다음 작업을 수행합니다.
Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.
Calendar Server를 중지합니다.
아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다. 데이터베이스(.db) 파일과 로그(log.*) 파일을 복사합니다. 공유(__db.*) 파일은 복사할 필요가 없습니다.
cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다. 예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin |
sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.
달력 데이터베이스의 복사본에 대해 rebuild 명령을 실행합니다.
./csdb rebuild /tmp/db /tmp/ |
데이터베이스 디렉토리를 지정하지 않는 경우, rebuild는 현재 디렉토리의 데이터베이스를 사용합니다. 이전 예에서 /tmp/ 매개 변수는 재구성된 데이터베이스에 대해 대상 디렉토리를 지정합니다.
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.
그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.
예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
./csdb rebuild db_0629
Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
./csdb rebuild db_0615
Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
./csdb rebuild db_0601
... etc.
rebuild 명령은 다시 만든 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.
rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다. 해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt |
rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.
손상된 데이터베이스에 공유(__db.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.
Calendar Server를 다시 시작합니다.
사이트에서 그룹 예약을 구현했다면 재구축에 GSE 데이터베이스를 포함해야 합니다.
달력 데이터베이스와 GSE 데이터베이스를 재구축하려면 다음 작업을 수행합니다.
csschedule -v list 명령을 실행하여 GSE 데이터베이스에 항목이 있는지 확인하고 GSE가 항목 처리를 마치게 합니다.
Calendar Server가 설치된 시스템에 대해 관리 권한이 있는 사용자로 로그인합니다.
Calendar Server를 중지합니다.
아직 달력 데이터베이스의 복사본을 만들지 않은 경우 지금 만듭니다.
데이터베이스(.db) 파일과 로그( log.*) 파일을 복사합니다. 공유(__db.*) 파일은 복사할 필요가 없습니다.
cal_svr_base/SUNWics5/cal/sbin 디렉토리로 변경합니다.
예를 들어, Solaris 운영 체제에서 다음과 같이 입력합니다.
cd /opt/SUNWics5/cal/sbin
sbin 디렉토리의 디스크 공간이 문제라면 다른 디렉토리에서 rebuild 명령을 실행합니다.
달력 데이터베이스 복사본에 대해 rebuild 명령을 실행합니다.
./csdb -g rebuild /tmp/db /tmp/
데이터베이스 디렉토리를 지정하지 않는 경우, rebuild는 현재 디렉토리의 데이터베이스를 사용합니다. 이전 예에서 /tmp/ 매개 변수는 재구성된 데이터베이스에 대해 대상 디렉토리를 지정합니다.
항상 최신 백업 복사본을 사용하여 달력 데이터베이스를 재구축합니다.
그러나 심각한 데이터 손실이 발생했고 그 동안 정기적으로 데이터베이스를 백업했으며 2개 이상의 복사본이 존재하는 경우, 최신 복사본에서 가장 오래된 복사본으로 재구축합니다. 한 가지 단점은, 삭제했던 달력 구성 요소가 다시 만들어진 데이터베이스에 나타난다는 것입니다.
예를 들어, db_0601, db_0615 및 db_0629 디렉토리에 백업 달력 데이터베이스 파일 3세트가 있는 경우, 다음 순서대로 rebuild 명령을 실행합니다.
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601 |
그러면 rebuild 명령은 재구축된 데이터베이스를 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 디렉토리에 저장합니다.
rebuild를 마치면 rebuild.out 파일에서 출력을 검토합니다.
해당 재구축이 성공했을 경우 rebuild.out 파일의 마지막 행은 다음과 같습니다.
Calendar database has been rebuilt |
rebuild가 성공했음을 확인한 다음 재구축된 데이터베이스(.db) 파일을 rebuild_db 디렉토리에서 작업 데이터베이스로 복사합니다.
손상된 데이터베이스에 공유(__db.*) 파일이 있는 경우 이들을 다른 디렉토리로 옮깁니다.
Calendar Server를 다시 시작합니다.
이전 샘플 출력에서는 이벤트와 작업 데이터베이스가 각각 두 번씩 검색되었습니다. 이는 오류가 아닙니다. 처음 검색에서는 calprops 데이터베이스 정보를 확인합니다. 재검색에서는 calprops를 달력 데이터베이스에서 액세스할 수 있는지 확인합니다.
다음 예에서는 명령과 해당 출력을 보여 줍니다.
# ./csdb -g rebuild Building calprops based on component information. Please be patient, this may take a while... Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning deletelog database... 15 deletelog entries scanned Scanning gse database... 21 gse entries scanned Scanning recurring database... 12 recurring entries scanned Successful components db scan Calendar database has been rebuilt Building components based on calprops information. Please be patient, this may take a while... Scanning calprops database to uncover events... 25 calendars scanned Scanning calprops database to uncover todos... 25 calendars scanned Successful calprops db scan Calendar database has been rebuilt |
달력 데이터베이스를 삭제하려면 csdb 유틸리티 delete 명령을 사용합니다. Calendar Server를 중지해야 합니다.
대상 데이터베이스( caldb, sessdb 또는 statdb)를 지정하려면 -t 옵션을 사용합니다. 그렇지 않으면 csdb는 세 가지 데이터베이스를 모두 삭제합니다.
예를 들어, 달력 데이터베이스를 삭제하려면 다음 명령을 사용합니다.
csdb -t caldb delete
csdb 유틸리티는 데이터베이스를 삭제하기 전에 경고 메시지를 표시합니다.