인스턴트 ADD COLUMN, FULLTEXT 인덱스가 나타날 때까지: MariaDB 마이그레이션 중 발생한 쓰기 중단

(dev.to)

MariaDB와 MySQL에서 FULLTEXT 인덱스가 포함된 테이블에 컬럼을 추가할 때 발생하는 예기치 않은 쓰기 중단 현상의 원인을 분석하고, 서비스 중단을 방지하기 위한 효율적인 데이터베이스 마이그레이션 전략을 제시합니다.

이 글의 핵심 포인트

1MariaDB 10.3+ 및 MySQL 8.0+에서 컬럼 추가는 일반적으로 'Instant' 작업이지만, FULLTEXT 인덱스가 있으면 제외됨
2FULLTEXT 인덱스가 있는 테이블에 컬럼을 추가하면 테이블 재구축과 함께 쓰기 잠금(Shared Lock)이 발생함
3테이블 재구축 중에는 모든 쓰기 작업(UPDATE 등)이 대기 상태에 빠져 서비스 지연을 유발함
4여러 개의 ALTER TABLE 문을 개별적으로 실행하면 각 문장마다 테이블 재구축이 발생하여 장애 시간이 길어짐
5여러 컬럼 추가를 하나의 ALTER TABLE 문으로 통합하여 실행하는 것이 재구축 횟수를 줄이는 핵심 해결책임

이 글에 대한 공공지능 분석

왜 중요한가?

데이터베이스 스키마 변경이 단순한 메타데이터 수정을 넘어 서비스 전체의 가용성을 위협하는 '쓰기 중단'으로 이어질 수 있음을 보여줍니다. 특히 대규모 트래픽을 처리하는 서비스에서 마이그레이션 중 발생하는 잠금(Lock)은 곧 서비스 장애와 직결됩니다.

어떤 배경과 맥락이 있나?

최신 MariaDB와 MySQL은 컬럼 추가 시 데이터 복사 없이 메타데이터만 변경하는 'Instant' 알고리즘을 지원하지만, FULLTEXT 인덱스처럼 보조 테이블과 연동된 구조는 이 알고리즘에서 제외되어 테이블 재구축이 강제됩니다.

업계에 어떤 영향을 주나?

개발 환경(소규모 데이터)과 운영 환경(대규모 데이터)의 차이로 인해 발생할 수 있는 '보이지 않는 위험'을 경고합니다. 이는 DevOps 및 데이터베이스 운영 프로세스에서 마이그레이션 전략의 정교함이 필수적임을 시사합니다.

한국 시장에 어떤 시사점이 있나?

빠른 기능 출시를 중시하는 한국 스타트업 환경에서, 무심코 실행한 DB 마이그레이션이 사용자 경험을 해치는 치명적인 장애로 이어질 수 있습니다. 따라서 배포 전 반드시 대용량 데이터셋 기반의 부하 테스트와 쿼리 실행 계획 검토가 병행되어야 합니다.

이 글에 대한 큐레이터 의견

이번 사례는 '개발 환경에서는 잘 작동하던 코드가 왜 운영 환경에서 장애를 일으키는가'라는 고전적인 문제를 DB 엔진의 내부 동작 원리 관점에서 잘 보여줍니다. 개발자는 단순히 기능 구현에 그치지 않고, 사용 중인 DB 엔진의 특정 인덱스 구조가 마이그레이션 알고리즘에 어떤 영향을 미치는지 깊이 있게 이해해야 합니다.

물론, 모든 마이그레이션을 'Instant'로 만들 수 없다는 점은 기술적 한계입니다. FULLTEXT 인덱스의 특성상 재구축이 불가피하다면, 무조건적인 방어보다는 서비스 점검 시간을 활용하거나 블루-그린 배포와 같은 인프라적 접근을 통해 리스크를 관리하는 트레이드오프를 고려해야 합니다. 스타트업 창업자라면 개발팀이 이러한 '엣지 케이스'를 인지하고 있는지 확인하고, 데이터 규모 확장에 따른 인프라 리스크 관리 프로세스를 구축하도록 독려해야 합니다.

원문 보기 →