MariaDB (r1)

MySQL의 창시자인 마이클 몬티 와이드니어스가 2008년 자신이 설립한 회사 MySQL AB를 썬 마이크로시스템즈에 매각한 것이 직접적인 계기가 되었다. 썬 마이크로시스템즈는 이후 2010년 오라클에 인수되었고, 이로 인해 MySQL의 향후 개발 방향과 오픈 소스 정책에 대한 우려가 커지기 시작했다.

몬티 와이드니어스를 비롯한 원래 MySQL 개발자들과 커뮤니티는 오라클의 통제 하에서 MySQL의 오픈 소스 생태계가 훼손될 가능성을 염려했다. 이에 따라, MySQL 코드베이스의 포크(fork)를 통해 독립적이고 커뮤니티 주도의 개발을 지속하기로 결정하였다. 그들은 MySQL 5.1 버전의 코드를 기반으로 2009년 초에 프로젝트를 시작했으며, 몬티의 딸인 '마리아'의 이름을 따 프로젝트명을 'MariaDB'로 명명하였다[2].

초기 개발은 주로 몬티 프로그램 AB에서 주도하였으며, 목표는 GPL 라이선스 하에 완전한 오픈 소스로 남아있으면서 MySQL과의 높은 호환성을 유지하는 것이었다. 첫 번째 안정판인 MariaDB 5.1은 2009년 10월 29일에 릴리스되었고, 이는 MySQL 5.1과 기능적으로 동등하면서도 일부 버그 수정과 새로운 스토리지 엔진(아리아)을 포함하였다. 이 포크는 데이터베이스 사용자와 리눅스 배포판들에게 MySQL의 대안으로 빠르게 주목받기 시작했다.

마리아DB의 개발은 MySQL 포크 이후 몇 차례의 주요 단계를 거치며 발전했다. 초기 버전은 호환성 유지에 집중했으나, 점차 독자적인 기능을 강화하는 방향으로 진화했다.

초기 개발 단계에서는 MySQL 5.1 및 MySQL 5.5와의 바이너리 호환성을 유지하며 안정성을 확보하는 데 주력했다. 버전 5.1, 5.2, 5.3을 거치며 Aria 스토리지 엔진, 세그먼티드 키 캐시, 마이크로초 단위 지원과 같은 성능 개선 요소를 도입했다. 특히 Aria는 MyISAM을 대체하는 크래시-세이프 트랜잭셔널 스토리지 엔진으로 개발되었다.

10.x 시리즈로 넘어오면서 개발 속도가 빨라지고 독자적인 정체성이 뚜렷해졌다. 마리아DB 10.0에서는 MySQL 5.5와의 호환성을 유지하면서도 Galera 클러스터를 통한 동기식 다중 마스터 복제를 기본 지원하기 시작했다. 이는 고가용성 아키텍처 구축에 중요한 전환점이 되었다. 이후 버전에서는 윈도우 함수, 공통 테이블 표현식(CTE), JSON 지원 등 현대적인 SQL 기능을 지속적으로 추가하며 오라클이 개발하는 MySQL 8.0의 기능과도 경쟁하게 되었다.

주요 버전별 주요 추가 사항은 다음과 같다.

현재 마리아DB 재단은 장기 지원(LTS) 버전과 단기 지원(STS) 버전을 혼합하여 출시하는 정책을 유지하고 있다. 이는 기업 환경의 안정성 요구와 최신 기능의 빠른 도입 요구를 동시에 충족시키기 위한 전략이다.

MariaDB는 플러그형 스토리지 엔진 아키텍처를 채택하여, 데이터를 물리적으로 저장하고 접근하는 방식을 선택할 수 있게 한다. 이는 핵심 기능인 SQL 문 처리와는 독립적으로 설계되어, 특정 워크로드나 성능 요구사항에 맞춰 최적의 엔진을 선택할 수 있는 유연성을 제공한다. 기본적으로 포함된 InnoDB 엔진은 트랜잭션 지원과 ACID 준수, 외래 키 제약 조건, 행 단위 잠금을 제공하는 표준 엔진이다.

다양한 용도를 위해 여러 특화 엔진을 포함한다. Aria 엔진은 MyISAM을 대체하는 비트랜잭션 엔진으로, 내구성이 향상되었으며 임시 테이블과 내부 온디스크 임시 테이블에 주로 사용된다. ColumnStore는 컬럼 기반 저장소를 사용하여 대규모 데이터 웨어하우징과 분석 쿼리에 적합하다. Memory 엔진은 모든 데이터를 RAM에 저장하여 초고속 임시 작업에 사용되지만, 서버 재시작 시 데이터가 사라진다.

