데이터베이스 스키마 변경 및 락 병목 관리

개요\n\n대용량 데이터베이스 운영 환경에서 스키마 변경(Schema Change)은 서비스 가용성에 직접적인 영향을 미치는 고위험 작업입니다. 특히 전통적인 ALTER TABLE 구문은 메타데이터 락(Metadata Lock, MDL)을 유발하여 서비스 전체의 지연을 초래할 수 있습니다. 본 문서에서는 MDL 병목 현상의 원인과 이를 해결하기 위한 온라인 DDL 도구 활용 전략을 설명합니다.\n\n## 메타데이터 락(MDL) 병목 현상\n\n대용량 데이터베이스에서 스키마 변경 시 서비스 중단을 유발하는 주된 원인은 데이터 복사 시간이 아닌, 메타데이터 락(MDL) 대기 큐입니다.\n\n* 락 대기 메커니즘: ALTER 구문이 배타적 락을 요청할 때, 실행 중인 긴 트랜잭션이 존재하면 락 대기가 시작됩니다.\n* 병목 확산: 락 큐는 선착순으로 처리되므로, ALTER 구문 뒤에 들어오는 단순 조회 쿼리들까지 모두 대기 상태에 빠지게 됩니다.\n* 결과: 커넥션 풀이 빠르게 고갈되어 서비스 전체가 지연되거나 중단되는 현상이 발생합니다.\n\n## 해결 전략: 온라인 DDL 도구\n\n이러한 문제를 해결하기 위해 실무에서는 gh-ost와 같은 온라인 DDL 도구를 활용하여 원본 테이블에 직접적인 영향을 주지 않는 방식을 채택합니다.\n\n### 트리거 방식 vs 바이너리 로그(binlog) 방식\n* 트리거 방식: 쓰기 요청 시마다 락 경합이 증가할 가능성이 있어 부하가 발생할 수 있습니다.\n* 바이너리 로그(binlog) 방식: 애플리케이션 외부에서 변경 사항을 읽어오는 구조로, 원본 테이블의 부하를 최소화합니다. 교체 시점에만 최소한의 락을 확보하므로 서비스 영향도가 매우 낮습니다.\n\n## 안전한 스키마 변경을 위한 실무 원칙\n\n안전한 스키마 변경의 핵심은 작업 속도보다 '기존 쿼리의 락 큐를 건드리지 않는 격리력'을 확보하는 것입니다.\n\n1. 격리된 도구 사용: 운영 중인 환경에 적합한 온라인 DDL 도구를 선정합니다.\n2. 설정값 최적화: 사용하는 도구의 설정값에 따라 락 발생 여부가 달라지므로 사전 테스트가 필수입니다.\n3. 부하 모니터링: 작업 수행 중 데이터베이스의 커넥션 상태와 락 대기 현상을 실시간으로 모니터링합니다.\n\n## 주의사항 및 한계\n\n* 모든 온라인 DDL 도구가 완벽한 무중단을 보장하지는 않습니다.\n* 데이터베이스 버전 및 엔진 설정에 따라 지원하는 기능이 다를 수 있습니다.\n* 작업 전 반드시 스테이징 환경에서 충분한 테스트를 거쳐야 합니다.