← 전체 글로 돌아가기

DB

운영 DB를 다룰 때 꼭 지켜야 할 세 가지

스키마 변경 전에 백업, 변경 후에 검증, 문제 시 롤백. 이 순서를 거르면 안 된다.

개인 프로젝트도 운영 환경 DB라면 신중하게 다뤄야 한다. 한 번 잘못하면 데이터는 복구 불가능하다.

변경 전: 반드시 백업

# PostgreSQL
pg_dump -U user dbname > backup_$(date +%Y%m%d_%H%M%S).sql

# MySQL
mysqdump -u user -p dbname > backup_$(date +%Y%m%d_%H%M%S).sql

# SQLite
cp production.db production.db.backup

백업이 정상인지 복구 테스트까지 해야 한다. 백업 파일이 있어도 복구할 수 없으면 소용없다.

변경 중: 로그와 응답 기록

# 마이그레이션 실행
npx prisma migrate deploy 2>&1 | tee migration.log

# 스키마 변경 후 데이터 검증
npx prisma db execute --stdin < validate.sql

모든 변경을 로그로 남겨둬야 나중에 뭐가 터졌는지 추적할 수 있다.

변경 후: 즉시 검증

-- 새로 추가한 컬럼의 NULL 값 수
SELECT COUNT(*) WHERE new_column IS NULL;

-- 데이터 타입이 맞는지
SELECT typeof(new_column) FROM table LIMIT 5;

-- 기본값이 제대로 적용됐는지
SELECT COUNT(DISTINCT new_column) FROM table;

쿼리 한두 개로 사소한 문제를 미리 찾을 수 있다.

권한 확인

# 현재 사용자 권한
SHOW GRANTS FOR current_user;

권한 부족으로 마이그레이션이 실패할 수도 있다. 특히 인덱스 생성이나 테이블 락이 필요한 작업은 더 그렇다.

롤백 계획

# 마이그레이션 상태 확인
npx prisma migrate status

# 마지막 마이그레이션만 취소 (5.0+)
npx prisma migrate resolve --rolled-back latest

# 백업에서 복구
rm production.db
restore < backup_file.sql

OK 상태라고 해서 일을 끝내면 안 된다. 24시간 뒤에 다시 한 번 검증해야 진짜 안전한 것이다.