사용자는 `CREATE TABLE` 문에서 `ENGINE = 엔진_이름` 절을 지정하여 테이블별로 엔진을 선택할 수 있다. 또한, 동일한 데이터베이스 내에서도 테이블마다 서로 다른 스토리지 엔진을 혼합하여 사용하는 것이 가능하다. 이 플러그형 구조 덕분에 커뮤니티나 서드파티가 개발한 새로운 스토리지 엔진을 쉽게 통합할 수도 있다.

MariaDB는 MySQL 포크에서 시작되었지만, 독자적인 성능 최적화와 확장성 기능을 지속적으로 개발하여 대규모 데이터 처리와 높은 동시성 환경에서 우수한 성능을 발휘한다. 핵심 성능 향상 요소로는 쿼리 최적화 개선, 병렬 쿼리 처리 도입, 그리고 인덱스 및 버퍼 풀 관리의 효율화가 포함된다. 특히, Aria 스토리지 엔진은 MyISAM을 대체하며 충돌 복구 기능과 향상된 캐싱을 제공하고, InnoDB는 기본 스토리지 엔진으로서 트랜잭션 안정성과 동시성 제어를 보장한다.

확장성 측면에서는 수평적 확장과 수직적 확장을 모두 지원한다. Galera 클러스터를 통한 다중 마스터 복제는 실시간 데이터 동기화와 고가용성을 제공하며, 읽기 및 쓰기 작업을 여러 노드로 분산시킬 수 있다. 또한, 샤딩을 위한 Spider 스토리지 엔진은 논리적으로 단일 데이터베이스처럼 보이게 하면서 물리적으로 여러 데이터베이스 서버에 데이터를 분산 저장하고 쿼리한다.

성능 튜닝을 위한 다양한 시스템 변수와 상태 변수를 제공하며, 쿼리 캐시의 대안으로 설계된 더 효율적인 캐싱 메커니즘을 도입했다. 대용량 데이터베이스 환경을 위해 테이블 파티셔닝, 컬럼 기반 스토리지 엔진인 ColumnStore, 그리고 윈도우 함수와 공통 테이블 표현식 같은 고급 SQL 기능을 지원하여 복잡한 분석 쿼리의 성능을 향상시킨다.

MariaDB는 데이터베이스 보안을 강화하기 위해 여러 계층의 기능을 제공합니다. 사용자 계정 관리, 접근 제어, 데이터 암호화, 그리고 감사 로깅이 핵심 요소입니다.

사용자 인증과 권한 관리는 GRANT 및 REVOKE 문을 통해 세밀하게 제어할 수 있습니다. MySQL과의 호환성을 유지하면서도, PAM (Pluggable Authentication Modules)이나 LDAP와 같은 외부 인증 시스템을 플러그인으로 지원하여 기업 환경에 맞는 인증 방식을 도입할 수 있습니다. 또한, 역할 기반 접근 제어를 통해 권한을 그룹화하여 관리 효율성을 높입니다.

데이터 보호를 위해 TLS/SSL을 통한 네트워크 연결 암호화를 지원하며, AES 알고리즘을 사용한 데이터 암호화 기능을 제공합니다. 이는 테이블스페이스 수준에서 적용되어 저장된 데이터 파일 자체를 암호화합니다. 보안 감사 측면에서는 MariaDB Audit Plugin을 활성화하여 데이터베이스에 대한 모든 접근과 쿼리 실행 이력을 기록할 수 있어, 규정 준수 요건을 충족하고 이상 징후를 탐지하는 데 도움을 줍니다.

MariaDB는 전통적인 클라이언트-서버 모델을 기반으로 동작하는 관계형 데이터베이스 관리 시스템이다. 이 모델에서 MariaDB 서버 프로세스(데몬)는 데이터베이스 엔진의 핵심으로, 데이터 저장, 처리, 관리의 모든 책임을 진다. 반면, 클라이언트 응용 프로그램(예: 웹 서버, 데스크톱 프로그램, 명령줄 도구)은 네트워크를 통해 서버에 연결하여 SQL 쿼리를 전송하고 그 결과를 받아 사용자에게 제공한다. 이 분리된 구조는 중앙 집중식 데이터 관리와 여러 클라이언트의 동시 접근을 효율적으로 지원한다.

