MySQL 8.4 ONLINE DDL이 LOCK=NONE인데 멈출 때: metadata lock 차단 세션 찾는 순서

MySQL 8.4에서 ALTER TABLE ... LOCK=NONE을 실행했는데도 명령이 시작하지 않거나 마지막에 멈춘 듯 보이면, 먼저 메타데이터 락(MDL)을 의심해야 합니다. LOCK=NONE은 해당 InnoDB 작업 중 읽기와 쓰기를 허용하겠다는 요청이지, DDL이 테이블 정의를 바꾸기 위해 필요한 메타데이터 락까지 없앤다는 뜻은 아닙니다.

이 글은 InnoDB 테이블에서 온라인 DDL을 배포할 때, 대기 중인 ALTER TABLE과 이를 막는 세션을 찾고, 섣불리 세션을 끊지 않고 안전하게 다음 행동을 정하는 방법을 다룹니다. 예시는 MySQL 8.4 기준이며, 운영 서버에서 실행 전에는 권한과 배포 중단 기준을 확인해야 합니다.

적용 범위와 먼저 볼 것

왜 LOCK=NONE인데 대기하는가

InnoDB 온라인 DDL은 테이블을 항상 완전히 잠그지 않고 변경하려는 기능입니다. 예를 들어 보조 인덱스를 추가하는 일부 작업은 in-place 방식으로 수행하면서 동시 DML을 허용합니다. 이때 LOCK=NONE을 붙이면 읽기와 쓰기를 막지 않는 수준의 동시성을 MySQL에 요구합니다. 요청한 수준을 지원하지 않는 작업이면 조용히 더 강한 락으로 바꾸는 대신 오류로 멈춥니다.

하지만 SQL 문이 테이블 정의를 변경하려면 서버가 다른 세션과 정의 변경 순서를 맞춰야 합니다. 이 조정에 쓰는 것이 MDL입니다. 세션 A가 테이블을 읽고 트랜잭션을 오래 열어 둔 상태라면, 세션 B의 DDL은 필요한 MDL을 얻을 때까지 기다릴 수 있습니다. DDL이 줄의 앞에 서면 이후에 같은 테이블을 열려는 세션도 함께 밀릴 수 있어, 단순히 DDL 하나가 느린 문제로 끝나지 않을 수 있습니다.

온라인 DDL에는 시작과 완료 직전에 짧은 배타적 락이 필요할 수 있습니다. 공식 문서도 이 대기 때문에 타임아웃이 발생할 수 있다고 설명합니다. 따라서 LOCK=NONE은 배포 계획을 세우는 좋은 안전장치이지만, 장기 트랜잭션·커넥션 풀의 미종료 세션·긴 조회를 대신 관리해 주지는 않습니다.

최소 재현: 열린 트랜잭션 뒤에서 ALTER TABLE이 기다리는 모습

아래는 테스트 전용 예시입니다. 터미널을 두 개 열어 세션 A와 세션 B에서 나누어 실행합니다. 실제 운영 테이블과 이름이 겹치지 않는 별도 스키마를 사용하십시오.

CREATE DATABASE IF NOT EXISTS ddl_lab;
USE ddl_lab;

CREATE TABLE orders (
  order_id BIGINT NOT NULL,
  customer_id BIGINT NOT NULL,
  ordered_at DATETIME NOT NULL,
  status VARCHAR(20) NOT NULL,
  PRIMARY KEY (order_id)
) ENGINE=InnoDB;

INSERT INTO orders (order_id, customer_id, ordered_at, status)
VALUES (1, 101, NOW(), 'PAID');

세션 A에서는 행을 읽은 뒤 커밋하지 않습니다. 행 자체를 수정하지 않아도, 트랜잭션 안에서 테이블을 참조한 상태가 DDL과 충돌하는지 확인하는 재현 재료가 됩니다.

USE ddl_lab;
START TRANSACTION;

SELECT order_id, customer_id, ordered_at, status
FROM orders
WHERE order_id = 1;

-- 이 세션은 COMMIT 또는 ROLLBACK 전까지 열어 둡니다.

세션 B에서 인덱스를 추가합니다. ALGORITHM=INPLACE, LOCK=NONE은 이 예제 작업이 요청한 온라인 방식으로 불가능하면 강한 락으로 전환하지 않고 실패하도록 만듭니다.

USE ddl_lab;

ALTER TABLE orders
  ADD INDEX ix_orders_customer_ordered (customer_id, ordered_at),
  ALGORITHM=INPLACE,
  LOCK=NONE;

대기와 차단 세션을 찾는 순서

가장 짧은 출발점은 sys 스키마의 schema_table_lock_waits 뷰입니다. 이 뷰는 메타데이터 락을 기다리는 세션과 이를 막는 세션을 함께 보여 줍니다. 애플리케이션 로그의 커넥션 ID나 배포 도구의 PID와 연결하기도 쉽습니다.

SELECT
  object_schema,
  object_name,
  waiting_pid,
  waiting_query,
  blocking_pid,
  blocking_account,
  blocking_query
FROM sys.schema_table_lock_waits
WHERE object_schema = 'ddl_lab'
  AND object_name = 'orders';

