들어가며
MariaDB는 데이터베이스 관리와 운영 효율성을 높이기 위한 다양한 기능들을 지속적으로 도입하고 있다. 그 중 MariaDB 11.4 버전에서 새롭게 소개된 Online Schema Change(이하 OSC) 기능은 실시간 서비스 환경에서 스키마 변경을 서비스 중단 없이 안전하게 수행할 수 있다는 점에서 주목할 만하다. OSC는 기존 Online DDL 방식에서 ALTER TABLE 명령문의 ALGORITM=COPY 옵션을 사용할 때 발생하던 서비스 중단 문제를 개선한 기능이다. 본 Insight Report에서는 OSC의 개념과 동작 원리를 설명하고 테스트 결과 및 주의사항에 대하여 쉽게 풀어보고자 한다.
기존 Online DDL 방식
OSC 기능을 이해하기 위해 먼저 MariaDB의 기존 Online DDL 방식을 간략히 살펴보겠다.
Online DDL은 DDL 수행 시에도 동시 DML을 허용하며 불필요한 테이블 복사를 최소화하는 기능으로 ALTER TABLE 명령문에서 ALGORITHM 옵션으로 작업 방식을 지정하고 LOCK 옵션으로 동시성 수준을 제어하는 방식으로 동작한다.
Online DDL에서 지원하는 ALGORITHM 및 LOCK 옵션은 아래와 같다.


이처럼 기존에도 상황에 따라 ALGORITHM과 LOCK 옵션을 조합하여 ALTER TABLE 명령문의 동시성 수준을 제어할 수 있었다.
그러나 테이블 복제가 필요한 경우(예: 기존 컬럼의 데이터 유형을 변경)는 ALGORITHM=COPY 방식만 가능하며 이 경우 반드시 LOCK=SHARED를 사용해야 했기 때문에 아래 그림과 같이 서비스 중 DML이 차단되어 사실상 온라인 변경이 불가능한 제약이 존재했다.

MariaDB Online Schema Change(OSC)란?
Online Schema Change(이하 OSC)는 기존 Online DDL에서 ALGORITHM=COPY 방식을 사용하는 경우에도 LOCK=NONE 설정을 지원하도록 개선한 기능이다. OSC 방식은 아래 그림과 같이 ALTER TABLE 명령문 수행 중에도 DML이 차단 되지 않는다.

Online Schema Change(OSC)의 동작 방식
OSC의 내부 프로세스는 다음과 같은 단계로 이루어진다.

■ 동작 방식
① 새 테이블 생성
기존 테이블의 스키마에 기반하여 동일한 구조의 새로운 테이블을 생성한다. 이때 수정이 필요한 부분 (예: 컬럼 추가, 데이터 타입 변경 등)을 반영한다.
② 초기 데이터 복사
기존 테이블의 모든 데이터를 새 테이블로 복사한다. 복사 과정은 백그라운드에서 비동기로 이루어지며, 기존 테이블에 대한 읽기/쓰기 작업은 계속해서 허용 된다.
③ 동시 DML 처리
복사 도중 발생하는 DML(INSERT, UPDATE, DELETE) 작업은 Online change buffer에 임시 저장 된다.
④ 변경 사항 적용
Online change buffer에 저장된 변경 사항을 새 테이블에 순차적으로 적용하여, 두 테이블 간 데이터 일관성을 맞춘다.
⑤ 테이블 교체
모든 변경 사항이 적용되면 기존 테이블과 새 테이블을 교체한다.
Online Schema Change(OSC)의 특징
OSC 기능은 다음과 같은 특징을 가지고 있다.
■ Non-blocking 스키마 변경
ALTER TABLE 수행 중에도 기존 데이터를 계속해서 읽고 쓸 수 있으며, 스키마 변경은 백그라운드에서 진행된다. 이를 통해 서비스 운영 중에도 스키마 수정이 가능하다.
■ 대체 메커니즘 활용
내부적으로 새로운 테이블을 생성한 후 기존 테이블의 데이터를 복사하고 동시에 발생하는 DML을 별도의 Online change buffer에 저장한다. 이후 복사가 완료되면 새로운 테이블과 버퍼의 변경사항을 병합한다.
■ 트리거 미사용 구조
OSC 기능은 스키마 변경 중 발생하는 DML을 처리하기 위해 트리거(trigger)를 사용하지 않는다. 이는 INSERT, UPDATE, DELETE 트리거를 사용하는 타사(3rd party) 도구와 차별화 된 점이다.
■ 자동 전환
ALTER TABLE 수행 시 알고리즘을 DEFAULT로 선택한 경우, NOCOPY를 적용할 수 없으면 OSC가 자동으로 활성화 된다.
■ 사용자 제어 옵션
사용자는 아래 표와 같이 제어 할 수 있다.

이러한 특징들은 트리거를 활용한 방식 (3rd party 도구 또는 수동으로 처리) 보다 더 간편하고 안전하게 ALTER TABLE 명령문을 수행할 수 있다.
기존 Online DDL 방식과 Online Schema Change(OSC)의 LOCK 범위 비교
기존 Online DDL 방식은 ALGORITHM=COPY, LOCK=SHARED 옵션을 의미하며 ALTER TABLE 명령문이 수행되는 동안 아래의 연두색 영역과 같이 전체에 걸쳐 DML이 차단된다.

OSC 기능의 경우 아래와 같이 Online change buffer를 사용하여 ALTER TABLE이 진행될 때 동시 DML이 가능하다. 위에서 설명한 동작 방식 중 ④변경사항 적용, ⑤테이블 교체에 해당하는 부분에서는 일시적으로 DML이 차단되지만 일반적으로 기존의 방식 보다는 훨씬 적은 시간임을 알 수 있다.
Online Schema Change(OSC) 동작 및 부하 수준에 따른 영향도 비교
OSC의 이점은 적용 사례에 따라 달라질 수 있다. 이를 비교하기 위해 OSC 동작 및 부하 수준에 따라 아래 네 가지 케이스로 나누어 영향도 비교 테스트를 수행하였다.

공통적으로 한 세션에서는 약 10,000,000행(데이터파일 크기 약 2.3G)의 테이블에 컬럼의 데이터 타입을 변경하는 ALTER TABLE 명령문을 수행하고 다른 세션에서는 다중 스레드 벤치마크 도구인 sysbench를 사용하여 DML(INSERT/UPDATE/DELETE)을 포함한 OLTP 부하를 실행하였다. 이를 통해 ALTER TABLE 구문의 수행 시간과 스키마 변경 중 Metadata lock으로 인해 DML 대기가 발생하는 시간을 비교하였다.
사용한 버전은 MariaDB Enterprise Server 11.4.7 이며 그 외 테스트 환경은 다음과 같다.

ALTER TABLE 명령어는 다음 구문을 기준으로 수행하였다.
| ALTER TABLE sbtest1 CHANGE COLUMN c c VARCHAR(120), ALGORITHM=#####, LOCK=#####; |
■ CASE 1 – 기존 Online DDL 방식, 높은 부하 상황


■ CASE 2 – OSC 방식, 높은 부하 상황

■ CASE 3 – OSC 방식, 중간 부하 상황


■ CASE 4 – OSC 방식, 낮은 부하 상황

■ 동작 방식 및 부하 수준에 따른 비교

OSC 기능을 사용할 경우 [CASE 4]와 같이 부하가 낮은 상황에서는 서비스가 온라인 상태를 유지하면서 빠르게 스키마 변경을 수행할 수 있음을 확인하였다. 이는 기존 Online DDL을 사용한 방식인 [CASE 1]과 ALTER TABLE 수행 시간이 거의 동일한 반면 Metadata lock에 의한 대기는 발생하지 않아 OSC의 장점이 가장 극대화 되었다. 반면 [CASE 2]와 같이 초당 DML 발생량이 많은 경우에는 OSC 기능을 사용하더라도 후반부에 metadata lock으로 인한 DML 대기 현상이 발생하여 서비스 중단을 발생 시킬 수 있을 것으로 보인다.
결론적으로 OSC 기능은 서비스 부하가 적은 시간대에 수행할수록 빠르고 안정적으로 처리 된다. ALTER TABLE 수행 시간과 Metadata lock에 의한 대기 시간은 스키마 변경 구문 및 부하 패턴에 따라 달라질 수 있으므로 운영 환경에 적용하기 전 유사한 조건에서 사전 테스트와 부하 검토를 통해 적절한 수행 시점을 선정하면 보다 안정적으로 반영할 수 있을 것이다.
제약 사항
OSC 기능은 스토리지 엔진과 작업 유형에서 제한이 있다.
■ 스토리지 엔진 별 지원 여부

■ 제한되는 작업 유형
AUTO_INCREMENT 컬럼 추가, ALTER IGNORE TABLE, SYSTEM VERSIONING 해제, 외래 키의 CASCADE/SET NULL/SET DEFAULT 옵션 및 ORDER BY 절 사용 시 등에 제한이 있다.
자세한 내용은 MariaDB 공식 매뉴얼의 “Online schema change Limitations” 문서를 참고해야 한다.
마치며
MariaDB의 Online Schema Change(OSC) 기능은 기존 Online DDL의 제약을 개선하여 서비스 중단 없이 스키마를 변경할 수 있도록 설계 된 기능이다. OSC 기능은 Online change buffer 메커니즘을 활용하여 Lock으로 인한 서비스 중단을 최소화하고 스키마 변경 작업을 보다 안정적이고 빠르게 수행하도록 한다. 이를 통해 서비스 연속성을 확보할 수 있을 뿐만 아니라 개발자들의 스키마 변경 요청에 더 민첩한 대응이 가능하여 어플리케이션 개발 측면에서도 도움이 될 것으로 보인다. 앞으로도 OSC와 같은 기능 개선을 통해 MariaDB가 더욱 효율적이고 유연한 운영 및 개발 환경을 제공할 수 있기를 기대한다.
# References
- https://mariadb.com/docs/release-notes/community-server/mariadb-11-4-series/what-is-mariadb-114#online-schema-change
- https://mariadb.com/docs/release-notes/enterprise-server/11.4/whats-new#operational-enhancements
- https://mariadb.com/docs/release-notes/enterprise-server/11.4/11.4.4-2#operational-enhancements
- https://mariadb.com/docs/release-notes/enterprise-server/11-4/release-notes-for-mariadb-enterprise-server-11-4-4-2
- https://mariadb.com/docs/server/reference/sql-statements/data-definition/alter/alter-table/online-schema-change
- https://mariadb.com/resources/blog/alter-table-is-now-universally-online/
- https://mariadb.com/resources/blog/reduced-operational-downtime-with-new-alter-table-features/
- https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-online-ddl
- https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-online-ddl/innodb-online-ddl-operations-with-the-instant-alter-algorithm
- https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-online-ddl/innodb-online-ddl-operations-with-the-nocopy-alter-algorithm
- https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-online-ddl/innodb-online-ddl-operations-with-the-inplace-alter-algorithm
- https://jira.mariadb.org/browse/MDEV-13134
- https://jira.mariadb.org/browse/MDEV-16329
- https://jira.mariadb.org/browse/MDEV-31812
김환희 프로
오픈소스사업부 오픈소스솔루션사업팀
에스코어에서 오픈소스 DB와 관련된 전문가로 삼성 계열사 및 국내 주요 대기업을 대상으로 기술지원 업무를 하고 있습니다.
Register for Download Contents
- 이메일 주소를 제출해 주시면 콘텐츠를 다운로드 받을 수 있으며, 자동으로 뉴스레터 신청 서비스에 가입됩니다.
개인정보 수닙 및 활용에 동의하지 않으실 경우 콘텐츠 다운로드 서비스가 제한될 수 있습니다.
파일 다운로드가 되지 않을 경우 s-core@samsung.com으로 문의 주십시오.