클라이언트는 다양한 인터페이스를 통해 서버와 통신한다. 가장 일반적인 방법은 MySQL 프로토콜을 사용하는 네트워크 연결이다. 클라이언트 라이브러리(예: Connector/C, Connector/J, Connector/Python)를 사용하여 응용 프로그램 내에서 연결을 설정한다. 또한 `mysql` 명령줄 클라이언트와 같은 전용 도구를 사용하여 직접 서버에 접속하고 SQL 명령을 실행할 수도 있다. 서버는 이러한 연결 요청을 수락하기 위해 특정 네트워크 포트(기본값 3306)에서 대기(listen)한다.

서버 내부에서는 각 클라이언트 연결에 대해 별도의 스레드가 생성되어 요청을 처리한다. 이 스레드는 클라이언트의 인증을 확인하고, 전달받은 SQL 문을 구문 분석하고 최적화하며, 필요한 스토리지 엔진(예: InnoDB, Aria)을 호출하여 데이터를 읽거나 쓴다. 처리 결과는 다시 클라이언트에게 반환된다. 이 아키텍처는 여러 사용자와 응용 프로그램이 동시에 데이터베이스에 안전하게 접근할 수 있는 기반을 제공한다.

MariaDB에서 쿼리가 처리되는 과정은 크게 구문 분석, 최적화, 실행의 세 단계로 나뉜다. 이 과정은 쿼리 최적화기와 스토리지 엔진이 협력하여 효율적으로 수행한다.

먼저 클라이언트로부터 받은 SQL 문은 파서에 의해 구문 분석되어 올바른 문법인지 확인하고, 내부적인 구문 트리 구조로 변환된다. 이후 쿼리 최적화기가 이 구문 트리를 분석하여 가장 효율적인 실행 계획을 수립한다. 최적화기는 사용 가능한 인덱스를 평가하고, 조인 순서를 결정하며, 불필요한 조건을 제거하는 등의 작업을 수행한다. 최종 선택된 실행 계획은 실행 엔진에 전달된다.

실행 엔진은 계획에 따라 스토리지 엔진에 데이터 접근을 요청하고 결과를 처리한다. MariaDB는 플러그인 기반의 스토리지 엔진 아키텍처를 채택하고 있어, 실행 엔진은 InnoDB, Aria, MyISAM 등 테이블에 지정된 특정 스토리지 엔진의 API를 호출하여 실제 데이터 읽기/쓰기 작업을 수행한다. 처리된 결과는 네트워크 버퍼를 거쳐 최종적으로 클라이언트에게 반환된다.

이 과정 전반에 걸쳐 쿼리 캐시 (10.3 이전 버전)나 성능 스키마 같은 부가적인 모듈이 성능 향상이나 모니터링에 기여하기도 한다.

MariaDB를 설치하기 위한 시스템 요구사항은 운영 체제, 하드웨어 사양, 필요한 소프트웨어 의존성으로 구분된다. 요구사항은 설치할 버전, 예상되는 워크로드, 그리고 사용할 기능에 따라 달라질 수 있다.

일반적으로 MariaDB는 리눅스, 윈도우, macOS를 포함한 주요 운영 체제를 지원한다. 하드웨어 측면에서는 최소 1GB의 RAM과 500MB 이상의 디스크 여유 공간이 권장되지만, 대규모 데이터베이스를 운영할 경우 더 많은 메모리와 저장 공간이 필요하다. CPU는 최신 64비트 아키텍처를 권장하며, 특히 InnoDB 스토리지 엔진을 사용할 때는 다중 코어 프로세서가 성능에 유리하다.

필수적인 소프트웨어 의존성으로는 해당 운영 체제의 기본 개발 도구(예: gcc, make)와 라이브러리(예: libc, openssl)가 포함된다. 패키지 관리자를 통한 설치 시 대부분의 의존성이 자동으로 해결된다. 네트워크 포트(기본값 3306)가 열려 있어야 원격 접속이 가능하며, 방화벽 설정이 필요할 수 있다. 특정 기능(예: GIS 지원, 연결 풀링을 위한 MariaDB MaxScale)을 사용하려면 추가 패키지나 구성이 필요하다.

