데이터베이스 unique 제약이 문제를 일으킬 때 배포 전 확인

unique 제약 조건을 데이터베이스 스키마에 추가하면, 기존 데이터 중에 중복이 있으면 배포가 실패할 수 있다.

현재 데이터베이스 상태를 확인한다

SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1;

uniqu 제약을 걸려는 칼럼에서 실제로 중복 값이 있는지 본다. 만약 있다면, 마이그레이션 전에 정리해야 한다.

마이그레이션 순서를 정한다

1. 기존 데이터에서 중복을 찾는다
2. 중복을 정리한다 (삭제하거나 병합)
3. unique 제약을 추가한다
4. 새로운 데이터가 들어올 때 중복을 방지하는 로직을 확인한다

설정을 확인한다

npm run build

마이그레이션 파일이 실제로 제약을 추가하는지 확인한다. 그리고 마이그레이션이 보상 트랜잭션을 지원하는지 본다 (원복할 수 있는지).

작은 환경에서 먼저 시도한다

Development 환경의 데이터베이스로 먼저 마이그레이션을 시도한다. 만약 실패하면, 왜 실패했는지 에러 메시지를 읽고 프로덕션 데이터베이스에 적용하기 전에 수정한다.

롤백 계획을 준비한다

마이그레이션 후 문제가 생기면 빠르게 원상복구해야 한다. 제약을 추가하는 명령의 반대 명령을 미리 작성해 두는 게 좋다:

ALTER TABLE users DROP CONSTRAINT unique_email;

애플리케이션 로직도 함께 검토한다

Databse 제약은 안전장치이지만, 애플리케이션에서도 중복을 사전에 방지해야 한다. 새 사용자 등록 시 이미 존재하는 이메일인지 먼저 확인하는 로직이 있는지 본다.