도입
덤프 파일이 생성됐다는 사실과 데이터베이스 이전이 성공했다는 사실은 다르다. 테이블은 복원됐지만 이벤트나 루틴이 빠질 수 있고, 문자셋 또는 AUTO_INCREMENT가 달라질 수 있다. 이 글은 InnoDB 데이터베이스 하나를 논리 백업으로 옮기고 결과를 검증하는 절차를 다룬다.
전제 조건과 인증 파일
원본과 대상의 버전을 기록한다.
mariadb --version
mariadb -h source-db -e "SELECT VERSION(), @@character_set_server, @@collation_server"
mariadb -h target-db -e "SELECT VERSION(), @@character_set_server, @@collation_server"비밀번호는 명령행에 쓰지 않고 권한이 제한된 옵션 파일을 사용한다.
[client-source]
host=source-db
user=migrator
password=REPLACE_ME
[client-target]
host=target-db
user=migrator
password=REPLACE_MEchmod 600 ./migration.cnf원본 사전 조사
SELECT TABLE_NAME, ENGINE, TABLE_ROWS, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'app'
ORDER BY TABLE_NAME;
SELECT COUNT(*) FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'app';
SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'app';
SELECT COUNT(*) FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'app';--single-transaction은 InnoDB 같은 트랜잭션 엔진에서 일관된 스냅샷을 만든다. MyISAM이나 MEMORY 테이블이 섞여 있으면 같은 보장을 하지 못한다. 덤프 중 ALTER, DROP, RENAME, TRUNCATE 같은 DDL도 피한다.
덤프 생성
mariadb-dump \
--defaults-extra-file=./migration.cnf \
--defaults-group-suffix=-source \
--single-transaction \
--quick \
--routines \
--events \
--triggers \
--default-character-set=utf8mb4 \
--databases app \
--result-file=app.sql트리거는 기본 포함이지만 의도를 드러내기 위해 명시했다. 루틴과 이벤트는 별도 옵션이 필요하다. Windows에서는 >보다 --result-file이 줄바꿈 변환 문제를 피하는 데 유리하다.
Get-FileHash .\app.sql -Algorithm SHA256해시와 파일 크기, 생성 시각을 이전 기록에 남긴다. 덤프 파일에는 데이터와 정의자, 개인정보가 포함될 수 있으므로 암호화된 경로로 전송하고 작업 후 보존 정책에 따라 처리한다.
빈 대상에 복원
대상에 같은 이름의 기존 DB가 있다면 덮어쓰지 않는다. 새 서버에서 빈 상태임을 확인한 뒤 복원한다.
mariadb \
--defaults-extra-file=./migration.cnf \
--defaults-group-suffix=-target \
< app.sql오류가 하나라도 발생하면 성공으로 간주하지 않는다. 스크립트에서는 클라이언트 종료 코드를 확인하고 로그를 보관한다.
구조와 데이터 검증
테이블 목록과 행 수는 시작점일 뿐이다.
SELECT TABLE_NAME, ENGINE, TABLE_ROWS, AUTO_INCREMENT, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'app'
ORDER BY TABLE_NAME;중요 테이블은 추정치인 TABLE_ROWS 대신 직접 센다.
SELECT COUNT(*) AS orders_count,
MIN(order_id) AS min_id,
MAX(order_id) AS max_id,
SUM(total_amount) AS amount_sum
FROM app.orders;원본과 대상에서 동일 쿼리를 실행하고 결과를 비교한다. 구조는 다음 출력으로 비교한다.
SHOW CREATE TABLE app.orders;
SHOW CREATE VIEW app.monthly_sales;
SHOW CREATE TRIGGER app.orders_before_insert;
SHOW CREATE PROCEDURE app.close_expired_orders;
SHOW EVENTS FROM app;문자열은 대표 한글과 이모지를 조회해 깨짐도 확인한다. 애플리케이션 읽기 테스트와 제한된 쓰기 테스트를 수행한 뒤에야 컷오버한다.
실패 시 원칙
부분 복원된 DB에 같은 덤프를 임의로 재실행하면 중복이나 객체 충돌이 생길 수 있다. 트래픽이 연결되지 않은 대상 DB를 폐기하고 빈 DB로 다시 시작하는 편이 명확하다. 실제 폐기는 대상과 백업을 재확인하고 승인 절차에 따라 수행한다.
점검 체크리스트
- 원본의 엔진 종류와 DDL 동결 시간을 확인했는가?
- 루틴·이벤트·트리거 옵션을 포함했는가?
- 덤프 파일 해시와 종료 코드를 기록했는가?
- 대상이 빈 DB인지 확인했는가?
- 중요 테이블의 정확한 행 수와 집계값을 비교했는가?
- 구조, collation,
AUTO_INCREMENT, 루틴과 이벤트를 비교했는가? - 애플리케이션 검증과 롤백 기준이 있는가?
함께 읽기
참고 자료
확인일: 2026-07-29
한 줄 요약
마이그레이션 완료 조건은 덤프 생성이 아니라 구조·데이터·집계·문자셋·부가 객체와 애플리케이션 동작까지 원본과 일치하는 것이다.
댓글 0