Background Image
조회 수 51502 추천 수 0 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

무중단 서비스를 위한 DB 서버 이중화 구축
죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다.

 

* 본 게시글은 월간 마이크로소프트웨어 7월호에 게재된 내용입니다.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
오보명 obm@nhn.com | NHN Business Platform 서비스 플랫폼 개발 센터에서 플랫폼 확산 업무 및 오픈소스 라이선스 컨설팅 업무를 담당하고 있다. 4년 전 CUBRID라는 국산 DBMS와 인연을 맺은 이후, CUBRID 의 국내/해외 확산 업무를 담당하고 있으며 CUBRID 글로벌 커뮤니티 사이트(http://cubrid.org)를 운영하면서 전세계 개발자들과 소통하고 있다.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 


2011년 6월 17일(금) 자정 00:00부터 오전 09:30분까지 국내 홈쇼핑 선두 업체의 쇼핑 사이트가 시스템 점검을 이유로 서비스 운영을 일시 중단했다. 해당 업체의 2010년 매출액과 온라인 쇼핑 매출 비율(30%)을 고려할 때, 1시간 당 매출액은 약 2,700만원이고, 9.5시간 동안 올릴 수 있는 매출액은 약 2억 5천만 원에 이른다. 물론, 대부분 고객들이 잠을 자는 시간이어서 실제 손실액은 훨씬 적었을 것이다. 당일 필자는 에어컨 가격을 알아보고 있었는데, 결국 다른 쇼핑 사이트에서 이를 구매했다. 서비스가 죽지 않아야 하는 이유? 바로 매출과 직결되기 때문이다.

 

왜 서비스는 중단되는가?
서비스 중단의 유형은 원인에 따라 크게 두 가지로 구분할 수 있다. 운영자가 예측하지 못한 장애 상황이 발생한 경우, 그리고 운영자가 의도적으로 서비스를 중단하고 시스템 점검과 같은 상시 운영 업무를 처리하는 경우이다. 이때 문제가 되는 것은 전자의 경우이다. 천재지변, 네트워크 단절, 운영 서버 리소스의 과다 사용, 하드웨어 고장 등의 이유로 장애가 발생하는 경우, 운영자가 원인을 판단하고 서비스를 정상 복구하기까지 상당한 시간이 소요되기 마련이다. 후자의 경우는 다행히 작업 시간을 미리 예측할 수 있지만, 사용자 방문이 가장 적은 새벽에 점검 작업을 수행하여야 하므로 운영자는 늘 피곤할 수 밖에 없다. 근본적으로 피곤은 “간” 때문이기는 하지만, 운영자의 피곤을 줄일 수 있는 확실한 방법은 바로 HA(High Availability) 시스템 구축이다.

 

서비스에 적합한 HA 솔루션 선택
서비스 가용성을 높이기 위한 방안으로 DBMS벤더들은 각각 다양한 방식으로 HA 솔루션을 지원한다. 아래 표는 각 제품 별 특징을 요약한 것이다.

table 1.jpg

 

표 1. 제품별 HA 솔루션의 특징 요약

 

Oracle RAC 및 MS-SQL Cluster는 공유 스토리지 기반의 구조를 따르고 있으며, MySQL과 CUBRID는 복제(Replication)을 사용하여 데이터베이스를 여러 대의 서버에 분산하는 구조를 채택하고 있다. 그 외에도 마스터/슬레이브 데이터베이스 간 동기화 방식과 복제 방식, 자동 절체(Auto-Failover) 기능의 유무, Failover 이후 어플리케이션의 자동 연결 여부 등 제품마다 동작 방식, 지원 기능 및 구축 비용이 매우 상이하다. 운영자는 예산, 서비스 규모 및 부하 패턴을 고려하여 적합한 솔루션을 채택할 수 있다.
지금부터는 비용 부담 없이 공개된 매뉴얼만으로 쉽게 고가용성 시스템을 구축할 수 있는 MySQL과 CUBRID에 대해 더욱 상세히 살펴보고자 한다.

 

목표 1. 죽지 말아야 한다.

 

웹 서비스 제공자는 누구나 서비스 가용성이 100%이기를 바랄 것이다. “서비스는 죽지 말아야 한다”는 목표를 달성하기 위해서는 데이터베이스 서버의 죽음을 미리 대비하고, 죽음을 반드시 알려야 한다. 이를 위해 CUBRID HA는 아래와 같은 기능을 제공한다.

• DB 서버 다중화 구성
• 복제 기반의 데이터베이스 동기화
• 장애 감지 및 Failover

 

1) DB 다중화 구성
CUBRID HA는 읽기/쓰기 부하를 담당하는 마스터 노드, 장애 시 마스터 기능을 대체하는 슬레이브 노드, 읽기 부하 분산을 담당할 수 있는 복제 노드를 조합하여 다양하게 구성할 수 있다. 아래는 CUBRID HA 구성의 예이다.

 

