Category: MariaDB

MariaDB 에 대한 글을 모아놓은 카테고리

데이터베이스를 위한 시스템 설정 – HugePage Size

Oracle, MariadB, MySQL 등과 같은 관계형 데이터베이스를 다루다보면 시스템 튜닝에 대해서 많이 접하게 된다. 특히나 리눅스 시스템에서 이들 데이터베이스 시스템이 제대로 작동하기 위한 운영체제 차원에서 필요한 작업을 많이 하게 된다.

이러한 운영체제 차원에서 작업은 여러가지가 있어서 알아야 하는 내용도 많고 세팅해야 하는 것도 많다. 대부분 인터넷이나 가이드 북을 이용해 어찌어찌 설정을 한다고 하지만 많은 사람들이 그것이 왜 필요한지 깊게 이해하는 사람들은 드물다.

그래서 아주 간단하게 데이터베이스 시스템을 다루는데 있어 리눅스 운영체제에서 필요로 하는 작업에 필요한 배경지식에 대해서 다루어 보고자 한다.

가상 메모리 관리(Virtual Memory Management)

모든 운영체제는 가상 메모리 관리 기법을 사용한다. 가상이라는 말에서 보이듯이 메모리를 가상화 한다는 이야기인데, 정확하게 말하면 실제로 물리적 메모리의 양이 정해져 있는데도 불구하고 그보다 많은 메모리를 필요로하는 애플리케이션을 구동할 수 있게 해주는 기법이다.

가상 메모리 관리 기법이 존재하기 전에는 실제 물리적 메모리 보다 많은 애플리케이션을 실행할 수 없었다. 더군다나 현대의 운영체제는 멀티 태스킹(Multi Tasking) 으로 운영되기 때문에 이들 애플리케이션 모두가 사용하는 메모리 양을 계산해보면 실제 물리적 메모리보다 많다. 그런데도 신기하게도 아무런 문제 없이 작동되는데 가상 메모리 기법 때문이다.

가상 메모리 관리에서 운영체제는 실제 주소가 아닌 가상 메모리 주소에 접근하게 된다. 하지만 실제 데이터는 물리적 메모리에 존재하기 때문에 가상 메모리 주소를 물리적 메모리로 변환해줘야 할 필요가 있다. 이렇게 가상 메모리 주소를 물리적 메모리 주소로 변환해주는 것이 MMU(Memory Management Unit) 이다.

이 MMU 는 물리적으로 CPU 내부에 존재한다. 현대의 거의 대부분의 CPU 에는 이런 MMU 가 다 있다.

MMU(Memory Management Unit)

MMU 는 가상 메모리 주소를 실제 물리적 주소로 변환해주는 것인데, 내부적으로 가상 메모리 주소와 물리적 주소를 매핑 시켜놓는 테이블이 존재한다.

일종의 매핑 테이블(Mapping Table) 인데 매핑 테이블은 가상 메모리 주소와 물리 메모리를 페이지(Page) 단위로 관리하도록 되어 있다. 쉽게 말하면 가상 메모리 주소 공간을 특정 크기 단위로 쪼갠 페이지, 실제 물리 메모리 주소를 특정 크기 단위로 쪼갠 페이지를 서로 매핑 시켜 논 것이다.

위 그림을 보면 가상 메모리, 물리 메모리가 양 옆에 있고 중간에 주소변환을 위한 페이지 맵(PAGE MAP) 혹은 테이블 이 존재한다.

MMU 느린 속도

MMU 내에 페이지 테이블이 존재는 가상 메모리를 물리 메모리로 빠르게 변환 시켜준다. MMU가 CPU 내부, 반도체 내부에 유닛으로 존재하다보니 소프트웨어에 비하면 속도가 매우 빠르다.

그런데, CPU 에서 가상 메모리에 접근할때 마다 페이지 테이블 전체를 스캔해야 한다. 그래야만 실제 데이터를 가지고 올 수 있을 테니까. 아무리 반도체 칩으로 구현되어 있어도 이렇게 데이터 접근시마다 페이지 테이블 전체를 스캔하면 아무해도 속도가 나질 않는다.

