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시간 뒤에 다시 한 번 검증해야 진짜 안전한 것이다.