table 2.jpg

 표 2. CUBRID HA 구성의 예시

 

아래 그림처럼 CUBRID HA 기본 구성을 한 후, 마스터 서버에 장애가 감지되면, 브로커 미들웨어가 등록된 슬레이브 DB 서버의 상태를 확인하여 연결을 수립한 후, 사용자 요청(읽기/쓰기)을 처리한다. 만약, 브로커 서버와 DB 서버를 각각 분리한 구성에서 브로커 서버에 장애가 감지되면, 마찬가지로 인터페이스(JDBC, PHP, CCI 등)에 등록된 2차 브로커 서버의 상태를 확인하고 연결을 수립한다.

  

pic 1.jpg


그림 1. CUBRID HA 구성에서 마스터 장애 시 Failover

 

MySQL 기반의 HA 환경을 무료로 구성하는 대표적인 방법으로는 1) MySQL 복제와 Linux Heartbeat 패키지를 사용, 2) MySQL 복제와 MMM(Master-Master Replication Manager) 솔루션을 사용하는 것이다. 1)은 운영 편의성 측면에서 매우 취약한 구성인데 이유는 마스터 DB 서버에서 장애가 감지되더라도 운영자가 수동으로 Failover를 하고, 슬레이브 DB 서버와 연결되도록 어플리케이션의 연결 정보를 수동으로 갱신하여야 하기 때문이다. 한편, 2)의 경우는 CUBRID와 마찬가지로 자동 Failover 및 어플리케이션 자동 연결 기능이 지원된다.
 

pic 2.jpg


  

그림 2. MySQL 복제+ Linux HB 구성에서 마스터 장애 시 Failover

 

2) 복제 기반의 데이터베이스 동기화
CUBRID와 MySQL는 데이터베이스 동기화를 위해 복제 기법을 사용하지만, 복제의 동작 방식이 서로 다르다. CUBRID는 마스터 노드에서 데이터(row)의 변경 사항을 로깅하여 이를 복제하는 row-based 복제 기법을 사용하고, MySQL은 마스터에서 수행된 SQL 문을 그대로 로깅하여 복제하는 statement-based 복제 기법을 사용한다. Row-based 복제는 마스터의 모든 변경 사항에 대해 복제할 수 있고 보다 적은 LOCK을 사용하게 되어 동시성이 높다는 장점이 있다. 한편, statement-based 복제는 슬레이브로 SQL문만 복제하므로 마스터 서버에 부하를 덜 주지만 마스터와 슬레이브 사이에 데이터베이스 불일치가 발생할 수 있다.
그림 3은 CUBRID HA 구성에서 복제 방식을 나타낸 것이다. 마스터 노드에서 데이터가 변경되면 트랜잭션 로그와 복제 로그가 슬레이브 노드로 복사 및 반영되면서 마스터 및 슬레이브 데이터베이스가 동기화된다.
 

pic 3.jpg


 그림 3. CUBRID Row-based 복제 방식

 

