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

단축키

Prev이전 문서

Next다음 문서

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

 

들어가며

 데이터베이스는 결국 데이터를 저장해야 하고 데이터를 저장할 공간을 필요로 한다. 운영체제 위해서 동작하는 큐브리드는 운영체제로부터 필요한 만큼의 공간을 할당받고 이를 필요에 따라 효율적으로 사용한다. 이 글에서는 큐브리드가 영구저장장치에 데이터를 저장하기 위하여 내부적으로 어떻게 저장공간을 관리하는지에 대하여 이야기한다. 이를 통해 데이터베이스를 연구하고 개발하는 개발자들이 오픈소스 데이터베이스인 큐브리드에 좀 더 쉽게 접근할 수 있었으면 한다.

 

- 이 글의 내용은 버전 10.2.0-7094ba을 기준으로 하나, 최신 develop branch의 11.0.0-c83e33 에서도 차이가 없는 것으로 보인다.

 


큐브리드의 저장공간 관리

 큐브리드 서버는 여러 모듈들이 복합적이고 정교하게 동작하며 데이터를 관리한다. 이 중 저장공간을 관리해주는 모듈로는 디스크 매니저 (Disk Manager)와 파일 매니저 (File Manager)가 존재한다. 이들의 역할을 명확히 하기 위해서는 먼저 큐브리드에서 저장 공간을 어떠한 단위로 관리하는지를 알아야 한다.

 
페이지와 섹터

페이지(Page)는 큐브리드의 가장 기본적인 저장공간의 단위이다. 페이지는 연속적인 바이트의 연속으로 기본 크기는 16KB이며, 사용자가 볼륨을 생성할 때 8K, 4K 등으로 설정 가능하다. 페이지는 IO의 기본 단위이기도 하다.

섹터(Sector)는 페이지의 묶음으로 64개의 연속적인 페이지로 구성된다. 공간을 관리할 때, 페이지만을 단위로 연산을 수행하는 것은 비용이 크므로 이보다 큰 단위인 섹터를 두고 사용한다.

 
파일과 볼륨

 파일(File)은 특정 목적을 위해 예약된 섹터들의 묶음이다. 앞서 페이지나 섹터가 단순히 저장공간을 나누는 물리적인 단위였다면, 파일은 특정한 목적을 지니는 논리적인 단위이다. 예를 들어 사용자가 "CREATE TABLE .." 구문을 통해 테이블을 생성하면 테이블이 저장될 공간이 필요한데, 이 때에 파일의 일종인 힙 파일(Heap File)이 생성된다. 마찬가지로 인덱스를 생성하거나, 쿼리 결과를 저장하는 등 데이터를 저장할 일이 생긴다면 그 목적에 맞는 파일이 생성된다. 여기서 말하는 파일은 OS에서 open() 시스템콜을 통해 생성하는 OS 파일과는 구분된다. 이 후 이 글에서 특별히 언급하지 않는 한, 파일이라는 단어는 이 큐브리드의 파일을 의미한다.

 볼륨(Volume)이란 큐브리드에서 데이터를 저장하기 위해 운영체제로 부터 할당받은 OS 파일이다. "cubrid createdb .."등의 유틸리티를 통해 생성한 데이터베이스 볼륨을 말한다.

 다음은 이들을 간략히 도식화한 것이다.

Volume Architecture

 사용자가 데이터베이스 볼륨을 생성하면, 큐브리드 서버는 이 볼륨을 앞서 이야기한 섹터, 페이지 단위로 나누고 파일이라는 논리적인 단위로 묶어서 데이터를 저장하는데에 사용한다. 그림을 보면 OS의 파일로써 생성된 볼륨이 여러개의 섹터로 나뉘어져 있는 것을 볼 수 있고 목적에 따라 각 섹터들을 묶어 힙 파일, 인덱스 파일 등으로 사용하는 것을 볼 수 있다.

 

Note

- 여기서 볼륨은 로그볼륨등이 아닌 데이터가 저장되는 데이터 볼륨만을 이야기 한다.

- 볼륨, 페이지, 섹터는 물리적인 단위인데 반해 파일은 논리적인 단위로 하나의 파일이 계속 커질 경우 여러 볼륨에 걸쳐서 존재할 수도 있다.

 
디스크 매니저와 파일 매니저

 디스크 매니저와 파일 매니저는 이러한 저장공간 단위들을 관리하는 모듈이다. 각각의 역할은 다음과 같다.

 

디스크 매니저 (Disk Manager): 볼륨 공간 전체를 관리한다. 파일 생성 시 섹터들을 예약(Reservation)해 주고, 섹터가 부족하면 OS로부터 섹터를 더 확보하는 등의 역할을 한다.

파일 매니저 (File Manager): 큐브리드 파일들의 저장 공간을 관리한다. 파일이 추가적인 공간을 필요로 할 때 예약한 섹터들 중 페이지를 할당(Allocation)해주고, 더 이상 할당할 페이지가 없다면 디스크 매니저로부터 추가적인 섹터를 예약하는 등의 역할을 한다.
 

 다음은 이들의 관계를 도식화한 것이다.

Disk, File Manager

 

 힙 매니저, 비트리 매니저 등 다른 모듈들이 데이터를 저장할 공간이 필요할 경우, 목적에 맞게 파일을 생성하고 필요한만큼 저장공간을 할당한다. 파일매니저가 파일을 위하여 공간을 확보할 때에는 항상 섹터단위로 확보한 후, 내부적으로는 페이지 단위로 할당한다. 파일이 예약한 섹터를 모두 소진하여 더이상 페이지를 할당할 수 없게 되면 디스크 매니저로부터 섹터를 예약한다. 볼륨내의 저장 공간이 모두 소진되었을 경우, 디스크매니저는 OS로부터 추가적인 공간을 요청한다.

 아래에서 각 요청에 대한 처리가 어떻게 이루어지는지 자세히 살펴보자.

 


파일 사용 중 공간이 부족할 경우엔 어떻게 될까?

 만약 파일 사용 중에 할당받은 공간을 모두 사용하면 어떻게 될까? 예를 들어 테이블의 레코드들이 저장되는 힙파일에 삽입연산이 발생했는데, 더 이상 공간이 없는 경우등을 말한다. 답은 "추가적인 페이지를 할당받는다."이다. 페이지 할당과정을 이해하기 위하여 먼저 파일의 구조를 살펴보자.

 파일은 섹터단위로 디스크 매니저로부터 저장 공간을 확보하고, 이를 페이지 단위로 필요할 때마다 할당해서 사용한다. 이를 위해서 파일 매니저는 각 파일마다 파셜 섹터 테이블 (Partial Sector Table)과 풀 섹터 테이블 (Full Sector Table)을 두고 예약한 섹터의 할당 여부를 추적한다.

 

  • 파셜 섹터 테이블 (Partial Sector Table): 예약한 섹터 중, 섹터의 64개의 페이지 중 1개의 페이지라도 미할당된 상태라면 이 테이블에 등록된다. 각 섹터는 다음의 정보를 지닌다: (VSID, FILE_ALLOC_BITMAP)
  • 풀 섹터 테이블 (Full Sector Table): 예약한 섹터 중, 섹터 내의 모든 페이지가 할당되었을 경우에 이 테이블에 등록된다. 각 섹터는 다음의 정보를 지닌다: (VSID)

 VSID는 섹터의 ID이고, FILE_ALLOC_BITMAP은 각 섹터 내 64개의 페이지의 할당 여부를 표시한 비트맵이다. 이 두 테이블은 기본적으로 파일 헤더 페이지에 저장되며, 파일이 커짐에 따라 추가적인 시스템 페이지를 할당받아 테이블을 저장하기도 한다.

 페이지 할당 과정은 단순하다. 이렇게 두가지 테이블에 예약한 섹터 정보를 유지함으로써 (사실 이 두 테이블의 정보를 유지하는 것이 다소 복잡하다.), 추가적인 페이지가 필요할 경우 파셜 테이블의 엔트리를 하나 골라 비트맵의 비트를 하나 켜주는 것으로 페이지 할당을 완료할 수 있다. 만약 파셜 섹터테이블에 엔트리가 존재하지 않는다면 예약한 모든 섹터의 페이지를 할당해서 사용 중인 것이므로, 추가적인 섹터를 디스크 매니저로부터 예약해야 한다.

 

Note

- 페이지 할당은 System Operation (Top operation)으로 처리된다. 이는 트랜잭션중에 추가적인 공간이 필요하여 페이지를 할당하는 경우에, 트랜잭션의 commit, abort와 무관하게 페이지 할당 연산은 먼저 commit되는 것을 의미한다. 이를 통해 트랜잭션이 끝나기 전에 다른 트랜잭션도 할당된 페이지를 사용할 수 있게 되어(Cacading Rollback 혹은 기타 처리 없이) 동시성이 증가하게 된다.

- 파일 헤더에는 두개의 섹터테이블 말고도 유저 페이지 테이블 (User Page Table)이 존재한다. 이는 파일의 Numerable 속성을 위한 테이블로, 이 글의 범위는 넘어가므로 생략한다.

- 파일의 크기는 이론적으로 무한하게 커질 수 있으므로 섹터 테이블의 크기도 이를 추적할 수 있도록 계속해서 커질 수 있어야 한다. 이를 위해 큐브리드는 여러페이지로 이루어진 가변크기의 데이터 셋(set)을 저장하기 위한 File Extendible Data라는 자료구조를 가지고 있다.

 

파일 사용 중 더이상 할당할 페이지가 없다면 어떻게 될까?

 파일 사용 중 예약된 모든 섹터의 페이지를 사용했다면 추가적인 섹터를 예약해야 한다. 섹터의 예약이 어떻게 이루어지는지 살펴보기 전에 볼륨의 구조를 살펴보도록 하자. 다음은 볼륨의 구조를 도식화한 것이다.

Volume Format

 

 볼륨의 볼륨 헤더와 섹터 테이블 (Sector Table)을 포함하는 시스템 페이지와 나머지 유저 페이지로 이루어져 있다. 섹터 테이블은 파일의 파셜 섹터 테이블과 유사하게, 볼륨내 섹터들의 예약여부를 비트맵으로 들고 있다.

 페이지 할당 과정을 참고하면, 섹터의 예약 과정도 손쉽게 추측해 볼 수 있다. 섹터 테이블의 비트맵을 확인하고 예약되지 않은 섹터의 비트를 켜주는 것이다. 기본적으로는 이와 같으나, 섹터 예약은 여러 볼륨의 섹터 테이블들을 참고하여 예약 여부를 결정해야 하며, 그 과정에서 볼륨의 확장 및 추가 등의 작업이 일어날 수도 있기 때문에 효율성과 동시성의 증가를 위해 디스크 캐시 (DISK_CACHE)를 두고 다음과 같이 2 단계로 예약을 수행한다.

2 step sector reservation

 

1. 디스크 캐시를 통해 섹터를 사전 예약한다.

2. 사전예약의 결정 사항을 바탕으로 실제 볼륨들의 섹터테이블들을 순회화면서 예약비트를 킨다.

 

 그림과 같이 1의 과정에서 볼륨자체의 섹터를 모두 소진했을 경우에는 시스템 파라미터 (System Parameter)에 따라 볼륨을 확장하고, 최대 크기까지 확장하고나면 새로운 볼륨을 추가하기도 한다.

디스크 캐시는 전체 볼륨들의 섹터 예약정보들을 바탕으로 예약 시 필요한 값들을 미리 계산하여 가지고 있다. 예를 들어 각 전체 볼륨들의 가용 섹터 수 등을 섹터 테이블들의 정보를 바탕으로 가지고 있어, 이 값만 가지고 바로 현재 볼륨에서 예약이 가능할지 아니면 볼륨을 확장해야할지 등을 판단할 수 있다.

 

공간을 더 이상 사용하지 않는다면?

 예약했던 섹터들, 할당했던 페이지들이 더 이상 필요하지 않다면 어떻게 될까? 물론 공간을 반환하여 다른 데이터들이 저장될 수 있도록 해야 한다. 반환 과정은 기본적으로 예약이나 할당 과정에서 섹터 테이블의 비트를 켰던 것과 반대로 비트를 끄고, 섹터 테이블들을 규칙에 맞게 재구성하는 것이다.

 실제 공간을 반환하는 시점은 페이지 및 섹터를 사용하는 모듈의 정책에 따른다. 예를 들어 힙파일의 경우 데이터를 모두 삭제했다고 해서 바로 페이지를 반환하지 않는다. 힙 파일의 페이지를 반환하기 위해서는 해당 페이지에 있는 레코드를 모두 delete했을 때가 아니라, MVCC 및 Vacuum의 동작에 따라 더 이상 데이터가 필요없다고 힙 매니저가 판단했을 때이다. 또, 임시파일의 경우 정책에 따라 파일을 바로 제거하지 않고 다른 용도로 재활용하기 때문에 쿼리가 끝났다고 해서 쿼리 중에 사용한 임시 파일의 공간이 바로 반환되는 것은 아니다.

 공간 반환은 postpone 연산 (Deferred Database Modification)으로 수행된다. 즉 트랜잭션 중에 공간을 반환하더라도 커밋 시점 전까지는 반환이 처리되지 않는다.

 


임시 목적 데이터

 앞서 이야기한 내용은 영구 목적의 데이터들의 경우이다. 임시 목적의 데이터는 조금 다르게 처리된다. 여기에서는 이 차이점들에 대하여 간단히 정리한다. 그전에 먼저 데이터를 명확히 분류하고, 볼륨의 타입에 대해서 이야기해보자. 데이터는 크게 다음과 같이 두가지로 분류할 수 있다.

 

  • 영구 목적 데이터: 영구 목적의 데이터는 영구적으로 보존되어야 하는 데이터로, 데이터베이스가 실행 중에 Failure가 발생하더라도 온전한 상태를 유지해야 한다. 예를 들어 테이블의 레코드를 저장하는 힙 파일, 인덱스를 저장하는 비트리 파일은 영구 목적 데이터를 저장하는 파일들이다.
  • 임시 목적 데이터: 임시 목적 데이터는 쿼리수행에 따라 임시적으로 저장되는 데이터로, 데이터베이스가 재시작된다면 모두 의미없는 데이터가 된다. 예를 들어 쿼리 결과를 담는 중에 메모리가 부족하여 디스크에 쓰게 된 임시 파일이나, 외부 정렬 (External Sorting)과정에서 만들어진 임시 파일 등이 있다.

 위의 이야기에서 알 수 있는 가장 큰 차이점은 데이터베이스가 종료되어도 데이터가 유지되어야 하느냐이다. 이는 ARIES를 따르는 큐브리드에서는 곧 리커버리를 위한 로깅이 필요성 유무를 이야기한다. 영구 파일의 경우는 영구 파일 내의 데이터가 변경될 때에 항상 로깅을 하고, 임시 파일의 경우는 로깅을 하지 않는다. 또한, 임시 목적의 데이터는 재시작시 유지되어야 할 필요가 없으므로 여러 파일 연산에서 동작이 훨씬 단순해진다.

 
임시 목적 데이터와 볼륨

 데이터 볼륨의 타입에도 영구, 임시 두가지 타입이 존재한다. 데이터의 목적에 따라 어떤 볼륨에 어떤 데이터가 저장되는지를 도식화하면 다음과 같다.

volume type

 

 영구목적의 데이터의 경우에는 영구타입의 볼륨에만 저장된다. 반면에 임시 목적의 데이터는 임시타입, 영구타입 볼륨 모두에 저장될 수 있다. 이는 임시 데이터를 저장할 때마다 OS로부터 새로운 볼륨을 생성하고 포맷하는 것을 방지하기 위해, 사용자가 직접 임시 목적 데이터를 위한 볼륨을 추가할 수 있기 때문이다 (cubrid createdb -p temp). 임시 목적 데이터의 파일을 생성할 경우엔 사용자가 만들어둔 영구 타입의 임시 목적 볼륨을 먼저 찾아보고, 없을 경우에 임시 타입의 볼륨을 생성해 낸다. 임시 타입의 볼륨은 데이터 베이스 재시작 시 모두 제거되고, 임시 목적의 영구 타입 볼륨 역시 재시작 시에 내부의 모든 파일이 파괴된다.

 
임시 목적 데이터와 파일

 임시 목적 데이터가 담기는 파일 (이하 임시파일)들은 영구 목적이 담기는 파일들에 비해 관리가 단순하다. 임시 파일은 주로 쿼리의 결과나 중간 결과 등 쿼리 수행 중에 많은 양의 데이터에 접근하게 될 경우에 이를 임시로 저장하기 위한 파일이다. 이는 어차피 제거될 파일들이기 때문에 관리를 위한 오버헤드를 줄일 수 있고, 영구 파일에 비해 짧은 주기로 자주 생성/제거되는 파일이기 때문에 연산 자체가 빨라야 하기 때문이다. 차이점은 다음과 같다.

 

- 로깅을 하지 않는다.

- 페이지를 반환하지 않는다.

- 파일을 다 사용하더라도 파괴하지 않고 재사용한다.

- 섹터테이블을 한 종류만 사용한다.

 

 재시작되면 필요없는 데이터이기 때문에 로깅을 하지 않는 것은 기본이고, 페이지 내의 데이터가 더 이상 사용되지 않더라도 페이지를 따로 반환하지 않는다.

 파일 또한 바로 파괴하지 않고 시스템 파라미터에 따라 일정 수만큼 임시 파일을 캐싱해두고, 이 후 임시 파일이 필요할 경우에 재사용하도록 한다. 캐시가 가득 찼을 때에만 임시 파일을 지우므로, 쿼리 수행 중에 임시 목적 데이터를 위해 사용된 디스크 공간은 쿼리가 끝나고 바로 반환되지 않고 유지되는 것을 확인할 수 있다.

 영구 파일의 페이지 할당 과정에서 살펴본 섹터 테이블은 결국 페이지의 할당과 반환이 반복되는 상황에서 할당되지 않는 페이지를 빠르게 찾기 위한 것인데, 임시 파일의 경우에는 페이지 반환 자체를 하지 않기 때문에 단순히 파셜 섹터 테이블과 같은 형태의 테이블 하나만을 사용하며 순차적으로 페이지를 할당해 나간다. 만약 섹터 내의 페이지를 모두 할당했더라도 이를 풀 섹터 테이블로 옮기지 않는다. 단순히 예약한 섹터와 섹터들 내에서 어떤 페이지까지 예약했는지를 트래킹하는 용도로 사용된다.

 이외의 기본적인 사항은 위에서 살펴본 디스크 매니저와 파일 매니저의 동작을 그대로 따른다.

 


참고자료

1. CUBRID Manual - https://www.cubrid.org/manual/en/10.2/

2. CUBRID Source Code - https://github.com/CUBRID/cubrid

3. Mohan, Chandrasekaran, et al. "ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging." ACM Transactions on Database Systems (TODS) 17.1 (1992): 94-162.

4. Liskov, Barbara, and Robert Scheifler. "Guardians and actions: Linguistic support for robust, distributed programs." ACM Transactions on Programming Languages and Systems (TOPLAS) 5.3 (1983): 381-404.

5. Silberschatz, Abraham, Henry F. Korth, and Shashank Sudarshan. Database system concepts. Vol. 5. New York: McGraw-Hill, 1997.


  1. 데이터 베이스 접근 제어와 CUBRID

    데이터 베이스 서비스/운영 환경에서는 데이터의 손실을 근본적으로 차단하기 위한 여러가지 솔루션이 있습니다. 그 중 대표적인 솔루션인 데이터 베이스 접근 제어가 어떻게 CUBRID와 연동 되는지에 대해 기술하였습니다. CUBRID 접속 환경 CUBRID 데이터 베이스의 접근하는 기본적으로 2가지 형태 입니다. (환경에 따라 다를 수 있습니다.) 데이터 베이스 개발자 또는 관리자를 위한 경우 - IDE, Manager 툴을 사용하여, CUBRID 사용, 관리 CUBRID 데이터베이스를 활용하여, 애플리케이션을 서비스 하기 위한 경우 - 웹 서비스를 위한 WAS 사용, 별도의 애플리케이션 사용 CUBRID는 데이터베이스의 연결 전 BROKER 서버의 PORT로 접속 하여, 데이터베이스와 연결 됩니다. 브로커 포트 확인 하기 - 현재 설정 된 값은 기본 설정 값으로 환경 설명을 위한 정보 입니다. 구성 시 변경 가능 합니다. - query_editor(TCP_30000) 개발 및 관리자용 / broker1(TCP_33000) 서비스용 cubrid@host1$ cat $CUBRID/conf/cubrid_broker.conf [broker] MASTER_SHM_ID =30001 ADMIN_LOG_FILE =log/broker/cubrid_broker.log [%query_editor] -- 브로커 명 SERVICE =ON SSL =OFF BROKER_PORT...
    Date2020.08.23 Category제품 여행 By윤준수 Views2334 Votes0
    Read More
  2. 가벼운 웹 프레임워크 Flask위에 CUBRID 얹기

    Python 기반 Web Framework를 떠올리면 DJango를 떠올릴텐데요. Django 보다 가볍고 쉬운 Flask Web Framework와 CUBRID 데이터 베이스 연동 하는 방법을 기술 하였습니다. - Windows 환경에서의 구성과 Linux 환경에서의 구성 Spec.CUBRID 10.2 64bit Windows 10 64 bit - python 3.6.7 - Flask 1.1.2 - Werkzeug 1.0.1 Ubuntu 20.04.1 LTS (Linux) - python 3.8.2 - Flask 1.1.2 - Werkzeug 1.0.1 CUBRID Server# vi /etc/hosts - hostname과 IP 매칭 # ufw allow 33000/tcp # su - cubrid $ wget http://ftp.cubrid.org/CUBRID_Engine/10.2_latest/CUBRID-10.2-latest-Linux.x86_64.sh $ sh CUBRID-10.2-latest-Linux.x86_64.sh $ cubrid service start $ cubrid server start demodb Windows (Flask) WEB ServerPython Install python : https://www.python.org/ - 3.6.7 Release version 다운로드 및 설치 - 환경 변수 Path : C:\Users\<username>\AppData\Local\Programs\Python\Python36\Scripts 추가 Path : C:\Users\<username>\AppData\Local\Programs\Python\Python36 추가 flask Install cmd> pip3 install flask cmd> flask --version CUBRID Driver - CUBRID FTP...
    Date2020.08.12 Category제품 여행 By윤준수 Views2909 Votes1
    Read More
  3. DBeaver Database Tool 큐브리드 사용하기

    1, DBeaver 소개 DBeaver는 SQL 자동 완성과 구문 강조를 지원하는 편집기를 제공하며 이클립스 플러그인 구조 기반의 플러그인 아키텍처를 제공함으로써 데이터베이스에 특화된 기능이나 데이터베이스에 독립적인 기능들을 제공할 수 있게 한다, DBeaver와 CUBRID 사용은 JDBC 드라이버와 데이터베이스 Connection 정보를 설정해 사용할 수 있다. 2, DBeaver 다운로드(https://dbeaver.io/) 2, DBeaver 설치 - 언어선택 후 윈도우 프로그램 설치와 동일하게 “다음” 클릭해 설치를 완료한다. 3, DBeaver CUBRID 연결 3-1, 콘센트 모양 클릭 3-2, Select your database 매뉴에서 CUBRID 선택 3-3, JDBC Connection Setting* General 입력정보 - Host : CUBRID 서버 IP정보 입력 - Server & Database/Schema : 데이터베이스명(Oracle 기준 SID) * Authentication 입력정보 - Username : dba - Password : 비번 (참조: CUBRID는 설정 전 DBA 초기 패스워드 없음) 3-4, Edit Driver Setting* Edit Driver Settings + CUBRID - Url Template 기본에는 jdbc:CUBRID:{host}:{port}:{server}:{database}:: 등록되어 있으나 jdbc:CUBRID:{host}:{port}:{database}::: 로...
    Date2020.07.09 Category제품 여행 By정만영 Views8835 Votes0
    Read More
  4. named pipe를 활용한 압축 백업하기.

    작년 12월 18일에 CUBRID 10.2가 릴리즈 되었다. 자세한 링크는 다음과 같다. https://www.cubrid.com/3824761 이번 버전부터 backup 시 named pipe 를 활용 할 수 있다. Named Pipe | 파이프를 이용해 명령들을 연결하여 사용하거나 명령, 프로세스 치환을 사용하면 명령 실행 중에 자동으로 pipe 가 생성되어 사용된 후 사라지게 되는데요. 이때 생성되는 파이프를 이름이 없다고 해서 unnamed pipe 또는 anonymous pipe 라고 합니다. 이에 반해 named pipe 는 직접 파이프를 파일로 만들어 사용합니다. 자 이제 Named pipe를 생성해 보자. 1 2 3 $ mkfifo backup_pipe $ ls -al backup_pipe prw-rw-r--. 1 hiclass hiclass 0 May 25 10:40 backup_pipe 이렇게 생성해도 되고 1 2 3 $ mknod backup_pipe p $ ls -al backup_pipe prw-rw-r--. 1 hiclass hiclass 0 May 25 10:40 backup_pipe 이렇게 생성 할 수도 있다. 이제 생성한 파이프를 이용하여 백업을 해보자. 먼저 용량비교를 위해서 파이프를 사용하지 않은 일반 백업을 해 보겠다. $ cubrid backupdb demodb -S -l 0 -z -D . -o bk.out Backup Volume Label: Level: 0, Unit: 0, Database demodb, Backup Time: Mon ...
    Date2020.05.25 Category제품 여행 ByHiCLASS Views1301 Votes0
    Read More
  5. CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager)

    들어가며 데이터베이스는 결국 데이터를 저장해야 하고 데이터를 저장할 공간을 필요로 한다. 운영체제 위해서 동작하는 큐브리드는 운영체제로부터 필요한 만큼의 공간을 할당받고 이를 필요에 따라 효율적으로 사용한다. 이 글에서는 큐브리드가 영구저장장치에 데이터를 저장하기 위하여 내부적으로 어떻게 저장공간을 관리하는지에 대하여 이야기한다. 이를 통해 데이터베이스를 연구하고 개발하는 개발자들이 오픈소스 데이터베이스인 큐브리드에 좀 더 쉽게 접근할 수 있었으면 한다. - 이 글의 내용은 버전 10.2.0-7094ba을 기준으로 하나, 최신 develop branch의 11.0.0-c83e33 에서도 차이가 없는 것으로 보인다. 큐브리드의 저장공간 관리 큐브리드 서버는 여러 모듈들이 복합적이고 정교하게 동작하며 데이터를 관리한다. 이 중 저장공간을 관리해주는 모듈로는 디스크 매니저 (Disk Manager)와 파일 매니저 (File Manager)가 존재한다. 이들의 역할을 명확히 하기 위해서는 먼저 큐브리드에서 저장 공간을 어떠한 단위로 관리하는지를 알아야 한다. 페이지와 섹터 페이지(Page)는 큐브리드의 가장 기본적인 저장공간의 단위이다. 페이지는 연속적인 바이트의 연속...
    Date2020.03.31 Category제품 여행 By김재은 Views1596 Votes1
    Read More
  6. linux버전 CUBRID 기본 설치 디렉터리 바꾸기

    10.1 버전 부터 linux 용 버전인 CUBRID-10.x.x.xxxx-d56a158-Linux.x86_64.sh를 설치하면 기본 설치 디렉터리가 예전과 다르게 엄청 길어진다. 아래의 그림과 같이 보이게 된다. 유지관리나 해당 콘솔에서 작업을 할 때 디렉터리명이 길어지면 상당히 불편하다. 이전 버전과 같이 CUBRID로 설치 되게 설치 패키지를 수정해 보자. 일단 linux용 버전의 패키지.sh 파일의 구조는 다음과 같다. vi로 열어보면 상단 shell script + 하단 tar with gzip 으로 구성 되어 있다. 그래서 일단 스크립트 부분과 tar+gz 부분을 분리해 보자. 스크립트 소스 네에는 다음과 같은 힌트가 있다. 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 # take the archive portion of this file and pipe it to tar # the NUMERIC parameter in this command should be one more # than the number of lines in this header file # there are tails which don't understand the "-n" argument, e.g. on SunOS # OTOH there are tails which complain when not using the "-n" argument (e.g. GNU) # so at first try to tail some file to see if tail fails if used with "-n...
    Date2020.01.21 Category제품 여행 ByHiCLASS Views1341 Votes6
    Read More
  7. No Image

    LOB 데이터 경로 변경하기

    운영을 하다 보면 DB 데이터의 경로를 변경해야 하는 경우가 있는데요, CUBRID의 경우 DB 백업/복구를 통해 DB 데이터의 경로 변경을 지원하고 있습니다. 하지만 LOB 데이터는 DB 내부에 저장되지 않고, 외부 파일 시스템에 파일 형태로 저장되고 DB 내부에는 해당 파일의 위치정보만 저장되기 때문에 DB 백업/복구 시에는 LOB 데이터 파일에 대한 별도 관리가 필요합니다. 이 글에서는 DB 데이터 경로변경에 더불어 LOB 데이터의 경로를 변경할 수 있도록 가이드하려고 합니다.(9.3기준) 1. 테스트 정보 - DB 명 : testdb - 기존 경로 : /home/cubrid/CUBRID/databases/testdb - 변경 경로 : /disk/testdb 2. 경로 변경 절차 1) 서비스 종료 $ cubrid service stop @ cubrid server stop: testdb Server testdb notified of shutdown. This may take several minutes. Please wait. ++ cubrid server stop: success @ cubrid broker stop ++ cubrid broker stop: success @ cubrid manager server stop ++ cubrid manager server stop: success @ cubrid master stop ++ cubrid master stop: success 2) DB 백업 (백업 옵션은 매뉴얼 참조) $ cubrid backupdb -D /disk/BACKUP...
    Date2020.01.16 Category제품 여행 By허서진 Views2004 Votes0
    Read More
  8. No Image

    SSH 공개키 인증을 사용하여 암호 없이 편리하게 원격 호스트에 접속하기-!

    SSH 키는 공개 키 암호화 방식 및 인증 확인 응답 인증을 사용하는 SSH 서버에 대해 자체 식별하는 방식입니다. 비공개 서버에 접속하기 위해서는 인증절차를 거쳐야 하는데요, 기존에 비밀번호를 네트워크를 통해 보내는 비밀번호 인증은 네트워크 상에서 ID/비밀번호가 그대로 노출되는 문제가 있고, 접속할 때마다 입력해야 하는 번거로움이 있습니다. SSH 키는 이와 달리 공개키 암호 방식을 사용하여 서버에서 인증받을 수 있으며, 암호를 생략하고 원격 호스트로 접속할 수 있습니다. 과정은 아래와 같습니다. 1. 로컬 호스트에 키 생성(private key, public key) 2. 원격 호스트에 public key 복사(public key 만으로는 복호화할 수 없기 때문에 여러 서버에 복사해도 무관) 3. 로컬 호스트에서 원격 호스트로 ssh 접속 4. 원격 호스트에서 public key로 암호화 된 정보를 로컬 호스트에게 주고, 로컬 호스트는 private key와 원격 호스트의 public key를 이용하여 복호화 수행 5. 인증 완료 시 암호 입력 필요 없이 접속 가능 실제 명령어 수행 과정을 살펴보도록 하겠습니다. 1. 로컬 호스트에 키 생성 ssh-keygen 명령어를 이용해 private/public 키를 생성합니다. s...
    Date2020.01.03 Category나머지... By허서진 Views17268 Votes0
    Read More
  9. No Image

    LINUX 설정 값 nproc, nofile 과 큐브리드의 관계

    LINUX 설정 값 nproc, nofile 과 큐브리드의 관계 리눅스의 설정 값 중 nproc, nofile이 있습니다 [정의] 1. nproc : User당 사용할 수 있는 프로세스 최대 개수 2. nofile : User당 오픈할 수 있는 파일 개수 (리눅스에서는 모든 개체를 파일로 봅니다.) [문제 사항] 값이 적을경우 아래와 같은 문제가 발생할수 있습니다 큐브리드 계정으로 로그인이 안되는 오류 발생 cubrid server 에러에 shutdown a connection이 발생할수 있습니다 [설정 값 확인] < USER MAX 값 확인 > $ ulimit -aS |grep "max user processes" $ ulimit -aH |grep "max user processes" < open file MAX 값 확인 > $ ulimit -aS |grep "open files" $ ulimit -aH |grep "open files" [측정 방법] 1. nproc # ps h -Led -o user |sort |uniq -c |sort -n - nproc는 프로세스 외 LWP 또한 측정하며, 위와 같은 명령어로 확인할 수 있습니다. 2. nofile $ expr `lsof -u [User Name] |wc -l` - 1 [설정 방법] # vi /etc/security/limits.d/20-nproc.conf 수정 (RHEL 7 기준) limits.d디렉토리의 설정 값이 마지막 적용되는 값 입니다. (limis.conf의 값이 먼저 적용 되고, 마지막으로 limits.d 디렉토리...
    Date2020.01.03 Category제품 여행 By강주원 Views18807 Votes0
    Read More
  10. No Image

    큐브리드에서의 신입사원

    2019년 9월 1일 첫 직장으로 큐브리드에 입사하였다. 날이 그리 차갑지도 덥지도 않은 그저 그런 가을 날에, 걱정 반 기대 반을 가슴에 품고서 새로운 사무실에 들어가 새로운 사람들과 만나게 되었다. 새로운 만남, 새로운 생활을 한다는 기대감과, 무슨 일을 하게 될까, 과연 잘 할 수 있을까 하는 걱정이 공존되는 날이었다. 데이터베이스 보다는 운영체제, 커널, 시스템만 했던 사람이 잘 적응할 수 있을 까, 늦깎이 신입사원이 잘할 수 있을까 등 걱정이 많았지만, 하지만 이번 글에서는 새해가 오는 만큼 걱정 보다는 좋았던 점에 대해서만 다루겠다. 큐브리드에서의 생활은 기대했던 것과는 달리 늘 좋았다. 물론, 큐브리드 블로그에서 쓰는 글이라 믿지 못할 지도 모르겠지만 늘 좋았다. 내가 경험했던 직장생활은 '미생'이 유일했기에 하는 말일 수도 있겠지만, 생각했던 것과는 다른 생활이었다. 신입사원이 느꼈던 좋은 점에 대해 몇 가지 나열하자면, 우선, 대화가 자유롭다. 직급에 상관없이 서로 질문하고, 대답해주고, 대화하는 것에 아무런 거리낌이 없다. 오프라인으로 서로 질의응답을 하는 것은 물론, 온라인으로 서로 소통하는 것에 있어 자유롭다...
    Date2019.12.31 Category나머지... By김주호 Views579 Votes0
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 16 Next
/ 16

Contact Cubrid

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