DB 마이그레이션 해보면서 겪은 트러블슈팅

혼자 사이드프로젝트로 만든 서비스에서 기존에 supabase를 쓰고있었는데 어느날부턴가 db가 업데이트가 안되는걸 알게되었다.

 

프로젝트 특성상 매일 하루 1번씩 db 내용을 싹 최신화하고 있었는데

 

그게 사용량을 많이 잡아먹었는지 무료요금제로는 더이상 커버가 안된다는 듯한 알림 메세지와 함께 업뎃이 멈춰버렸다.

 

 

가끔 이러긴해도 수동으로 풀어주면 됐었는데 이번엔 안되길래 그냥 서버 자체에 mysql 설치해서 운용해보는 방식으로 바꾸는걸로 마음먹고 작업을 시작했다.

---

 

ORM으로 Prisma를 사용중이었는데 세팅부터 바꿔주는 일을 해주었고,

 

그래도 테이블은 눈으로 봐야하니까 알아보다 Sequel Ace를 알게 되어 도입하니 잘 작동하는듯 보였다.

 

근데 지금까지 했던작업이 모두 로컬에서 돌아가는 세팅을 해준것이었고,

 

원래 목적이었던 서버에서 db가 돌아가는 모양새는 아니었다.

 

그래서 db로 넘어가서 로컬에서 했던 작업 그대로 반복했는데,

 

db의 원격 ip로는 접근할수없다는 에러메세지가 반복되는 현상이 나타났고, 여기서 좀 많이 헤맸다..

알고보니 EC2에서 인바운드 보안그룹에 Mysql 과 포트번호를 추가해줘야 하는것이었고,

 

ec2 보안그룹

 

 

위 이미지처럼 적용해주었더니 그제서야 정상적으로 db 접근이 가능해져서 마이그레이션에 성공했다.

 

---

 

서비스 정상작동 테스트를 위해 이것저것 해보았는데

 

검색 기능에서 서버에러가 발생하였다.

 

로그를 확인해보니 아래처럼 나왔는데,

 

 

서버 에러 로그

 

 

기존에 PostgreSQL을 supabase에서 사용했었는데 대용량 데이터에서 탐색,정렬 등이 우수하다는 장점으로 썼었다.

 

에러로그에 찍힌 "mode" 는 대소문자 구분없이 탐색을 위한 Prisma의 옵션이었는데 아래처럼 사용했었다.

 whereClause = {
    OR: [
      { name: { contains: searchQuery, mode: "insensitive" } }
    ],
  };



await prisma.product.findMany({ 
  where: whereClause
})

 

 

PostgreSQL이 기본적으로 대소문자를 구분하기때문에 구분없이 탐색을 위해 위와같은 대소문자 구분없이 탐색하게 하려고 넣었던것이었는데 prisma 문서에서 알게된사실이 하나 있었다.

MySQL도 PostgreSQL랑 마냥 동일하게 작동하는줄 알았는데, 얘는 기본적으로 대소문자 구분없이 탐색이 가능하다고한다.

 

그래서 Mode옵션이 필요없는거였다고...

prisma docs

출처 : https://www.prisma.io/docs/orm/prisma-client/queries/filtering-and-sorting#case-insensitive-filtering

 

 

그래서 기존 코드에서 mode만 빼고 다시 배포하니 정상 작동하는걸 확인하였고, 처음 목표로 했던 모든 작업이 마무리 되었다.

 

 

 

블로그포스팅에 생략된 내용이 많아서 되게 금방 작업이 끝난것처럼 느껴지지만 진짜 하나하나가 매우 하드한 작업이었다.

(개인적견해)

 

PostgreSQL에서는 어떤이유로 대소문자를 구분하는지 따로 알아볼 필요가 있을것 같다.

---

 

결론

본업이 프론트엔드 개발자라 DB를 잘 모르는 상태에서 하다보니 진짜 간만에 머리 쥐어뜯는 느낌으로 매달렸다. 

그래도 그만큼 배운건 많았던 초창기 생각나는 자극적인 경험이었다 ㅋ