3) 장애 감지 및 Failover
CUBRID는 HA 기능이 구현되었던 초기 버전(2008 R2.1이하 버전)에서는 MySQL HA와 마찬가지로 Linux Heartbeat 패키지를 사용하여 노드 상태를 감지하였으나, NHN 내/외부 서비스에 CUBRID HA 적용 후 Linux Heartbeat 패키지의 불안정한 문제들(예: 부정확한 장애 감지로 인해 원치 않는 failover 발생)과 설정의 어려움이 있어, 이후 버전부터는 자체 구현한 CUBRID Heartbeat을 내장하고 있다.
CUBRID HA로 구성된 모든 노드들은 네트워크를 통해 heartbeat 메시지를 주고 받으며 자신을 제외한 노드의 상태를 감시한다. 만일, 일정 시간 동안 특정 노드로부터 heartbeat 메시지를 수신하지 못하게 되면, 해당 노드에 장애가 발생한 것으로 판단한다.
만약, 마스터 노드에서 장애가 발생하면 즉시 구성 정보와 다른 노드들의 상태 정보를 조합하여 슬레이브 노드 중 마스터가 될 수 있는 후보 노드를 선택하고 이 노드에서 쓰기 연산이 가능하도록 해당 노드의 역할을 변경하기 위한 Failover를 수행한다.

  

pic 4.jpg


그림 4. CUBRID Heartbeat에 의한 장애 감지와 Auto-Failover

 

목표 2. 날리지 말아야 한다.

 

목표 1을 달성했다고 하여 모든 문제가 해결된 것은 아니다. 만약, 장애가 발생한 순간의 트랜잭션이 정상적으로 반영되지 않거나, 마스터 노드와 슬레이브 노드 간 데이터베이스 불일치가 발생한다면 어떻게 될까? 쓰기 연산이 비교적 많은 SNS또는 메신저 사용자라면 누구나 겪었을 경험, 열심히 글을 입력했는데 그 글이 보이지 않는 황당함을 서비스 고객이 겪을 수도 있다.
“날리지 말아야 한다”는 목표를 달성하기 위해 CUBRID HA는 세가지 동기화 모드를 지원하며, 운영자는 서비스 유형에 따라 적절한 모드를 설정할 수 있다.

 

table 3.jpg

 표 3. CUBRID HA의 동기화 모드 비교

 

목표 3. 빨라야 한다.

 

목표 1, 목표 2를 달성했다고 해도 여전히 남은 문제, 바로 HA 성능이다. 장애 발생 시점부터 서비스가 정상화될 때까지의 소요 시간을 최소화하기 위해서는, 1) 복제 지연 최소화, 2) 신속한 장애 감지, 3) 가용한 슬레이브 노드로 Failover 수행, 4) 어플리케이션이 슬레이브 노드로 즉시 연결 등 일련의 과정들이 신속 정확하게 수행되어야 한다. 그래야만 서비스 고객들이 순간의 서비스 중단을 눈치채지 못할 것이다.

 

1) HA 환경에서의 복제 지연 테스트
서비스 가용성과 안정성을 향상시키기 위하여 HA 솔루션을 도입할 때 반드시 고려해야 할 반대 급부가 바로 성능이다. HA 환경에서는 슬레이브 노드로 복제를 수행하므로 마스터 노드에 부하가 증가한다. 또한, 데이터 무결성을 보장하기 위하여 HA 동작 모드를 동기 모드(sync mode)로 설정한 경우, 비동기 모드(async mode)에 비해 마스터 노드에 부하가 증가한다. 문제는 이러한 복제 지연이 “얼마나” 실제 서비스에 영향을 주느냐인데, 이를 검증하기 위하여 간단한 테스트를 수행하였다.
마스터 노드 1개와 슬레이브 노드 1개로 구성된 HA 환경을 구축하고, 테이블 1개에 일정 개수의 레코드가 축적될 때까지 100% INSERT 연산을 수행하는 테스트이다. 일반 환경, HA환경(Async모드), HA 환경(Sync 모드)에서 각각 테스트를 수행하였다.
(CPU: Xeon(R) CPU 3065 @ 2.33GHz, Memory: 4G, OS: Linux CentOS 2.6.18, CUBRID 2008 4.0.0233, MySQL 5.5.11)

 

table.jpg

 

