SQL 덤프에서 스키마(구조)만 내보내기

세 가지 상황이 계속 반복됩니다:

• 스테이징이나 CI용 스키마 구축 — 테스트가 실제 컬럼, 인덱스, 제약 조건을 대상으로 실행되도록 빈 테이블 구조를 원하지만, 일회용 환경에 기가바이트 단위의 운영 데이터를 밀어 넣는 것은 절대 원하지 않습니다.
• 시드 데이터만 — 대상 데이터베이스에 스키마는 이미 있고, 이를 채울 INSERT 행만 필요합니다. 기존 것과 충돌할 CREATE 문 없이요.
• 잡음 제거 — 덤프가 절대 가져오고 싶지 않은 수천만 행짜리 logs, sessions, audit_trail, cache 테이블로 비대해져 있습니다.

mysqldump --no-data로 충분하지 않은 이유

고전적인 조언은 mysqldump --no-data(구조만) 또는 mysqldump --no-create-info(데이터만)입니다. 둘 다 내보내기 플래그입니다. 실행 중인 데이터베이스에서 새로 뜨는 덤프에 무엇이 담길지를 바꿀 뿐입니다. 이미 .sql 파일로 디스크에 놓여 있는 덤프에는 아무 소용이 없습니다.

실무에서는 그 파일이 다른 사람에게서, 또는 백업 작업에서, 또는 더 이상 라이브로 접근할 수 없는 서버에서 오는 경우가 잦습니다. 접근할 수 없는 데이터베이스를 상대로 mysqldump를 다시 실행할 수는 없습니다. 자격 증명이 사라졌거나, 서버가 폐기되었거나, 그 파일이 받은 전부이기 때문입니다. 그 시점에서 플래그는 무용지물이고, 결국 파일 자체를 편집하게 됩니다.

수동 방식

가장 먼저 떠오르는 방법은 grep이나 sed로 줄을 걷어내는 것입니다. 구조를 유지하고 데이터를 버리려면:

# INSERT 행만 빼고 전부 유지
grep -v '^INSERT INTO' dump.sql > schema.sql

# 또는 데이터 전용 파일을 위해 INSERT 행만 유지
grep '^INSERT INTO' dump.sql > data.sql

작고 깔끔한 덤프에서는 괜찮아 보이지만, 실제 덤프에서는 깨집니다:

• 여러 줄 INSERT. 하나의 INSERT INTO … VALUES가 수천 줄에 걸칠 수 있습니다. grep은 첫 줄만 매칭하고 나머지 값들을 고아로 남겨, 깨진 파일을 만듭니다.
• 확장 INSERT. mysqldump는 여러 행을 하나의 거대한 문장으로 묶습니다. 줄 기반 필터는 그런 문장이 어디서 끝나는지 알 수 없습니다.
• 주석과 블록. 조건부 /*! … */ 블록, LOCK TABLES, -- 주석이 데이터 사이에 뒤섞여 있어, 순진한 필터는 쓰레기를 남기거나 가져오기에 필요한 것을 잘라냅니다.
• 데이터 전용은 더 나쁩니다. 순수한 grep '^INSERT'는 행이 의존하는 SET과 LOCK 문을 버리고, 정확히 0번째 열에서 시작하지 않는 INSERT는 조용히 사라집니다.

결국 스키마를 얻는 대신 자기 필터를 디버깅하는 데 시간을 쓰게 됩니다.

DumpCleaner로 구조만 또는 데이터만

DumpCleaner는 줄을 매칭하는 대신 SQL 문장을 이해하므로, 크기에 상관없이 파일에서 구조와 데이터를 안정적으로 분리합니다:

1. .sql 덤프를 DumpCleaner에 끌어다 놓습니다 (MySQL, MariaDB 또는 PostgreSQL). 스트리밍으로 파일을 파싱하므로 수 기가바이트 덤프도 일정한 메모리로 로드됩니다.
2. 원하는 문장 유형을 켭니다: CREATE TABLE, CREATE INDEX, INSERT INTO, ALTER, DROP, LOCK, SET. INSERT INTO의 체크를 해제하면 구조만 얻고, CREATE TABLE / CREATE INDEX의 체크를 해제하면 데이터만 얻습니다.
3. 또는 프리셋을 고릅니다. 구조만 또는 데이터만을 선택하면 모든 토글이 한 번에 설정됩니다. 그런 다음 원하면 테이블별로 다듬으세요.
4. 내보내기. 스테이징이나 CI를 위한 간결한 스키마 파일, 또는 시딩을 위한 깔끔한 데이터 전용 덤프를 얻습니다.

필터가 문장을 인식하기 때문에, 여러 줄에 걸친 확장 INSERT는 하나의 전체로 유지되거나 버려집니다. 절대 한복판에서 잘리지 않습니다.

진정한 강점은 필터링이 문장 유형별로도, 테이블별로도 작동하며, 이 둘이 결합된다는 점입니다. 모든 테이블의 구조는 유지하면서 실제로 필요한 세 개의 테이블에만 INSERT 데이터를 포함해, 8,900만 행짜리 logs 테이블은 빈 껍데기로 남길 수 있습니다. 어떤 --no-data 플래그로도 표현할 수 없는 일입니다.

자주 묻는 질문