DBMS/MySQL

[MySQL] DB에 이상한 데이터가 있어요! (MySQL Strict mode)

DevPing9_ 2023. 10. 2. 18:02

발단

데이터 중에 누가봐도 이상한게 있었다. 

테스트 데이터겠지, 그 때 어플리케이션 코드가 이상했겠지로는 설명이 안되는 최신데이터로 말이다.

 


MySQL Strict Mode

MySQL 5.7 이상 버전들은 Strict Mode 가 기본설정이지만, 그 이하 버전들은 Strict Mode 가 꺼져있다.

 

Strict Mode 가 꺼져있다면 에러가 나야 할 쿼리들이 에러 없이 실행된다.

 

varchar(4) 로 설정했지만 10글자의 String 을 INSERT 문으로 작성하여도 성공적으로 실행된다.

 

아래 포스팅에 잘 설명되어 있으니 참고하자.

 

 

MySQL Strict mode 끄기/켜기

MySQL 5.7 부터는 STRICT_MODE 가 기본 설정이라고 하니 별도의 설정 작업이 필요없다.

www.lesstif.com


그럼 Strict Mode 를 키면 되나?

이미 Strict Mode 가 꺼진채로 운영중인 시스템에서 켜 버린다면 재앙이 발생할 수 있다.

누군가는 Strict Mode 가 꺼진 것을 인지하고 어플리케이션 코드를 짜버렸을 수도 있으니까 말이다.

 

이럴 때에 변경 비용이 적은게 바로 마이크로서비스 아키텍처이구나... 라고 열심히 느끼고 있다.

 

 

어플리케이션에서 값 검증

이런 상황에서는 DB 를 믿지 못하니 insert 할 객체에 validation 을 모조리 걸어버리는 방법밖에는 없다.

DB 가 할 일을 어플리케이션에서 중복으로 하는 느낌이 들어 매우 거부감이 들었다.

 

Strict Mode 가 켜져있다면, 어플리케이션에서는 값에 대한 검증을 미뤄도 될까?

 

동료들과 토의 결과, 답은 '아니다' 로 귀결 되었다.

 

어플리케이션에서 값에 대한 검증을 하지 않는다면, Client 는 SQL Error Message 를 보게 된다.

비지니스에 대한 에러메세지가 아닌 그저 특정 값을 insert/update 할 수 없다라는 메세지만 받기 때문에 작업자는 비지니스에 대한 요구사항을 정확히 알 수 없다.

 

오래된 작업일수록 히스토리를 알기 어려워지는데, 그 때 에러메세지라도 비지니스적으로 작성이 되어있다면 히스토리 파악에 도움이 되기에 유지보수비용을 줄일 수 있다 라는 것이 결론이다.

 

 

728x90