최신 버전의 CUBRID과, MySQL을 적용하여 테스트한 결과, 일반 환경에서는 MySQL의 입력 성능이 평균 20% 더 높지만, HA 환경(Async모드)을 구성했을 때는 CUBRID의 입력 성능이 평균 9% 더 높았다. 또한, HA 환경(Sync모드)을 구성했을 때는 슬레이브 노드에서 트랜잭션이 커밋된 이후에 마스터 노드에서 트랜잭션을 완료 처리하므로 Async일 때보다 약 2배의 시간이 소요되나, 복제 지연은 거의 없는 것으로 확인되었다. 단, 서비스 부하 패턴 및 장애 발생 시점의 복제 데이터 양에 따라 테스트 결과는 상이할 수 있음을 고려하여야 한다.

 

2) Failover 테스트
서비스 운영 중에 자주 발생되는 장애 유형을 6가지로 분류하고, 각 장애 상황에서 CUBRID HA가 성공적으로 Failover를 수행하는지에 관한 테스트이다. 덧글을 입력할 수 있는 게시판 어플리케이션에서 30개의 동시 쓰레드가 QPS 700 수준의 쓰기 및 읽기 연산을 수행하는 도중 장애가 발생하는 시나리오이다. 단, Failover 시간 및 TPS가 정상화되는데 소요되는 총 시간은 서비스 부하 패턴 및 장애 발생 시점의 복제 데이터 양에 따라 상이할 수 있음을 고려하여야 한다.
(CPU: 4 core * Xeon(R) CPU X3350 @ 2.66GHz, Memory: 4G, OS: Linux CentOS 2.6.18, CUBRID R2.2 Patch 9)

 

table 4.jpg

 표 4. CUBRID HA의 Failover 성능 테스트 결과

 

결론. 궂은 날 빛나리라.


지금까지 DB 서버 이중화 구축을 위한 각 제품별 HA 솔루션의 특징을 살펴보고, 비용 고민 없이 도입할 수 있는 오픈소스 제품인 MySQL과 CUBRID의 HA 의 동작 방식과 특징, 그리고 성능을 세가지 목표 관점에서 검토해 보았다.
만약, HA 시스템을 구축할 계획이 있다면 이것만은 명심하자. 걱정 없이 슬레이브 데이터베이스에 실시간 백업(hot backup)을 걸 수 있는 날, 서버 장비가 갑자기 고장 나도 서비스가 중단 없이 운영되는 날, 근무 시간 동안 DB 엔진 버전 업그레이드 작업을 완료하고 퇴근하는 날, 그 날은 온다는 것을.

 

 

참고문헌