만일 페이지 테이블이 엄청나게 크다면 이 또한 속도에 영향을 준다.

느린 속도… 캐쉬가 답이다.

그래서 MMU 에 페이지 테이블 검색 속도를 높이기 위해서 중간에 캐쉬를 놓게 되었는데 이것이 바로 TLB(Translation Lookaside  Buffer) 이다.

위 그림은 가상 메모리 접근에 MMU 내부의 페이지 테이블과 TLB 가 작동하는지를 보여주는 그림이다. 간단하게 설명하면 CPU 는 무조건 TLB 를 먼저 찾는다. 캐쉬이다 보니까 필요로하는 데이터가 TLB 에 접근하면 찾을 수 있는지 검색을 하는 것이다. 만일 있다면 TLB 를 이용해서 물리 메모리에 접근하게 된다.

하지만 TLB 에 없다면 그때는 페이지 테이블을 전부 스캔하게 된다. 이렇게 페이지 테이블 스캔은 전체적으로 메모리 접근 속도에 영향을 주게 되고 전체적인 운영체제 성능에 영향을 미치게 된다.

4kb 크기의 페이지 문제

리눅스 운영체제에서 한 페이지 단위는 4kb 크기다. 만일 128GB 의 물리 메모리를 장착할 경우에 32M(약 3천 2백만) 개 정도의 페이지가 존재하게 된다. 이 많은 페이지를 페이지 테이블에 쑤셔 넣고 전체 스캔을 하게 되면 아무리 빠른 CPU라도 느릴 수밖에 없게 된다.

또한, 많은 양의 페이지는 TLB 에도 영향을 주게 된다. 너무나 많은 페이지가 존재 하다보니 캐쉬를 했던 페이지의 hit 율이 떨어져 자꾸 페이지 테이블 스캔을 하게 되는 것이다.

페이지 테이블이 페이지가 적고 캐쉬해야하는 양이 많으면 페이지 테이블를 스캔해야하는 일이 줄어든다.

HugePage 는 TLB 의 Hit 를 높여준다

Huge Page 는 기본 페이지 크기 4kb 를 크게 하는 기법이다. 이 기법을 사용하면 페이지 갯수가 줄어든다.

그런데, 많은 사람들이 페이지 크기를 늘리게 될 경우에 그 페이지가 가지는 데이터의 양을 한꺼번에 접근할 수 있어서 효율이 높아진다고 생각하는 경우가 많다. 물론 그런 영향이 없지는 않지만 Huge Page 를 하는 이유는 TLB 의 Hit 를 높여주는, 반대로 TLB 의 Miss 를 낮춰주는데 있다.

TLB 의 Hit 를 높여주면, 캐쉬 사용을 높여주면 데이터 접근이 빨라진다. 이것은 전체적인 운영체제의 메모리 성능을 높여주는 효과를 보여주게 된다. TLB Hit 를 위해서 간단한 방법이 바로 페이지 크기를 늘려주는 것이다. 4kb 마다 한 페이지가 아닌 2MB 마다 한 페이지라면 페이지 테이블 크기도 줄어들고 TLB 에 캐쉬된 페이지의 Hit 가 높아지게 된다.

Huge Page 사용 전략

HugePage 를 무턱대고 설정해서는 안된다. 일종의 전략이 반드시 필요하다.

  • OS 에서 지원해 줘야 한다.
  • 애플리케이션에서 지원해 줘야 한다.
  • 공유 메모리 설정과 연계되어 있다.

HugePage 를 사용하면 무조건 OS 상에 성능이 개선되는게 아니다. OS 에서는 당연히 사용을 하겠지만 애플리케이션에서도 HugePage 사용이 가능해야 한다.

HugePage 가 사용 가능한 애플리케이션으로 데이터베이스 시스템이 있다. PHP 와 같은 경우에도 사용이 가능하다고 한다.

무엇보다 중요한 것은 HugePage 설정은 단일 애플리케이션 시스템에 적합하다. Oracle 데이터베이스 하나만 작동하는 시스템이나 MySQL 하나만 작동하는 시스템등 여러 애플리케이션이 아니라 단일 애플리케이션만 구동하는 환경이라야 한다.

리눅스에서 HugePage 설정

MariaDB 를 위해 설정을 진행 해보자. 환경은 다음과 같다.

  • CentOS 8 64bit
  • RAM 4G
  • MariaDB 10.5.8

가장 먼저 해야할 것은 Transparent Huge Pages (THP) 설정을 never 로 바꾸는 것이다. THP 는 HugePage 를 자동으로 맞춰주는 기능인데, 성능 하락을 가져오기도 한다.

커널 파라메터를 수정하는 방법도 있지만 grub 에 부팅 옵션을 추가하는 것이 가장 간단하다.

위와같이 한 다음 재부팅을 한번 해주면 적용 된다.

현재 상태를 살펴보자. /proc/meminfo 를 보면 알 수 있다.

내용을 보면 아직 HugPage 를 사용하고 있지 않다고 나온다. 여기서 이제 계산이 필요하다. 얼마만큼 사용할 것인가, 누가 사용할 것인가 결정해야 하는 것이다.

MariaDB 를 사용할 것인데, MariaDB 를 사용하는데 있어서 InnoDB 를 사용할 것이다. InnoDB 는 Innodb pool 이 주로 메모리를 사용할 것인데, MariaDB 의 경우 물리 메모리에 약 70% 를 Inndb Pool 로 할달할 것을 권고 하고 있다. 나머지 10%는 MariaDB 자체 운영을 위해서 필요 하다. 전체 물리메모리에 약 80%에 해당한다.

df -k 했을때 나오는 전체 메모리 양이 3825740 kb(약 3.8GB) 인데, 이것에 80% 이면 3060592 kb 이다. 이것을 다시 2048 kb (한 페이지 크기) 로 나누면 1494.4296875 인데, 대략 1500 정도로 해두면 될 듯 하다.

이것을 이제 커널 파라메터로 넘겨 준다. sysctl.d 디렉토리에 파일을 만들어 별도로 관리해준다.

vm.hugetlb_shm_group 은 hugetlb 를 사용할 리눅스 시스템 그룹을 지정한 것이다.

MariaDB 에서 설정하기

시스템에서 HugePage 사용을 설정했다고 MariaDB 가 알아서 사용하지 않는다. my.cnf 서버 설정 파일에서 사용하도록 지정해 줘야 한다.

MariaDB 10.5.8 컴파일 설치

MariaDB 10.5.8 컴파일 설치를 해보도록 한다. 컴파일 설치를 위한 환경은 다음과 같다.

  • CentOS 8(x86_64) Latest version
  • 최소 설치(Minimal Installation) 환경

CentOS 8 에 최소 설치 환경이 매우 중요 하다. 최소 설치 환경이 아니라면 이 문서 내용 그대로 할 수는 없을 수도 있다.

컴파일 환경 구축

CentOS 8 을 최소설치하게 되면 패키지 저장소 또한 최소한으로 활성화가 된다. CentOS 8 은 패키지를 위한 저장소를 많이 분할해 놨는데 다음과 같다.

최소설치한 후 활성화된 저장소는 다음과 같다.

RedHat 배포판의 경우 프로그래밍 라이브러리들은 devel 패키지로 불린다. 이런 devel 패키지는 powertools 저장소에 존재한다. 따라서 이 저장소를 다음과 같이 활성화 시켜준다.

이제 컴파일을 위한 컴파일러와 라이브러리를 다음과 같이 설치 한다.

설치 작업시에 필요한 유틸리티 프로그램도 함께 설치해 준다.

Configure, Make, Install

컴파일을 위해 Configure 를 해준다. Configure 를 하기전에 소스 압축을 해제한 디렉토리에 build_target 디렉토리를 만들고 그 안에 다음의 내용을 기반으로 하는 build.sh 스크립트 파일을 작성해 준다.

