- 마스터 프로세스
- 프로세스 중 마스터 프로세스(cub_master)가 가장 먼저 시작된다. 각 프로세스를 연결하는 helper 역할을 한다.
- 브로커 프로세스
- 최초에 응용프로그램이 접속하는 프로세스
- 연결이 종료될 때까지 질의 요청을 처리할 프로세스인 CAS 프로세스(cub_cas)를 할당한다.
- CAS 프로세스
- Common Application Server.
- CAS 프로세스는 연결 요청을 마스터 프로세스에 전달한다.
- 서버 프로세스
- 서버 프로세스는 항상 특정 데이터베이스와 일대일로 대응된다.
- 실제 데이터베이스 서버라고 생각하면 될 듯 하다.
- 쿼리 요청이 응용프로그램(JDBC, ODBC 등 인터페이스)으로 들어온다.
- 브로커 프로세스가 응용프로그램에게서 요청을 받는다.
- 브로커 프로세스가 요청에 의해 CAS(common application server) 하나를 할당한다.
- CAS 프로세스는 마스터 프로세스에 연결 요청을 전달한다.
- 마스터 프로세스가 요청을 서버 프로세스를 찾는다.
- 1 ~ 5 프로세스가 정상적으로 이루어졌다면, 이후 응용프로그램 - CAS 프로세스 - 서버 프로세스 의 관계를 유지하며, 질의요청을 처리한다. 두 프로세스인 브로커 프로세스, 마스터 프로세스는 연결 요청을 처리하여 응용프로그램 - CAS 프로세스 - 서버 프로세스간 연결을 도와준다.
큐브리드 관련 프로세스들
cms 2776 1429 0 19:11 pts/0 00:00:00 cub_master #마스터
cms 2782 1429 0 19:11 ? 00:00:46 cub_broker #브로커
cms 2783 1429 0 19:11 ? 00:00:00 query_editor_cub_cas_1 #cas
cms 2784 1429 0 19:11 ? 00:00:00 query_editor_cub_cas_2
cms 2785 1429 0 19:11 ? 00:00:00 query_editor_cub_cas_3
cms 2787 1429 0 19:11 ? 00:00:00 query_editor_cub_cas_4
cms 2789 1429 0 19:11 ? 00:00:00 query_editor_cub_cas_5
cms 2801 1429 0 19:11 ? 00:00:46 cub_broker #브로커
cms 2802 1429 0 19:11 ? 00:00:00 broker1_cub_cas_1 #cas
cms 2803 1429 0 19:11 ? 00:00:00 broker1_cub_cas_2
cms 2804 1429 0 19:11 ? 00:00:00 broker1_cub_cas_3
cms 2805 1429 0 19:11 ? 00:00:00 broker1_cub_cas_4
cms 2806 1429 0 19:11 ? 00:00:00 broker1_cub_cas_5
cms 2818 1429 0 19:11 ? 00:00:05 cub_manager start #큐브리드 매니저- 오라클, Mysql은 2계층으로 이루어져있다고 했고, cubrid는 브로커프로세스까지 3계층으로 이루어져 있다고 했는데, 왜 굳이 브로커 프로세스를 두었는지?
- 2계층구조의 DB는 브로커 프로세스가 2계층 중 하나에 포함되어있는가?
- 오라클, Mysql과 같은 DB와 달리 사용 목적이 달라 아키텍쳐 설계단부터 3단계로 설계되었는지?
- 처음 설정된 CAS가 default로 5개인 이유가 있는지?
- 여러 응용 프로그램에서 하나의 DB에 접속하는 상황을 가정하고 5개로 설정한것인지?
- CAS가 여러개 필요한 이유는 알겠지만, CAS가 여러개 필요한 상황에 대해서는 이해하지 못하겠습니다.
응용프로그램은 접속 포트로 각 브로커를 구분해 접속할 수 있으므로 사용 목적에 따라 브로커를 분리해사용할 수 있다. 예를 들어 응용프로그램 A는 일반 사용자가 사용하는 프로그램이므로 브로커 #1만 사용하고, 응용프로그램 B는 운영자만 사용하는 프로그램이므로 브로커 #2만 사용하게 할수 있다. 이렇게 구분하면 브로커 #1을 종료했을 때 브로커 #1에 접속하는 응용프로그램 A만 접속할 수 없게 할 수 있다. 또는 단순히 브로커의 설정을 조작해 브로커 #1에 접속하는 응용프로그램 X는 읽기/쓰기가 모두 가능하게하고, 브로커#2에 접속하는 응용프로그램 Y는 읽기만 가능하게 할 수 있다.
- 브로커 프로세스를 관리하면서 얻는 이점이 잘 이해가 안됩니다.
- 응용프로그램의 접근/접근해제를 독립적으로 가능케한다고 하는데 어떤 상황에서 앞의 상황이 이득이 되는지 모르겠습니다.
이 값이 클수록 캐싱되는 데이터가 많아지므로 디스크 I/O 비용을 줄일 수 있지만, 너무 크면 시스템 메모리가 과도하게 점유돼 운영체제에 의해 스와핑이 발생할 수 있다
-
캐싱되는 데이터가 많아짐 → 계속 갖고있어야 하는 데이터가 어느순간 스와핑되어 사용할 수 없게 됨
- 운영체제에서 스와핑을 한다고 하더라도 스왑스페이스에서 데이터를 가져올 수 있지 않나? 왜 사용할 수 없다고 했는지 이해가 안된다. 혹시 스왑스페이스에서 데이터를 가져오는 과정에서 자원을 많이 사용하기 때문에 스와핑되어 사용할 수 없다고 한 것인지?
-
CSQL 버그.. 오타..?
- (= 데이터가 저장될 공간)
- 저장 형태에 따라 세가지로 구분됨.
- 영구적인 볼륨: 한 번 생성되면 데이터베이스가 삭제되기 전까지 유지되는 볼륨
👉 용도에 따라 4가지로 구분됨.
- 범용 볼륨: 일반적으로 사용하는 볼륨. 스키마, 인덱스, 데이터를 저장한다. 볼륨 생성 명령(cubrid createdb)을 실행할 때 볼륨 타입을 지정하지 않으면 범용 볼륨으로 생성된다.
- 데이터 볼륨: 데이터를 저장하기 위한 공간.
- 인덱스 볼륨: 인덱스를 저장하기 위한 공간.
- 임시 볼륨: 질의 처리 및 정렬을 수행할 때 중간 결과 및 최종 결과를 임시로 저장하는 공간.
이 공간이 모두 소진되면 일시적인 볼륨을 사용한다. 일시적인 볼륨은 데이터베이스를 재시작하면 삭제되지만 임시 볼륨은 영구 볼륨 이므로 데이터베이스를 정지해도 유지된다.
- 일시적인 볼륨: 데이터베이스 운영 중 필요한 중간 결과를 일시적으로 저장하기 위해 사용되는 볼륨
- 백업 볼륨: 데이터베이스의 백업 시점의 스냅숏으로, 데이터베이스 백업 시 생성되는 볼륨이다
$ cd $CUBRID_DATABASES
$ mkdir testdb
$ cd testdb
$ cubrid createdb testdb ko_KR.utf8
Creating database with 512.0M size using locale ko_KR.utf8. The total amount of disk space
needed is 1.5G.
- 이와 같이 testdb를 생성한 상태에서 데이터베이스 볼륨 파일을 확인해보면 다음과 같다.
$ ls
디렉터리: C:\CUBRID\testdb
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2021-11-08 오전 3:17 lob
-a---- 2021-11-08 오전 3:17 536870912 testdb
-a---- 2021-11-08 오전 3:17 65 testdb_keys
-a---- 2021-11-08 오전 3:17 536870912 testdb_lgar_t
-a---- 2021-11-08 오전 3:17 536870912 testdb_lgat
-a---- 2021-11-08 오전 3:17 172 testdb_lginf
-a---- 2021-11-08 오전 3:17 173 testdb_vinf
- testdb: 데이터베이스의 데이터와 인덱스 정보를 저장하는 볼륨. 카탈로그 테이블 정보가 포함돼 있다.
- testdb_lgar_t: 보관 로그 파일을 저장하기 전에 사용되는 임시 파일. 활성 로그 파일이 가득 차면 보관 로그 파일이 생성되는데, 보관 로그 파일은 데이터베이스의 백업 또는 복구 시 사용된다. HA 구성 시 데이터 복제에도 보관 로그 파일이 사용된다. 이 예에서는 보관 로그 파일이 아직 생성되지 않은 상태다.
- testdb_lgat: 활성 로그 파일. 진행 중인 트랜잭션 정보를 저장한다.
- testdb_lginf: 로그 파일의 정보를 저장하는 파일.
- testdb_vinf: 볼륨 파일의 정보를 저장하는 파일.
$ cubrid addvoldb -S -p data -n testdb_DATA01 --db-volume-size=512M testdb
$ cubrid addvoldb -S -p data -n testdb_DATA02 --db-volume-size=512M testdb
$ cubrid addvoldb -S -p index -n testdb_INDEX01 --db-volume-size=512M testdb
$ cubrid addvoldb -S -p temp -n testdb_TEMP01 --db-volume-size=512M testdb
PS C:\CUBRID\testdb> ls
디렉터리: C:\CUBRID\testdb
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2021-11-08 오전 3:17 lob
-a---- 2021-11-08 오전 3:25 536870912 testdb
-a---- 2021-11-08 오전 3:24 536870912 testdb_DATA01
-a---- 2021-11-08 오전 3:25 536870912 testdb_DATA02
-a---- 2021-11-08 오전 3:25 536870912 testdb_INDEX01
-a---- 2021-11-08 오전 3:17 65 testdb_keys
-a---- 2021-11-08 오전 3:25 536870912 testdb_lgar_t
-a---- 2021-11-08 오전 3:25 536870912 testdb_lgat
-a---- 2021-11-08 오전 3:17 172 testdb_lginf
-a---- 2021-11-08 오전 3:25 536870912 testdb_TEMP01
-a---- 2021-11-08 오전 3:25 322 testdb_vinf
볼륨 사용량 확인
- 해당 서버 프로세스를 켜고
PS C:\CUBRID\testdb> cubrid server start testdb
++ cubrid server start: success
- 볼륨 사용량을 확인한다.
cubrid spacedb -p testdb
-
큐브리드 서비스 시작
※ 주의사항 : 윈도우에서는 관리자 권한으로 터미널을 실행해야 한다.
cubrid service start
큐브리드 관련 프로세스를 한 번에 시작하고 종료한다.
cubrid service stop
시작한 프로세스를 종료한다. 큐브리드의 모든 프로세스가 종료된다.
-
큐브리드 프로세스 생성 순서
마스터 프로세스→서버 프로세스→브로커 프로세스→매니저 프로세스 -
큐브리드 프로세스 종료 순서
시작한 순서의 역순은 아니지만, 의존성을 고려하여 단계별로 모든 프로세스 종료
-
-
시작할 프로세스 지정
cubrid service start / stop명령을 이용하면 한번에 시작하고 종료한다.원하는 프로세스만 시작하려면
cubrid.conf파일에서 설정 할 수 있다. -
서버 프로세스 시작
서버프로세스는 데이터베이스별로 시작하거나 종료 가능
서버프로세스는 항상 데이터베이스와 1 : 1로 대응된다.
-
demodb 시작
cubrid server start demodb -
demodb 종료
cubrid server stop demodb
cubrid 서비스 시작 시 기본으로 시작할 데이터베이스를 지정하려면
cubrid.conf파일에서 설정 가능하다. -
-
브로커 프로세스 시작
-
큐브리드 설치시 기본으로 생성되는 브로커
- query_editor
- BROKER1
위 브로커들은 cubrid_broker.conf 파일에 기본으로 설정된 브로커다.
응용프로그램은 접속 포트로 각 브로커를 구분해서 접속할 수 있다. 즉, 사용목적에 따라 브로커를 분리하여 사용할 수 있다. 브로커의 설정을 통해, 브로커에 접속하는 응용프로그램의 권한을 설정할 수 있다.
-
브로커 시작
cubrid broker start -
브로커 종료
cubrid broker stop -
브로커 프로세스를 시작한 후 특정 브로커의 사용여부를 변경할때
cubrid broker on 브로커이름cubrid broker off 브로커이름
-
-
매니저 프로세스 시작
매니저 프로세스란?
큐브리드 GUI 도구에서 큐브리드를 원격 관리하기 위해 필요한 서비스
-
매니저 프로세스 시작
cubrid manager start -
매니저 프로세스 종료
cubrid manager stop
-
-
서비스 상태 확인
cubrid service status
-
서버 연결 테스트
- 큐브리드는 GUI 도구 없이 데이터베이스에 CSQL 질의 도구를 통해 질의가 가능하다.
$ csql -u dba demodb CUBRID SQL Interperter Type `;help` for help messages. csql>
CSQL 이란, 콘솔에서 질의를 실행하는 도구입니다. 사용할 수 있는 옵션은 아래와 같습니다.
-S, --SA-mode
독립 모드로 CSQL에서 내부적으로 서버의 기능을 포함하여 명령을 실행합니다.
때문에 해당 데이터베이스 서버가 실행 중이지 않아도 데이터베이스에 직접 접근할 수 있습니다.
-C, --CS-mode
CSQL을 응용 프로그램 클라이언트로 취급하여 서버에 접근합니다. 이 경우 브로커를 통해 명령
이 실행되어, 로그가 남습니다.
-u, --user=ARG
유저 이름을 지정합니다
-p, --password=ARG
비밀번호를 지정합니다. 주어지지 않으면 ""로 인식합니다.
-e, --error-continue
커맨드 실행 도중 에러가 발생할 경우, 다음 명령을 계속해서 수행합니다.
해당 옵션을 사용하지 않으면 에러 발생 시 모든 명령을 멈추게 됩니다.
-i, --input-file=ARG
커맨드 대신 파일 입력을 받아 커맨드로 사용합니다.
-o, --output-file=ARG
결과를 해당 파일로 출력합니다.
-s, --single-line
single line oriented execution
-c, --command=ARG
-c 혹은 --command로 CSQL 명령어를 지정해 실행할 수 있습니다. 공백이 들어가는 경우 ""로
묶어주어야 합니다.
-l, --line-output
결과를 테이블(표) 형식이 아닌 인덱스-값들 형태로 출력합니다.
<00001> s_name: 'X'
f_name: 'Mixed'
-r, --read-only
쓰기 작업을 할 수 없습니다
--string-width
각 값들에 대해 출력할 최대 글자수를 정합니다. 2일 경우 2글자 까지면 출력됩니다.
▼ --string-width 2
s_name f_name
============================================
'X' 'Mi'
--no-auto-commit
실행한 트랜잭션에 대해 자동으로 커밋하지 않습니다
--no-pager
pager를 사용하지 않고 모두 출력합니다
--no-single-line
turn off single line oriented execution
--no-trigger-action
트리거 사용을 비활성화합니다