초기 구성은 MariaDB 서버를 설치한 후, 보안 강화와 기본 운영 환경을 설정하는 과정을 가리킨다. 이 단계는 주로 `mysql_secure_installation` 스크립트 실행과 주요 설정 파일인 `my.cnf`(또는 `my.ini`)의 편집을 통해 이루어진다.

`mysql_secure_installation` 스크립트는 대화형 방식으로 다음과 같은 보안 관련 초기 설정을 안내한다.

• 익명 사용자 제거: 기본적으로 생성될 수 있는 테스트용 익명 계정을 삭제하여 보안을 강화한다.

• 원격 루트 로그인 비활성화: 루트 계정의 원격 접속을 차단하고 로컬 호스트에서만 접속할 수 있도록 제한한다.

• 테스트 데이터베이스 제거: 설치 시 함께 생성되는 'test' 데이터베이스 및 관련 접근 권한을 제거한다.

• 루트 패스워드 재설정: 초기 설치 시 비밀번호가 설정되지 않은 루트 계정의 패스워드를 강력한 비밀번호로 변경한다.

핵심 설정 파일인 `my.cnf`의 편집을 통해 서버의 기본 동작을 정의한다. 초기 구성 시 주로 확인하거나 수정하는 항목은 다음과 같다.

설정 파일 변경 후에는 항상 MariaDB 서비스(`mariadb` 또는 `mysqld`)를 재시작하여 변경 사항을 적용해야 한다. 초기 구성이 완료되면, 애플리케이션에 필요한 추가 데이터베이스와 사용자 계정을 생성하고 권한을 부여하는 작업으로 이어진다.

MariaDB는 데이터의 안전성을 보장하기 위해 다양한 백업 및 복구 방법을 제공합니다. 가장 기본적인 방법은 mysqldump 유틸리티를 사용하는 논리적 백업이다. 이 도구는 데이터베이스의 구조와 데이터를 SQL 문으로 된 덤프 파일로 내보낸다. 이 파일은 다른 MariaDB 서버나 MySQL 서버로 쉽게 이전하거나 특정 시점으로 복구하는 데 사용할 수 있다. 또한 `mariadb-dump`는 단일 데이터베이스, 특정 테이블, 또는 전체 서버를 백업하는 옵션을 지원한다.

보다 고성능이고 대규모 데이터베이스를 위한 물리적 백업 방법도 있다. Percona XtraBackup은 InnoDB 및 XtraDB 스토리지 엔진을 사용하는 데이터베이스에 대해 핫 백업(서비스 중단 없이 백업)을 수행할 수 있는 오픈 소스 도구이다. MariaDB Backup은 MariaDB 10.1 이상에 포함된 공식 백업 도구로, 증분 백업과 압축 백업을 지원하여 저장 공간과 시간을 절약한다.

복구 절차는 선택한 백업 방법에 따라 달라진다. mysqldump로 생성된 파일은 mysql 클라이언트나 `mariadb` 명령어를 사용하여 임포트한다. 물리적 백업의 경우, 백업 파일을 데이터 디렉토리에 복원한 후 트랜잭션 로그를 적용하여 일관된 상태로 만드는 과정이 필요하다. 정기적인 백업 테스트는 실제 재해 상황에서 복구가 제대로 이루어지는지 확인하는 필수 절차이다.

이진 로그를 활성화하면 시점 복구가 가능해진다. 이는 특정 시간대의 잘못된 DROP TABLE 문이나 데이터 손상 사고 후, 최신 전체 백업부터 문제가 발생하기 직전의 시점까지 로그를 재실행하여 데이터를 복구하는 기술이다. 백업 전략은 복구 목표 시점과 복구 목표 시간에 기반하여 수립해야 한다.

MariaDB는 데이터베이스의 상태와 성능을 효과적으로 추적하고 관리할 수 있도록 다양한 모니터링 도구와 방법을 제공한다. 내장된 시스템 테이블과 뷰, 명령줄 유틸리티, 그래픽 인터페이스 도구를 조합하여 사용한다.

주요 모니터링 수단으로는 `SHOW STATUS`, `SHOW PROCESSLIST`, `SHOW ENGINE INNODB STATUS`와 같은 SQL 명령어가 있다. 또한, `INFORMATION_SCHEMA` 데이터베이스와 `PERFORMANCE_SCHEMA`를 통해 상세한 서버 상태 정보를 쿼리할 수 있다. 성능 분석을 위해 `EXPLAIN` 명령어로 쿼리 실행 계획을 확인하고 최적화할 수 있다. 명령줄에서는 `mytop`이나 `innotop`과 같은 터미널 기반 모니터링 도구를 활용할 수 있다.