build.sh 파일을 작성한 후에 다음과 같이 실행 퍼미션을 주고 실행해 준다.

아무런 오류 없이 실행이 됐다면 컴파일과 설치를 해준다.

이상 없이 컴파일과 정상적으로 설치가 되었다면 설치후 작업을 진행한다.

설치 후 작업

Mariadb 는 정상적으로 작동하기 위해서는 시스템 계정이 반드시 필요하다. 다음과 같이 시스템 계정을 생성해 준다.

계정 생성이 되었다면 이제 데이터베이스가 사용할 데이터 디렉토리를 생성해 준다.

MariaDB 의 라이브러리를 인식시켜준다.

이제 간단하게 데이터베이스를 초기화 해야 하는데, 그러기 위해서 my.cnf 파일을 다음과 같이 생성.

이제 시스템 데이터베이스를 생성해준다.

galera_recovery 파일 수정

galera_recovery 라는 명령어가 있다. 이 파일을 쉘 스크립트 파일인데, mariadb.service 파일에도 이 명령어가 사용되고 있다. 그런데, 이 파일에는 사용지로 mysql 로 하드코딩되어 있어서 오류를 낸다. 바꿔준다.

systemd 등록

Mariadb 에서는 systemd 등록을 위한 서비스 유닛 파일을 제공한다. 이 파일은 설치 디렉토리에 support-files/systemd 에 mariadb.service 파일로 존재한다. 이 파일을 열어서 mariadb 실행 계정과 그룹을 다음과 같이 바꿔 준다.

systemd 를 사용할 경우에 Max file open 갯수를 mariadb.service 에서 바꿔줄 수 있다. 물론 /etc/security/limits.conf 파일을 수정해야하는 경우도 있다.

이제 systemd 에 등록하고 활성화 해준다.

Mariadb 시작/중지

이제 제대로 설치가 되었는지 Mariadb 를 시작/중지 해보자.

아무런 에러가 없다면 정상적으로 작동하는 것이다.

MariaDB 10.2.13 소스 설치

MariadbMariaDB 는 MySQL 의 오픈소스 버전 입니다. MySQL 를 최초로 개발한 사람이 점점 폐쇄성이 짙어가는 MySQL 을 대체하기 위해 MySQL 을 복제하고 기능을 개선한 MySQL 의 또 다른 버전 입니다.

현재 MariaDB 는 10.2.13 버전 입니다. MariaDB 10 소스 설치를 해보겠습니다. 설치 환경은 다음과 같습니다.

  • CentOS 7
  • 64bit

준비

다음의 패키지가 설치되어 있어야 합니다.

 

다운로드 및 unpack

 

Configure and make and install

MariaDB 는 cmake 를 이용하기 때문에 일반 Configure 와는 다르게 이것을 이용 합니다.

 

설치후 작업

설치가 끝난 후에는 수동으로 옮겨주어야할 파일들이 존재 합니다. 그래서 설치 후 작업을 다음과 같이 진행 합니다.

계정을 추가 합니다.

디렉토리 설정과 관련된 my.cnf 내용은 다음과 같습니다.

다음과 같이 디렉토리를 생성하고 소유권을 바꿔 줍니다.

MariaDB 라이브러리 시스템 인식.

시스템 데이터베이스 생성.

Systemd 스크립트 등록.

user, group 을 mysql 에서 maria 로 바꿔 주고 등록해줍니다.

 

galera_recovery 파일에 mysql 를 maria 로 바꿔 줍니다.

 

다음과 같이 mariadb 를 시작해 줍니다.

 

Xtrabackup 을 활용한 Replication 설정

Xtrabackup 을 이용한 Slave 추가 하기.

Master 에 Slave 를 추가해야 하는데, Online 상황에서 추가하기는 쉽지가 않다. 대부분 mysldump 를 이용해서 추가 하는 방법이나, mysql data 디렉토리를 압축해서 해제하는 방법을 쓰거나 둘중 하나이다.

하지만 이렇게하면 Online 상태를 유지할 수 없다. Online 상태를 유지면서 Master 의 데이터를 옮기는 방법으로는 Xtrabackup 을 이용하는게 제일 좋다.

먼저, Xtrabackup 툴을 Master 와 Slave 서버에 모두 설치해 준다. 그리고 Master 서버에 다음과 같이 백업을 위한 계정을 생성한다.

그리고 두가지를 생각해봐야 한다. 먼저 새롭게 준비된 Slave 에서 Master 에서 데이터를 땡겨올건지 아니면 Master 에서 Slave 로 쏴줄 것인지이다.

새로운 Slave -> Master 로 접속해서 데이터를 끌어오는 방법은 다음과 같다.

Master -> Slave 로 데이터를 쏴줄때는 다음과 같이 한다.

쏴줄때에 위와같이 하면 백업 진행중에 ssh 접속 패스워드 입력하라는 프롬프트가 나오고 지나가버립니다. 그래도 패스워드를 입력하면 됩니다.

백업 완료되면 디렉토리에 xtrabackup_binlog_info 파일 생성되고 다음과 같은 내용이 포함된다.

이 내용을 기반으로 Replication 을 할때에 활용한다.

데이터를 다 끌어오는 동안에 변경된 데이터를 적용해야하는데, 다음과 같이 한다.

그리고 다음과 같이 복원을 시행한다.

그리고 다음과 같이 리플리케이션을 걸어준다.

 

M-HA MySQL 설정

MySQL 은 인기있는 오픈소스 데이터베이스 시스템이다. 언제나 데이터베이스 시스템이라면 항상 따라오는 것이 Master-Slave 리플리케이션 환경이고 거기에 덧붙여 자동 페일오버(Auto FailOver) 를 어떻게 할 것이라는 골머리 앓는 주제가 따라서 나온다.

MySQL 의 경우에 자체 적인 FailOver 솔루션이 있다. Fabric 이 그것인데, 아직은 많이 쓰이지는 않는 모양이다. 대신에 AutoFailOver 를 지원하는 제3의 툴들이 존재하는데 M-HA 가 바로 이러한 솔루션이다.

M-HA 는 일본인이 Perl 을 이용해서 작성한 솔루션이다. github 저장소에 소스코드는 공개되어 있으며 저장소이름은 mha4mysql-manager 이다.

구조

M-HA 는 Manager 와 Node  로 이루어진다. Node 는 MySQL 이 설치된 서버에 모두 설치해줘야 한다. Mater/Slave 구조라면 Node 를 모두 설치해줘야 한다.

Manager 는 이들 Node 를 감시하고 이들 전체를 컨트롤하는 역활을 한다.

M-HA 특징

M-HA 를 AutoFailover 로 사용할만한 이유는 다음과 같다.

  • Short downtime
  • MySQL-Replication consistency
  • Easy Installation
  • No chagne to existing deployments

M-HA  를 고려할때에 중요한 부분이 짧은 다운타임이다.  Master/Slave 구조에서 장애시에  Slave 를 Master 로 빠르게 승격을 시켜주어야 한다. 그래야만 두 서버간에 데이터가 달라지는 데이터 무결성이 깨지지 않게 된다. M-HA 는 비교적 이러한 데이터 무결성을 보장하기 위해서 많은 노력을 기울인 솔루션이라고 보면 된다.

M-HA 구성도

최소한의 환경에서 M-HA 를 구성도는 대략 다음과 같다.

M-HA Architecture
M-HA Architecture

M-HA Node 는  MySQL 이 설치된 서버라면 전부 설치해주어야 한다. M-HA Manager 는 외부서버에 설치해된다.

Node 설치

설치는 M-HA 구글 저장소에 가면 각 배포판별로 바이너리로 배포하고 있어 쉽게 설치가능하다. 여기서는 소스를 가지고 컴파일 설치하도록 하겠다.

git 저장소에 소스를 다운받거나 Clone 해서 가지고 와도 된다.

의존성 패키지를 다음과 같이 설치해준다.

Perl 을 이용해서 소스를 코드를 컴파일 하고 설치해주면 된다.

위와 같은 설치를 Master/Slave 모든 MySQL 서버에 설치해 준다.

그리고 각 서버에 M-HA 가 접속하기 위한 MySQL 계정을 생성해 준다.

MySQL 각 서버에 /var/log/masterha 디렉토리를 만들어 준다.

Manager 설치

한가지 주의해야 할 것은 Manager 를 설치하기 전에 Node 도 같이 설치해줘야 한다는 것이다. Manager 설치도 소스코드를 다운받아 설치한다. 그 전에 다음과 같이 의존성 패키지를 설치해준다.

소스코드를 다운받는다.

컴파일 설치해 준다.

Manager 에 mha.cnf 파일 작성

Manager 의 mha.cnf 파일을 다음과 같이 작성한다.

SSH 접속 설정

M-HA 는 내부적으로 SSH를 이용해서  M-HA Node 의 릴레이 로그들을 전송하도록 한다. 그런데 자동으로 이게 되게 할라면 M-HA Manager 와 Node 들간 모두 SSH 를 무인증으로 접속이 가능해야 한다.

SSH RSA 를 생성하는데, 패스워드를 입력하지 않는다. 그러면 무인증 접속이 가능해진다.

각각에 생성한 키들은 ~/.ssh/authorized_keys  파일에 추가해준다. 중요한 것은 각각 서버들은 서로서로 모두 무인증 SSH 접속이 가능해야 한다는 것이다.

SSH 무인증 테스트를 다음과 같이 할 수 있다.

Replication 체크

다음과 같에 Replication 체크를 해본다.

여기서 버그가 있다. /usr/local/share/perl5/MHA/DBHelper.pm 파일 198 라인에 $host 변수에 문제가 있다.

위와같이 수정한 후에 다시 한번 해보면 오류를 해결할 수 있다.

이러한 문제는 호스트 이름에 ‘[‘, ‘]’ 를 붙임으로 나타는 현상이다. 이러한 문제는 다음의 파일에도 있다.

Manager 실행 시키기.

반드시 위에 버그를 제거한 후에 다음과 같이 실행을 한다.

위와같이 실행을 한 후 로그를 보면 다음과 같이 나와야 정상이다.

내용을 보면 192.168.96.32 서버가 현재 Master 고 30번 서버가 Slave 로 인식하고 있다.

FailOver 테스트.

간단한 FailOver 테스트를 해보자. 시나리오는 간단하다. 현재 Master 서버를 정지 시켜 보는 것이다. 그러면 다음과 같이 Manager 로그가 올라온다.

위와같이 로그가 온다면 FailOver 가 정상적으로 된 것이다. 또, 로그 디렉토리 /var/log/masterha 디렉토리에 mha.failover.complete 파일이 생성되어 있을 것이다. 또한, manager 가 죽어 있다. 그러니까 FailOver 가 발생되면 다음과 같이 실행이 된다.

  1. Slave 를 Master 로 승격시킨다.
  2. Manager 에 지정한 로그 디렉토리에 mha.failover.complete 파일을 생성한다.
  3. Manager 가 죽는다.

FailOver 가 발생할때마다 Manager 는 정해진 동작을 수행하고 자동으로 죽게 된다.

승격된 Master 서버에서는 다음을 체크해봐야 한다.

  1. show slave status 명령을 입력했을때 아무것도 나오지 말아야 한다.
  2. show variables like ‘%read%’ 명령어를 입력했을때에 read_only 값이 OFF 여야 한다.

위 두가지가 정상적으로 나온다면 M-HA 가 정상적으로 동작한 것이다.

TIMESTAMP and DATETIME 기능 개선

MariadbMariaDB 10 버전이 올라가면 기능이 향상되는데, TIMESTAMP 와 DATETIME 의 데이터 타입(Data Type)을 사용하는 컬럼에 경우 Update, Insert 시에 몇가지 기능이 향상되었습니다.

여기서 주목해야 할 것은 ‘created TIMESTAMP DEFAULT CURRENT_TIMESTAMP‘와 ‘updated TIMESTAMP ON UPDATE CURRENT_TIMESTAMP‘ 입니다.

Default와 Extra 컬럼에 내용을 자세히 보십시오.

여기서 Insert 를 다음과 같이 합니다.

‘created’ 컬럼에 자동으로 시간이 등록됩니다. 과거에는 다음과 같이 해줬어야 했습니다.

‘now()’ 함수를 사용해서 했어야 했지만 Mariadb 10 에서 TIMESTAMP 타입을 이용해서 컬럼을 정의하면 더 손쉽게 자동으로 처리를 해줍니다.

다음과 같이 Update 를 해봅니다.

update 필드에 값이 자동으로 시간이 업데이트 됩니다. DATETIME 도 이와 같은데 다른점은 값이 없을 경우 ‘NULL’이 됩니다.

test_date2 를 만들고 다음과 같이 실행보면 값이 없을때는 NULL이 들어 갑니다.

 

MariaDB 10 소스 설치

MariadbMariaDB 는 MySQL 의 오픈소스 버전 입니다. MySQL 를 최초로 개발한 사람이 점점 폐쇄성이 짙어가는 MySQL 을 대체하기 위해 MySQL 을 복제하고 기능을 개선한 MySQL 의 또 다른 버전 입니다.

현재 MariaDB 는 10.0.14 버전 입니다.  MariaDB 10 소스 설치를 해보겠습니다. 설치 환경은 다음과 같습니다.

  • 배포판: CentOS 7
  • 아키텍쳐: 64bit

준비

MariaDB 10.0.14 버전은 MariaDB 홈페이지에서 다운받을 수 있습니다. 그런데, 이 소스 버전을 가지고 설치를 할 수도 있지만, Fedora 배포판에서 패치한 버전을 가지고 설치를 해보겠습니다.

Fedora 배포판의 경우에 10.0.14 버전에 보안 패치나 경로에 대한 패치 그리고 CentOS 7 의 Systemd 를 지원하도록 하는 스크립트를 제공 합니다. 이것은 SRPM 을 다운받아 소스를 패치하는 방법을 썼습니다.

Configure && Compile && Install

MariaDB 는 cmake 를 이용하기 때문에 일반 Configure 와는 다르게 이것을 이용 합니다.

위 설정은 다음과 같은 주요한 기능을 가집니다.

  • Aria 스토리지 엔진 지원
  • Partition 스토리지 엔진 지원
  • XtraDB 스토리지 엔진 지원
  • TokuDB 플러그인 지원

설치 후 작업

Fedora 배포판의 설정중에 디렉토리 설정 부분을 많이 인용을 했기 때문에 기존의 컴파일 설치한 디렉토리와는 사뭇 다릅니다. 대부분의 소스 컴파일을 설치했을 때에는 대부분 설치할 디렉토리인 PREFIX 만 지정하기  때문에 벤치디렉토리, 서포트디렉토리등이 모드 PREFIX 이하에 놓입니다. 하지만 위 설정을 보시면 Fedora 배포판 호환인 RedHat 디렉토리 구조를 계승하고 있다는 것을 인지하시기 바랍니다.

설치가 끝난 후에는 수동으로 옮겨주어야할 파일들이 존재 합니다. 그래서 설치 후 작업을 다음과 같이 진행 합니다.

CentOS 7 데서부터 도입된 systemd 등록을 위한 파일들을 설치 합니다.

그리고 다음과 같이 스크립트 파일들을 복사해 줍니다.

이제 mariadb 를 운영하기 위한 계정을 생성해 주고 디렉토리 퍼미션을 조정해 줍니다.

이렇게 한 후에 다음과 같이 MariaDB 에 기본 데이터베이스들을 생성해 줍니다.

이제 다 되었습니다. systemd 를 이용해서 mariadb 를 시작하면 됩니다.