이 결과에서 중요한 것은 대기 PID가 아니라 차단 PID의 성격입니다. 차단 쿼리가 긴 SELECT인지, 아직 커밋하지 않은 쓰기 트랜잭션인지, 백업·관리 작업인지 구분해야 합니다. 같은 PID의 상세 상태를 볼 때는 필요한 열만 조회합니다.

SELECT
  p.ID,
  p.USER,
  p.HOST,
  p.DB,
  p.COMMAND,
  p.TIME,
  p.STATE,
  p.INFO
FROM information_schema.PROCESSLIST AS p
WHERE p.ID IN (/* waiting_pid, blocking_pid를 숫자로 넣습니다 */);

sys 뷰가 비어 있거나 더 낮은 수준의 확인이 필요할 때

Performance Schema의 metadata_locks에는 held·requested 메타데이터 락 정보가 있습니다. 다만 이 테이블을 직접 조인해 차단 관계를 추정하는 SQL은 MySQL 버전·관측 설정에 따라 읽기 어렵고 실수하기 쉽습니다. 먼저 sys 뷰를 사용하고, 결과가 비어 있는데 DDL이 계속 기다린다면 Performance Schema가 켜져 있는지와 메타데이터 락 관측 한도를 DBA와 확인하는 편이 안전합니다.

SELECT
  OBJECT_TYPE,
  OBJECT_SCHEMA,
  OBJECT_NAME,
  LOCK_TYPE,
  LOCK_DURATION,
  LOCK_STATUS,
  OWNER_THREAD_ID
FROM performance_schema.metadata_locks
WHERE OBJECT_SCHEMA = 'ddl_lab'
  AND OBJECT_NAME = 'orders'
ORDER BY OWNER_THREAD_ID, LOCK_STATUS;

작업 전·후 검증표

SELECT
  INDEX_NAME,
  SEQ_IN_INDEX,
  COLUMN_NAME,
  NON_UNIQUE
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'ddl_lab'
  AND TABLE_NAME = 'orders'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

세션 종료는 마지막 수단으로 둔다

차단 세션이 명백히 종료되어야 할 유휴 작업이고, 업무 소유자가 종료를 승인했으며, 롤백 시간과 애플리케이션 영향까지 확인한 경우에만 세션 종료를 검토합니다. 특히 쓰기 트랜잭션을 끊으면 InnoDB가 롤백을 수행하며, 이 시간이 DDL 대기보다 길어질 수 있습니다. 커넥션 풀은 끊긴 세션을 다시 만들 수 있으므로 애플리케이션 쪽의 재시도·오류 처리도 함께 봐야 합니다.

대기 중인 DDL을 취소해야 한다면, 배포 도구가 제공하는 취소 절차를 먼저 사용하고 현재 상태를 다시 조회합니다. DDL이 실패했다고 해서 인덱스나 테이블 정의가 항상 같은 상태로 남는 것은 아닙니다. 인덱스 추가 작업이 끝까지 가지 못했을 때는 재시도 전에 information_schema.STATISTICS로 실제 정의를 확인합니다.

자주 하는 오해

• LOCK=NONE이면 락이 없다. DML 동시성 요청과 MDL 대기는 다른 문제입니다. 시작·완료 단계의 짧은 배타적 락도 고려해야 합니다.
• 대기 중인 ALTER만 죽이면 끝난다. 차단 세션이 남아 있으면 다음 배포도 같은 곳에서 멈춥니다. 먼저 blocker를 식별해야 합니다.
• 차단 PID는 바로 KILL한다. 장기 트랜잭션의 롤백, 업무 오류, 커넥션 풀 재연결을 고려하지 않은 종료는 장애를 키울 수 있습니다.
• ALGORITHM과 LOCK 옵션을 생략해도 같다. 명시하지 않으면 작업 종류와 서버 판단에 따라 예상보다 강한 방식이 선택될 여지가 있습니다. 운영 배포에서는 허용 가능한 방식을 옵션으로 고정해 실패를 빠르게 드러내는 편이 안전합니다.
• DDL 완료 후 인덱스 존재만 보면 된다. 정의 확인 뒤 실제 쿼리 실행계획, 오류율, 대기열을 함께 관찰해야 합니다.

마무리

온라인 DDL의 목표는 테이블을 바꾸는 동안 동시 작업을 최대한 허용하는 것입니다. 그러나 그 목표가 메타데이터 락 대기까지 없애지는 않습니다. 배포가 멈춘 순간에는 옵션을 바꾸거나 세션을 끊기 전에 sys.schema_table_lock_waits로 waiting PID와 blocking PID를 연결하고, 차단 세션의 업무 맥락을 확인하십시오. 이 순서가 있어야 온라인 DDL을 단순한 문법이 아니라 안전한 운영 절차로 쓸 수 있습니다.

공식 출처

• MySQL 8.4 Reference Manual — InnoDB and Online DDL
• MySQL 8.4 Reference Manual — Online DDL Failure Conditions
• MySQL 8.4 Reference Manual — schema_table_lock_waits
• MySQL 8.4 Reference Manual — Performance Schema Lock Tables