데이터베이스 스키마 변경 후 데이터가 사라졌을 때

스키마 변경 후 갑자기 데이터가 보이지 않거나 쿼리가 에러를 내기 시작할 때가 있다. 이런 상황은 보통 마이그레이션 과정에서 뭔가 잘못되었다는 뜻이다.

먼저 마이그레이션 상태 확인하기

현재 적용된 마이그레이션이 뭔지 확인하자. Prisma라면 npx prisma migrate status 명령으로 보류 중인 마이그레이션이 있는지 확인할 수 있다. 혹은 데이터베이스 내부의 마이그레이션 테이블을 직접 쿼리해서 어느 마이그레이션까지 적용되었는지 확인해보자.

스키마 백업 확인하기

마이그레이션을 적용하기 전의 스키마를 백업해뒀다면, 그것과 현재 스키마를 비교하자. pg_dump 명령으로 PostgreSQL의 스키마를 덤프해서 diff를 확인할 수 있다.

pg_dump --schema-only database_name > current_schema.sql

테이블 구조 다시 확인하기

각 테이블의 컬럼 정의가 제대로 되어있는지 확인하자. 특히 삭제해야 할 컬럼을 실수로 삭제했거나, 기본값을 잘못 설정했을 수 있다. 데이터는 물리적으로 존재하지만 쿼리로 조회가 안 된다면, 스키마 문제일 가능성이 높다.

외래 키와 제약 확인하기

부모 테이블의 행을 지우는 마이그레이션을 했다면, 외래 키 제약 때문에 자식 행도 함께 삭제되었을 수 있다. ON DELETE CASCADE 같은 옵션이 부재중에 적용되었는지 확인해보자. 또는 제약을 만족하지 않는 데이터가 있어서 데이터 조회가 실패할 수도 있다.

컬럼 타입 변경이 데이터에 미치는 영향

예를 들어 텍스트 컬럼을 숫자로 변경하면, 기존 텍스트 데이터가 변환되거나 손실될 수 있다. 마이그레이션 도중에 타입 변환이 제대로 이루어졌는지 확인하자. 필요하면 마이그레이션 전후에 데이터를 검증하는 스크립트를 작성해서 실행해보자.

npx prisma validate
npx prisma migrate status

인덱스와 쿼리 성능 확인하기

스키마 변경 후에 쿼리가 매우 느려졌다면, 인덱스가 제대로 생성되지 않았을 수 있다. 혹은 통계 정보가 오래되어서 쿼리 옵티마이저가 잘못된 실행 계획을 세웠을 수도 있다. PostgreSQL에서는 ANALYZE 명령으로 통계를 갱신할 수 있다.

롤백 계획 세우기

만약 마이그레이션이 정말 잘못되었다면, 빠르게 이전 스키마로 돌아갈 수 있어야 한다. Prisma나 다른 마이그레이션 도구에서 롤백 명령을 제공한다면 미리 테스트해두자. 또는 백업에서 복구하는 절차를 문서화해두면 응급 상황에 도움이 된다.

개별 데이터 복구 시도

전체 데이터를 잃었다면, 데이터베이스 백업에서 특정 테이블만 복구하는 방법도 있다. PostgreSQL의 pg_restore 명령으로 선택적으로 복구할 수 있다. 하지만 복구 후에는 현재 스키마와 데이터 구조가 일치하도록 정렬해야 한다.