그래픽 사용자 인터페이스(GUI) 도구로는 공식적인 웹 기반 관리 도구인 phpMyAdmin이 널리 사용된다. 또한, MySQL Workbench도 MariaDB와의 호환성을 통해 서버 상태 모니터링, 성능 대시보드, 사용자 관리 등의 기능을 제공한다. 전문 모니터링 시스템과의 통합을 위해 Prometheus용 익스포터나 Zabbix 템플릿과 같은 에이전트를 사용하여 메트릭을 수집하고 시각화할 수 있다.

MariaDB와 MySQL은 공통의 뿌리를 공유하지만, 오라클이 MySQL을 인수한 이후 개발 방향이 달라지면서 여러 기능적 차이점이 발생했다. 주요 차이점은 새로운 스토리지 엔진 도입, 성능 최적화, 그리고 몇몇 고급 기능의 포함 여부에 있다.

가장 두드러진 차이점 중 하나는 사용 가능한 스토리지 엔진이다. MariaDB는 InnoDB의 대체제이자 성능 향상 버전으로 개발된 Aria 스토리지 엔진을 기본으로 포함한다. 또한, ColumnStore 엔진을 통해 대규모 데이터 웨어하우징과 분석 작업을 지원한다. 반면, MySQL은 여전히 InnoDB를 기본 스토리지 엔진으로 사용하며, 이러한 특화 엔진들을 기본으로 제공하지 않는다. 성능 측면에서 MariaDB는 쿼리 최적화와 실행 속도를 개선한 여러 기능을 도입했다. 예를 들어, 더 빠른 복제를 위한 병렬 복제 기능과 복잡한 조인 쿼리 성능을 향상시키는 윈도우 함수의 조기 지원이 대표적이다. 또한, 동적 컬럼 기능을 통해 하나의 테이블에 반정형 데이터를 저장할 수 있는 유연성을 제공한다.

보안과 관리 측면에서도 차이가 존재한다. MariaDB는 데이터 암호화를 위한 더 많은 선택지를 제공하며, 롤 기반 접근 제어와 같은 세분화된 권한 관리 기능을 포함한다. 또한, 서버 상태 모니터링을 위한 확장된 성능 스키마 메트릭과 진단 도구를 제공한다. 이러한 기능적 차이에도 불구하고, MariaDB는 MySQL과의 높은 수준의 호환성을 유지하는 것을 핵심 목표로 삼고 있다. 대부분의 MySQL 데이터 파일, 클라이언트 프로토콜, API 및 명령어가 MariaDB에서 그대로 작동하도록 설계되었다[8].

MariaDB는 MySQL의 포크로 시작했기 때문에 높은 수준의 하위 호환성을 유지하는 것을 주요 목표로 삼았다. 초기 버전부터 MySQL의 API와 프로토콜을 그대로 지원하여, 대부분의 경우 MySQL 클라이언트 라이브러리, 커넥터, 애플리케이션 코드를 수정 없이 MariaDB와 함께 사용할 수 있다. 데이터 파일 형식과 클라이언트/서버 프로토콜도 호환되도록 설계되었다[9].

그러나 시간이 지남에 따라 MariaDB는 독자적인 발전을 거치며 몇 가지 비호환성 요소를 도입했다. 주요 차이점은 새로운 기능, 향상된 성능을 위한 최적화, 그리고 제거된 MySQL의 일부 기능에서 나타난다. 예를 들어, 일부 MySQL 전용 스토리지 엔진은 MariaDB에 포함되지 않거나 대체 엔진으로 제공된다. 또한, 특정 시스템 변수 이름, 상태 변수, 또는 SQL 문법 확장 영역에서 차이가 발생할 수 있다.

애플리케이션을 MySQL에서 MariaDB로 마이그레이션할 때는 대체로 원활하게 진행되지만, 공식 호환성 매트릭스를 참고하고, 특정 기능에 대한 의존성을 테스트하는 것이 권장된다. MariaDB는 `mysql` 클라이언트와 동일한 이름의 클라이언트 도구를 제공하며, 시스템 데이터베이스 이름(`mysql`)과 구조도 유사하게 유지하여 관리자의 학습 곡선을 낮추었다.