자~ 이제 드디어 마이그레이션의 최종화다.
01. 다시 마주한 그 녀석.
필자는 데이터를 이전 화에서처럼 잘 넣었고, 이제 본격적으로 스퍼트를 나서고 있었다. 그런데....
하필이면, 다시 그 녀석을 마주했다.
√ Drift detected: Your database schema is not in sync with your migration history.
We need to reset the PostgreSQL database "prototyping" at "localhost:5432".
Do you want to continue? All data will be lost. ... yes
그래서 필자는 이 놈이 궁금해지기 시작했다. 도대체 그냥 넘길 놈이 아니기에... 이번에 확실히 알고 넘어가야만 한다고 생각했다.
02. 놈을 드디어 알아내다.
이 녀석이 뜨는 이유에 대해 공식 프리즈마 문서에는 이렇게 알려주고 있다.
Schema drift
Database schema drift occurs when your database schema is out of sync with your migration history - the database schema has 'drifted away' from the source of truth.Causes of schema drift in a development environment
Schema drift can occur if:The database schema was changed without using migrations - for example, by using prisma db push or manually changing the database schema.
Note: The shadow database is required to detect schema drift, and can therefore only be done in a development environment.
-> 즉, 길게 주저리 주저리 써 놓았는데, 너가 마음대로 초안이랑 다르게 바꾸면 발생하는 트러블이라고 적어 놓았다.
그러면 이런 의문이 든다. 작업하다보면, 당연히 초안이랑 다르게 바꾸지 않나? 뭐야? 왜 이렇게 불편해....
03. 마이그레이션의 원리
이건 필자가 마이그레이션의 원리에 대해 잘 몰랐기에 발생한 일이었다. 사실.....
- Migration
Prisma 에서 Migration 은 schema.prisma 파일에 정의해놓은 스키마에 변화가 있을 경우
사용하고 있는 DB 에도 업데이트를 해주기위해 사용하는 연산이다.
그래서 한 마디로 보자면, 마이그레이션은 코드를 깃 허브에서 버전 관리를 해 주는 것처럼 mysql db와 연동해서 해당 db의 버전을 관리하는 것으로 이해하면 된다.
그런데, 여기서 문제가 생기는 점은 이 히스토리가 꼬이는 경우다. 즉, 필자처럼 스키마 파일을 수정 하기 전에 마이그레이션을 하지 않고 그냥 버전을 건너 뛰어서 마이그레이션을 하면 이렇게 오류가 뜬다. 왜? 버전이 안 맞으니까...
04. 그래서 어떻게?
그래서 결국 어쩌란 말이냐? 이거 해결 못하는 거 아닌냐?
NOPE!!! 이런 나 같은 사용자가 많았는지, 프리즈마 측에서도 해결할 수 있는 방법을 다 적어 놓았다. 바로 아래 그림처럼 하면 된다.
즉, 마이그레이션 기존의 히스토리를 무시하고, 새롭게 마이 그레이션을 진행하고 이제 그 마이그레이션 부터 다시 마이그레이션을 적용하는 방법이다.
하는 법은 간단하다.
<Initialize migration history
To initialize a new migration history:
If you have a prisma/migrations folder, delete, move, rename, or archive this folder.
Run the following command to create the first migration without applying it, in case you need to modify the initial migration:>
prisma migrate dev --name initial-migration --create-only
즉, 당신이 마이그레이션의 히스토리를 따르지 않고, 새롭게 만들고 싶다면 마이그레이트에 크리에이트 온리 옵션을 주면 되겠다. 그리고 나서 다시
NPX migrate dev
를 하면 이제는 새롭게 수정된 파일로 마이그레이션이 새로 진행되는 것이다. 이를 통해 기존의 버전을 날리고 새로 시작하는 것이라고 생각하면 되겠다.
아! 참 이전 포스팅에서 덤프 파일의 데이터를 활용한다고 했었다. 맞다. 여기서도 하면서 한 번 데이터를 날려먹어서 그때 덤프파일을 다시 인서트 인투해서 복원했었다. 그래서 결국 기존 백업을 제대로 이용해 볼 수 있었다.
05. 느낀점.
이렇게 수많은 트러블 슈팅을 해 보면서 직접 몸소 부딪혀 보니, 오히려 많이 발전하고 스스로 해결할 수 있음을 다시 느낄 수 있어 좋았다. 기존에는 그냥 어떻게 하지하고 우왕좌왕했다면, 이제는 뭐 데이터 날아간다고? 뭐 날리지 뭐. 백업 받아둔 것으로 다시 복원하면 된다. 물론 그 전에 마이그레이트를 조절해서 방어하면 된다!!! 라는 자신감이 좀 붙은 과정이었다.
그러면 다시 또 새로운 문제와 직면할 때 다시 돌아오겠다.
그럼 이만....
