✔개요
큐브리드 설치 후, 큐브리드를 내 프로젝트와 연동하기 위해
netstat -nlp|grep cub를 통해 포트를 확인하였고
tcp 0 0 0.0.0.0:33000 LISTEN 16581/cub_broker
tcp 0 0 0.0.0.0:1523 LISTEN 16567/cub_master
tcp 0 0 0.0.0.0:30000 LISTEN 16570/cub_broker
tcp 0 0 0.0.0.0:8001 LISTEN 16597/cub_manager위처럼 4개의 포트가 나타났다.
도대체 브로커, 마스터, 매니져는 무엇이고, 무얼 통해 내 프로젝트의 DB 포트를 결정해야할까?
✔내용
Naver D2 CUBRID, 브로커 이야기 참고
해당 그림을 참고함을 추천한다.
cub_server
실제 DB 역할을 진행중인 서버이다.
libcubridcs.so
cub_server로 실제 명령을 보내는 c언어 라이브러리이다.
cub_broker
cub_cas의 ps를 관리한다. 1개의 cub_broker는 n개의 cub_cas를 관리 할 수 있다.
cub_cas
cub_master에 연결을 요청, cub_server와 연결된다.
cub_master
cub_cas의 요청을 받아, cub_cas와 cub_server를 연결시켜준다.
✔결과
위 개념을 확인 후
$CUBRID/conf/cubrid_broker.conf 파일을 수정하여 포트를 수정 및 접근할 수 있엇다.
broker 기능을 사용하므로 첫인상은 상당히 복잡하다는 느낌을 받았다.
실제 동작원리를 이해 후, 대규모 Enterprise 환경에서는 Connection 관리에 상당히 용이하다는 생각이 들었다.
추가적으로 cub_cas 및 cub_server는 클라이언트의 연결이 끊겨도 유지된다는 점,
mysql 및 oracle 등 타 RDBMS에도 broker 기능을 사용 가능하다는 점을 알아두면 좋을것이다.