[1] High Availability, http://en.wikipedia.org/wiki/High_availability, Wikipedia
[2] Failover, http://en.wikipedia.org/wiki/Failover, Wikipedia
[3] Shared Nothing Architecture, http://en.wikipedia.org/wiki/Shared_nothing_architecture, Wikipedia
[4] Oracle Database High Availability, http://www.oracle.com/technetwork/database/features/availability/index.html
[5] Database Mirroring in SQL Server 2005, http://technet.microsoft.com/en-us/library/cc917680.aspx
[6] MySQL HA/Scalability, http://dev.mysql.com/doc/mysql-ha-scalability/en/index.html
[7] CUBRID 4.0 매뉴얼, http://www.cubrid.com/manual/840/index.htm


 


  1. CUBRID-HA 제약사항을 극복해보자

     Charpter0. 들어가며.. 주요한 시스템인 경우, 장애가 발생하더라도 실시간으로 서비스를 제공해야 함으로 CUBRID이중화 방식은 필히 적용해야 할 구성방식입니다. 그러나 LOB 를 사용하지 못하는 제약사항이 있어 이를 극복할 수 있는 방법이 있지 않을까해서 테스트한 내용입니다. 본 장에서는 Linux에서, fail-over, fail-back상황에서 테스트했지만, 더 많은 OS, 더 많은 상황에서도 동기화가 되는지 종합적인 테스트가 이루어져야 할 것입니다. Chapter1. HA란 무엇인가 CUBRID에서는 HA기능을 기본적으로 제공하고 있다. HA란 무엇인가??  High Availability(HA)란, 하드웨어, 소프트웨어, 네트워크 등에 장애가 발생해도 지속적인 서비스를 제공하는 기능이다. 이 기능은 하루 24시간 1년 내내 서비스를 제공해야 하는 네트워킹 컴퓨팅 부분에서 필수적인 요소이다. HA 시스템은 두 대 이상의 서버 시스템으로 구성하여 시스템 구성 요소 중의 한 요소에 장애가 발생해 서비스를 중단 없이 제공할 수 있다.  운영중인 하나의 서버(master-node)에 이상이 발생하여도 대기중 이였던 서버(slave-node)를 활용하여 중단없는 서비스를 제공한다는 것이다.  어떠한 방식으...
    Date2018.11.07 Category제품 여행 By큐브리드_김주현 Views2136 Votes0
    Read More
  2. CUBRID contribute의 두번째 걸음, CUBRID 디버깅 하기

    디버깅은 실행중인 프로세스를 컨트롤할 수 있어 문제점을 찾거나 현재 로직을 확인 할 때 유용한 방법입니다. 이번에는 GDB를 활용하여 CUBRID server 프로세스를 디버깅해보도록 하겠습니다. GDB 사용에 앞서 CUBRID 빌드가 되어 있어야 합니다. CUBRID  빌드 관련 내용은 아래 링크를 확인하세요. http://www.cubrid.com/blog/3814572   디버깅을 위해서는 'debug' 모드로 빌드해주세요.  1 2 [root]vi build.sh build_mode="debug" cs   빌드시 에러가 발생한다면 표준에러만 파일로 리다이렉션하여 확인하는 것이 좋습니다.  1 2 [root]vi build.sh 2> error.out vi error.out cs 빌드가 완료가 되었다면 bash_profile 파일에 PATH 관련 정보를 추가 저장합니다. CUBRID 위치는 build시 저장한 위치로 변경하세요.  1 2 3 4 5 6 7 8 9 10 cd ~ [root]vi .bash_profile export CUBRID=/cubrid10.1/CUBRID   export CUBRID_DATABASES=$CUBRID/databases export PATH=$PATH:$CUBRID/bin export LD_LIBRARY_PATH=$CUBRID/lib:$LD_LIBRARAY_PATH CLASSPATH=$CUBRID/jdbc/cubrid_jdbc.jar export CLASSPATH [root]source .bash_profile cs demo DB를 생성합니다.​ 1 2 3 4 5 6 c...
    Date2018.08.09 Category제품 여행 By박세훈 Views1083 Votes0
    Read More
  3. No Image

    CUBRID 사용 포트와 OS명령어로 포트 오픈 상태 점검하기

    CUBRID를 설치 후 사용자들이 응용 프로그램과 CUBRID Manager 또는 CUBRID Migration Toolkit(CMT)를 연결 할 때 어떤 포트를 사용해야 하는지 "방화벽 문제로 CUBRID DB서버와 접속이 안되는 현상" 때문에 Q&A 문의가 생각보다 많이 있어 이번 블로그 내용에서는 접속대상 서버(PC)와 CUBRID DB서버간 포트개방 생태를 OS명령어로 확인하는 방법을 소개하고자 합니다.  우선, CUBRID 포트관련 내용을 간단하게 정리하면 설정 파일들은 $CUBRID/conf 디렉토리에 위치해 있고 cubrid.conf에 cubrid_port_id=1523, cubrid_broker.conf에 BROKER_PORT=30000,33000, cubrid_ha.conf에 ha_port_id=59901, cm.conf에 cm_port=8001 포트로 기본설정되어 있습니다, 아래 표는 CUBRID가 사용하는 포트를 정리한 것입니다.   1, CUBRID 포트 정리표 구분 대상 장비 Linux 포트 Windows 포트 방화벽 Single DB WEB/WAS Server 33000(TCP) 33000~33040(TCP) 개방 CUBRID Manager 30000(TCP) 8001(TCP) 30000~30040(TCP) 8001(TCP) 개방 CUBRID CMT 30000(TCP) 30000~30040(TCP) 개방 CUBRID HA WEB/WAS Server 33000(TCP) 33000~33040(TCP) 개방 CUBRID Manager 30000(TCP) 8001(TCP) ...
    Date2018.07.03 Category제품 여행 By정만영 Views7538 Votes0
    Read More
  4. Windows 10에서 CUBRID linux 버전 사용하기

    MS에서 2016.08.02 기준으로 Windows 1주년 업데이트 버전을 배포했다. 해당 업데이트의 믄 변화에는 bash(Linux 용 Windows 하위시스템 beta)를 사용할 수 있다는 것이다. 해당 버전에서 정상 동작 하는지 테스트를 해 보았으나, 초기 버전에는 linux의 shared memory 관리 부분이 구현이 덜 되어 데이터베이스 서버 엔진은 구동이 가능하지만  쉐어드 메모리를 사용하는 브로커는 정상 작동하지 않았다. 해당 버그는 MS의 GitHUB https://github.com/Microsoft/WSL/issues/92 에 보고 되어 수정이 되었다. Windows 16215 버전 이후 버전 및 작년 가을에 레드스톤3 업데이트 Fall Creators Update 에 와서는 CUBRID가 정상 구동 할 수 있는 shared memory 환경이 되었다. Windows 10 버전를 꾸준히 업데이트만 받았다면, 이제 CUBRID를 bash 환경에서 구동이 가능하다. 일단 기본적으로 활성화되는 기능은 아니기 때문에 제어판 > 프로그램 > 프로그램 및 기능 > Windows 기능 켜기/끄기에서 해당 기능을 활성화 해야한다. 활성화 이후에는 재부팅이 필요 할 수 있다. 또는 MS의 Install the Windows Subsystem for Linux 가이드 (https://docs.microsoft.com/ko-kr/windows/w...
    Date2018.06.27 Category제품 여행 By성진 Views1448 Votes0
    Read More
  5. 큐브리드의 유용한 명령어 살펴보기

    데이터베이스 시스템을 운영하면서 성능 개선은 매우 중요한 일입니다. CUBRID는 다른 DBMS와 다르게 JDBC 드라이버-브로커-데이터베이스 서버의 3계층(3-tier) 구조로 구성되어 있습니다. 3계층 중 브로커는 서버와 외부 응용 프로그램 간의 통신을 중계하는 CUBRID 전용 미들웨어로서, 커넥션 풀링, 모니터링, 로그 추적 및 분석 기능을 제공합니다. CUBRID는 CUBRID BROKER프로세스가 생성한 SQL LOG파일을 통해 SQL 성능 분석을 할 수 있습니다. (다른 DBMS 성능 모니터링은 시스템 DMV를 조회하여 확인합니다.)  이번 블러그에서는 CUBRID BROKER가 생성한 SQL LOG 파일을 이용하여 성능 문제를 분석하고 개선하는데 유용한 유틸리티에 대해 3회에 걸쳐 소개할 예정이며, 첫번째로 소개할 유틸리티는 broker_log_top 입니다. ▣ broker_log_top broker_log_top 유틸리티는 수행 시 특정 기간 동안 생성된 SQL LOG 파일를 분석하여 실행 시간이 긴 순서대로 나열합니다. 이 유틸리티는 수행시 log_top.res와 log_top.q와 같이 2개의 결과 파일을 남깁니다. log_top.res 파일에는 특정기간 동안 수행된 SQL들에 대한 최대 수행 시간, 최소 수행 시간, 평균 수행 시간 및 수...
    Date2018.01.04 Category제품 여행 By성진 Views3686 Votes0
    Read More
  6. 젊은 열정 대학생들과 함께한 컨트리뷰톤(contributon) 2017

    프롤로그 컨트리뷰톤 2017(https://www.kosshackathon.kr). 약 2달간의 일정으로 진행되는 오픈소스 멘토링 행사에 멘토 자격으로 참여하였습니다. 총 10개의 프로젝트에 각각 12~15명 내외의 멘티들이 선발되어 git 사용법부터 오픈소스에 컨트리뷰션(contribution)까지 진행해보는 과정으로 대학생들이 주를 이루었지만 간혹 경력이 상당한 개발자 분들도 멘티로써 참석하셨습니다. 뜨거운 열정이 느껴집니다. 저희는 CUBRID Manager(GUI 도구)를 진행 프로젝트로 선정하였는데, 오픈소스를 거의 처음 접해보는 멘티들에게 적절한 선택이지 않았나 생각합니다. 아래 사진 속에 저와 멘티들이 보이네요. 아마 진행할 프로젝트와 멘토 소개를 했던 것으로 기억하는데, 오랜만에 100명이 넘는 사람들 앞에서 잡은 마이크라 그런지 긴장한 모습이 역력합니다. 오픈소스 참여하고 싶어요 멘티들과의 첫만남. 저는 “컨트리뷰톤에 등록된 프로젝트 중 왜 CUBRID Manager에 지원하셨어요”란 질문을 던졌습니다. 아마 “CUBRID에 관심이 많아요.”, “DBMS 개발을 해보고 싶어요.”란 답변을 기대했던거 같은데, 의외로 “쉬워보여서요.”, “오픈소스가 처음인데, 멘토님이 친절하실 것 같아...
    Date2017.12.28 Category오픈소스 이야기 By민준 Views1992 Votes0
    Read More
  7. CUBRID 전환 시에 어떤 고민을 해야 할까요?

    최근 공개소프트웨어에 대한 관심이 높아지면서 국내 유일의 오픈소스 DBMS인 CUBRID도 많은 주목을 받고 있습니다.  전환을 생각하는 사용자로부터 많이 받는 질문 중 하나는 “우리가 운영하고 있는 시스템의 DBMS가 오라클/MySQL/MS-SQL 인데 CUBRID로 전환이 가능한가요?” 입니다. 그래서, 오라클 기반의 서비스를 CUBRID로 전환할때 전환에 절차 및 고려 사항들에 대한 대략적인 내용을 정리해보았습니다. 우선, CUBRID로 전환하기 위한 절차는 1)전환 가능성 분석  2) 기존 환경분석  3) 개발환경 구성 4) SQL 전환 순으로 진행됩니다. 이후의 절차인 운영환경 전환, 성능테스트, 운영 유지보수 등의 내용은 생략하도록 하겠습니다. 그럼, 각 절차에 대해서 상세히 알아보도록 하겠습니다 1) 전환 가능성 분석 아래 표와 같이 각 항목별로 배점을 부여하여 DBMS 전환이 가능한지를 확인합니다.  각 항목별배점 예시는 50:30:20, 60:20:20 등과 같이 배점기준을 정하여 가능성을 분석하며, 배점결과가 약 70~80 이상일 경우에는 전환이 가능하다고 판단하면 됩니다. 2) 기존 환경 분석 전환이 가능하다고 판단되면, 전환범위와 DBMS 스키마, DB크기 등에 대한 시스템 전반...
    Date2017.12.26 Category제품 여행 By권호일 Views4730 Votes0
    Read More
  8. CUBRID의 오류 종류와 생성되는 로그 종류는 ?

    CUBRID상에서 서비스 개발 및 운영 시 마주치게 되는 여러가지 문제를 해결하기 위해서는 오류코드(메세지)에 대한 해석과 서버에서 생성하는 다양한 로그에 대한 해석이 중요합니다. 이번 글에서는 해석에 치중하기 보다는 CUBRID 9.3 기준으로 어떤 종류의 오류코드(메세지)가 있는지 어떤 종류의 로그들이 생성되는지를 우선으로 살펴보겠습니다. 향후 시간이 되면 해석에 대해서도 글을 올리도록 하겠습니다. C 또는 JAVA언어를 이용하여 서비스 개발시 참고할 수 있는 오류 코드 종류는 아래 표와 같으며, 이를 활용하여 Source Debugging과 다양한 조건 및 상태에 따른 분기가 가능한 프로그램을 개발할 수 있습니다. 응용관련 CCI 오류코드 (오류 메시지) JDBC 오류코드 (오류 메시지) CAS 오류코드 (오류 메시지) DB관련 데이터베이스 서버 오류코드 (오류 메시지)   먼저 발생하는 오류 코드 종류에 대해서 알아 보도록 하겠습니다. 1. 응용관련 메시지 1.1 CCI에서 발생한 오류 코드 구분       CUBRID에서는 C기반 응용프로그램 개발을 위해 CCI(C Client Interface)제공하며, 오류 발생 시 음수 값을 반환합니다.       발생하는 오류 코드 구분 규칙은 다음과 같...
    Date2017.12.26 Category제품 여행 By김창휘 Views3878 Votes0
    Read More
  9. CUBRID의 접속 제어 관리 (ACL : Access_control) 기능 살펴보기

      접근 권한(Access Control)이란, 허용한 IP 목록과 허용된 DB 사용자 외 다른 IP 및 DB사용자가 해당 브로커나 데이터베이스 서버로 접속하는 것을 제한하기 위해 사용됩니다. 이 기능을 사용하시면, 외부의 잘못된 접근으로 인하여 발생하는 문제로부터 데이터베이스를 보호할 수 있습니다.   CUBRID는 데이터베이스에 접속하는 브로커 및 CSQL 인터프린터를 제한하기 위한 데이터베이스 접속 제어 관리, 브로커에 접속하는 응용 클라이언트를 제한하기 위한 브로커 접속 제어 관리를 제공하고 있습니다.   이번 글에서는 데이터베이스 및 브로커 접속 제어 관리의 설정 방법과 모니터링 방법을 살펴보겠습니다. 작성된 예시는 CUBRID 9.3.6.0002 버전 기준입니다.   1.     데이터베이스 서버 접속 제어 관리 1)     데이터베이스 서버 접속 제어 관리 설정 ①    cubrid.conf 파일 설정($CUBRID/conf/cubrid.conf) -      데이터베이스 서버의 접속 제어 관리 기능을 사용하기 위해서는 access_ip_control 파라미터를 yes로 설정해야 하며(기본 값은 no), access_ip_control_file(접속을 허용하는 IP 목록이 작성된 파일) 경로를 입력해야 합니다. -      해당 설정 값은 ...
    Date2017.12.21 Category제품 여행 By허서진 Views5114 Votes0
    Read More
  10. No Image

    손쉬운 PHP 확장 기능 개발

    PHP 확장 기능 Web 개발 인터페이스로 널리 사용되는 PHP에는 PHP고유의 기능 외에도 사용자가 기능을 추가할 수 있는 확장(Extension) 기능이 있습니다. 확장 기능을 사용하기 위해서는 리눅스 상에서는 PHP와 인터페이스되는 확장 라이브러리를 만들어야 합니다. PHP는 C 프로그래밍 초보자라도 확장 기능을 쉽게 만들 수 있도록 Zend Platform이라는 인터페이스를 제공하고 있습니다. 그럼 간단한 'Hello World' 확장 기능을 작성해 보겠습니다. 작성된 확장 기능은 CentOS 6.x 기준입니다. 설정하기 첫 번째 단계는 소스에서 PHP를 컴파일하는 데 필요한 필수 개발 도구 (automake, autoconf 등)를 설치하는 것입니다. 쉘 상태에서 다음 명령을 실행하면됩니다. (이미 이러한 개발 도구가 설치되어 있는 경우는 이 단계는 생략해도 됩니다) $ sed -i "s/^\exclude.*$/exclude=/g" /etc/yum.conf # allow kernel-devel package.                                                         $ yum groupinstall -y 'Development Tools' git 도구를 이용하여 php 소스를 다운 받습니다.  $ git clone http://git.php.net/repository/php-src.git                              ...
    Date2017.12.08 Category오픈소스 이야기 By김병욱 Views2906 Votes0
    Read More
Board Pagination Prev 1 ... 3 4 5 6 7 8 9 10 11 12 ... 16 Next
/ 16

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales