환경 및 목적
최근 진행 중인 Oracle → TiDB 전환 프로젝트에서, 애플리케이션 호환성 테스트를 위해 테스트 환경의 오라클 스키마 구조와 데이터를 TiDB로 동기화해야 했다. 전체 데이터 부하가 크지 않아서 효율적인 방법을 우선 고려하였으며, CSV 기반의 내보내기/불러오기 방식을 선택했다.
전체 프로세스 개요
- 테이블 스키마 변환
- 원본 데이터 내보내기 (CSV)
- 타겟 데스크탑(티드비)에 데이터 불러오기
1. 스키마 구조 변환
TiDB는 MySQL 프로토콜을 지원하지만, 오라클의 데이터 타입과 문법은 직접적으로 호환되지 않는다. 예를 들어, DATE, VARCHAR2, NUMBER 등의 타입, 또는 PRIMARY KEY, FOREIGN KEY, CONSTRAINT 등 제약 조건은 티드비에서 일부 제한적이다.
이번 테스트에서는 오라클 사용자 내 약 900개의 테이블이 존재하여 수동 변환은 불가능했고, 자동화 도구를 활용하기로 결정했다. 주로 사용한 도구는 TransferDB이며, 이는 PingCAP 소속 개발자가 개발한 비공식 공개 도구지만 매우 실용적이다.
TransferDB는 다양한 기능을 제공하며, 특히 다음 사항에 유용하다:
- 스키마 변환 (Schema Conversion)
- 표 구조 검증
- 이전/현재 시스템 간 성능 평가
- 데이터 전송 (전량 또는 증분)
- CSV 내보내기
본 문서에서는 스키마 변환 기능만 사용하였다. 설정 파일은 config.toml 형식으로 되어 있으며, [source]와 [target] 섹션에 연결 정보만 수정하면 된다.
설정 완료 후 아래 두 명령어를 실행하면 스키마 변환 작업이 시작된다:
# 준비 단계: 마이그레이션 메타정보 저장소 생성
./transferdb --config config.toml --mode prepare
# 실제 스키마 변환 수행 및 출력 파일 생성
./transferdb --config config.toml --mode reverse
실행 결과로 다음과 같은 두 개의 SQL 파일이 생성된다:
reverse_${sourcedb}.sql: TiDB에서 바로 실행 가능한 스키마 정의compatibility_${sourcedb}.sql: TiDB에서 지원되지 않는 요소(예: 외래키, 제약조건 등) 포함
첫 번째 파일은 직접 티드비에 적용하고, 두 번째 파일은 수작업으로 검토해 대체 전략(예: 애플리케이션 계층에서 제약 조건 처리)을 마련해야 한다.
2. 원본 데이터 내보내기 (CSV)
오라클에서 데이터를 CSV로 추출하기 위해 sqluldr2를 사용했다. 이 도구는 가볍고 빠르며, 플랫폼 독립적이며 커스텀 SQL도 지원한다.
다만, sqluldr2는 일괄 내보내기를 지원하지 않아, 테이블 목록을 미리 파일로 추출한 후 스크립트로 처리하는 방식을 채택했다.
먼저 모든 테이블 이름을 가져오는 쿼리를 실행하여 목록 파일을 생성한다:
./sqluldr2linux64.bin user=user/pwd@192.168.1.1:1521/orcl query='select table_name from all_tables where owner=''test''' file=/tmp/tidb/sqluldr_tables.sql
다음으로, 각 테이블에 대해 병렬로 내보내기 스크립트를 작성한다:
#!/bin/bash
cat /tmp/tidb/sqluldr_tables.sql | while read table_name
do
echo "Exporting $table_name"
/tmp/tidb/sqluldr2linux64.bin \
user=user/pwd@192.168.1.1:1521/orcl \
query="SELECT * FROM test.$table_name" \
charset=UTF8 \
field=0x7c0x260x7c \
record=0x3d0x37 \
null=null \
file="/tmp/tidb/data/orcltest.$table_name.csv"
done
주요 설정 사항:
- 필드 구분자 및 행 종료 문자는 복잡한 조합(예:
|&|,=%)을 사용하여 데이터 파싱 오류를 최소화 - 문자 인코딩은 UTF-8로 지정하여 한글 데이터의 깨짐 방지
- 파일명 형식은
{dbname}.{tablename}.csv로 맞춰야 TiDB Lightning이 정상적으로 인식 가능
3. TiDB로 데이터 임포트
CSV 파일을 티드비에 로드하는 방법으로는 일반적으로 LOAD DATA 또는 TiDB Lightning이 있다. 하지만 다음과 같은 이유로 Lightning이 더 적합하다:
- 다수의 파일을 동시에 처리 가능
- 성능이 우수하며, 여러 백엔드 모드 지원 (local, tidb 등)
- 장애 발생 시 재시작 가능 (중단점 복원), 반면
LOAD DATA는 실패 시 전체 삭제 후 재시작 필요
다음은 핵심 설정 예시:
[tikv-importer]
backend = "local"
sorted-kv-dir = "/tmp/tidb/lightning_dir"
[mydumper]
data-source-dir = "/tmp/tidb/data"
no-schema = true
filter = ['*.*']
[mydumper.csv]
separator = '|&|'
delimiter = ''
terminator = '=%'
header = false
not-null = false
null = '\N'
backslash-escape = true
trim-last-separator = false
실행 명령어:
./tidb-lightning --config tidb.toml --checkrequirements=false
주의사항:
local모드 권장:BLOB데이터 처리에 유리no-schema = true: 이미 스키마가 준비되었으므로 불필요한 재생성 방지- 구분자 및 종료 문자는
sqluldr2설정과 반드시 일치해야 함
보완 사항 및 한계
저장 프로시저, 사용자 정의 함수는 오라클 특유의 구문으로 인해 직접 마이그레이션 어렵다. 따라서 애플리케이션 코드 내에서 재현하는 것이 현실적이다.
뷰의 경우, PL/SQL로 내보낸 SQL을 직접 티드비에 적용했지만, 대부분의 시스템 함수 및 문법 호환 문제로 오류 발생. 이는 수동으로 SQL 리라이팅이 필요함.
결론
이전에는 DSG 같은 상용 도구를 사용했지만, 비용 문제가 있었고, 공식 문서(TiDB in Action)에서 제시한 OGG 기반 방식은 배포가 복잡했다.
본 문서에서 소개한 도구들은 설치 없이 즉시 사용 가능하며, 네트워크 제한이나 패키지 매니저 없는 환경에서도 문제없이 작동한다. 작은 규모의 테스트용 마이그레이션에 매우 효과적이다.
더 나은 솔루션이 있다면 공유해 주세요. TiDB 생태계 발전에 기여하겠습니다.