MariaDB 오픈 소스 데이터베이스

MariaDB 는 한 개발자의 노력을 시작된 오픈 소스 프로젝트 입니다. 과거 오픈 소스 데이터베이스의 대명사인 MySQL 을 개발한 개발자 중에 한인 Monty Widenius. 1962년 핀란드 태생으로 1995년 MySQL 데이터베이스를 개발하기 시작해서 그 이듬해에 첫 릴리즈를 하게 됩니다. 그리고 1998년, 3.21 버전부터 www.mysql.com 을 만들어 운영하면서 명실상부한 오픈 소스 데이터베이스로 발을 딛기 시작 합니다.

Monty Widenius
MySQL 을 개발한 Monty Widenius

MySQL은 오픈소스 정책을 가지고 있지만 개발과 판매등을 총괄하는 회사가 있습니다. MySQL AB 라는 회사인데, 개발지원에서부터 판매, 홍보까지 MySQL에 거의 모든것을 관장하던 회사입니다. MySQL이 오픈소스이긴 하지만 라이센스정책이 이중으로 되어있어(GPL, CopyRight) 이러한 라이센스 관련해서 제품의 구성등 전반적인 부분도 이 회사에서 모두 관리합니다.

MySQL이 오픈소스 진영에서 이름을 날리고 있던 2008년에 썬 아킥텍쳐 및 썬 OS로 유명한 ‘Sun microsystems’ 에 85억 달러에 인수 됩니다. 이때에 MySQL을 전부 총괄하던 MySQL AB 회사도 함께 넘어감으로써 모든 지적재산권도 썬으로 넘어가게 됩니다. 그러던 것이 1년도 않된 시점인 2009년 4월 오라클이 썬마이크로시스템즈를 인수함으로써 MySQL AB 의 모든 지적재선권은 다시 오라클로 넘어갑니다.

Oracle. 오픈소스 진영에서는 거의 악날함을 자주 보여줬던 RDBMS 최강의 회사 입니다. 상용시장에서 독보적인 오라클 데이터베이스 를 가지고 있었고 인수전에는 MySQL과 알게 모르게 경쟁하던 데이터베이스 제품을 가진 회사였기 때문에 인수당시부터 오픈소스진영에서는 MySQL에 대한 운명(?)에 대해서 우려하는 목소리가 많았습니다. ‘오라클 스럽게 죽일거다’라는 소리가 자주 들렸지요.

그런데, MySQL AB를 설립했던 Michael “Monty” Widenius(마이클 ‘몬티’ 비드니우스) 라는 사람이 오라클을 뛰쳐 나옵니다. 오픈소스 정의감으로 뛰쳐나왔으면 드라마틱하겠지만 오라클에서 대우가 별로 맘에 않들었다고 하네요. 그러한 그가 나와서 뭘했을 까요? 배운게 도둑질인데, 오라클 회사를 나와서 ‘Monty Program’ 이라는 것을 하게됩니다. 그리고 이 ‘Moty Program’ 에서 GPL 라이센스로 되어있는 MySQL 코드를 Branch 해서 RDBMS를 만들게 되었는데 그것이 바로 ‘MariaDB’ 입니다.

Monty Widenius 는  오라클이 MySQL 을 인수하게되자 오픈 소스 진영에 MySQL 을 구해달라는 호소문을 올리기도 합니다.

[MySQL 을 구해주세요!!]

실제로 오라클이 MySQL 을 인수하고 난 후에, 오라클은 라이센스 정책을 변경했으며 MySQL 의 테스트 소스코드를 비공개로 변경했습니다.

이러한 오라클의 폐쇄적인 정책으로 불구하고 MariaDB 는 수많은 개발자들의 기부로 인해서 성장했고 대부분의 리눅스 배포판에서 MySQL 을 대체하는데 이르렀습니다. 현재 MariaDB 는 10 버전을 출시로 더욱 강력해지고 안전한 데이터베이스를 제공하고 있습니다.

Mariadb
Mariadb 의 로고