대용량 DB 스키마 변경의 병목 원인
대용량 데이터베이스 환경에서 스키마를 변경할 때 서비스 중단을 유발하는 주된 원인은 데이터 복사에 소요되는 시간이 아닙니다. 실제 병목 현상은 메타데이터 락(MDL) 대기 큐에서 발생합니다.
ALTER 구문이 배타적 락을 요청할 때, 앞선 긴 트랜잭션이 존재하면 락 대기가 시작됩니다. 이때 락 큐가 선착순으로 처리되기 때문에 뒤이어 들어오는 단순 조회 쿼리들까지 모두 대기 상태에 빠지게 됩니다. 이로 인해 커넥션 풀이 빠르게 고갈되면서 서비스 전체가 지연되는 문제가 발생할 수 있습니다.
gh-ost 도구와 바이너리 로그 방식의 이점
이러한 문제를 해결하기 위해 실무에서는 gh-ost와 같은 도구를 사용하여 별도의 임시 테이블을 생성하고 비동기 복제를 수행하는 방식을 활용합니다. 특히 원본 테이블의 트랜잭션 부하를 최소화해야 하는 경우, 트리거 방식보다 바이너리 로그(binlog) 방식을 선택하는 것이 유리합니다.
트리거 방식은 쓰기 요청이 발생할 때마다 락 경합이 증가할 가능성이 있지만, 바이너리 로그 방식은 이미 기록된 변경 사항을 애플리케이션 외부에서 읽어오는 구조입니다. 따라서 원본 테이블의 부하를 거의 발생시키지 않으면서 교체 시점에 필요한 최소한의 락 시간만을 확보할 수 있습니다.
안전한 스키마 변경을 위한 핵심 원칙
안전한 스키마 변경의 핵심은 작업의 속도 자체가 아니라, 기존 쿼리의 락 큐를 건드리지 않는 격리력을 확보하는 데 있습니다. 운영 중인 데이터베이스 환경이나 사용하는 온라인 DDL 도구의 설정값에 따라 락 병목 발생 여부와 정도는 달라질 수 있으므로, 기존 서비스 쿼리에 영향을 주지 않는 격리된 방식의 도구 사용이 필수적입니다.