dump한 데이터베이스가 실행 안될 때

회사에서 개발용 데이터베이스가 존재하긴 하지만 프론트엔드 개발자도 다 같이 사용하고 있다보니 테이블을 지우거나 하는 부분에서 오류가 날 것 같아 내 로컬에서만 동작하도록 환경을 바꾸고 업무를 진행하기 위해 데이터베이스를 덤프시켰다.

 

덤프시킨 이후로 설정을 변경해 프로젝트를 실행시켰을 때, 데이터베이스와 프레임워크 간의 연결을 잘 되었지만 이상하게 일부 쿼리에서 오류가 발생했다. 오류 메시지는 단순히 사내 코드에서의 콜백 리턴이었어서 정확한 이유를 찾을 수가 없었다. 수석님께 말씀드렸을 때, mysql 설정 쪽이 문제일 것 같다고 말씀해주셨고 설정 관련해서 이것저것 삽질하며 찾아갔고 어떤 부분을 고쳐주어야 하는지 남겨두려고 한다.

 

설정이 문제였다고 확신

설정이 문제였다고 나 또한 확신할 수 있었던 것은 mysql 함수가 제대로 동작하지 않았다. 일부 쿼리들은 정상적으로 동작하는 것을 보아 mysql 자체는 문제가 아니었는데 JSON_OBJECT라던가 하는 함수가 사용된 쿼리들은 모두 오류를 뱉어냈다. 여러 해결 방법을 찾았지만 SQL 모드를 확인해보았다.

 

SQL 모드

SHOW VARIABLES LIKE 'sql_mode';

본인의 로컬 환경 또는 세팅이 완료된 데이터베이스에서 다음과 같은 쿼리를 입력해본다.

 

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,

이런 결과값을 확인했다. 여기서 ONLY_FULL_GROUPY_BY, STRICT_TRANS_TABLES 등의 모드 값으로 인해 JSON_OBJECT 와 같은 내부 함수들이 제약받을 수 있다.

 

SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';

NO_ENGINE_SUBSTITUTION은 엔진이 InnoDB로 설정되어있을 때 가정하고 InnoDB 스토리지 엔진이 사용할 수 없는 상태에서 테이블 생성 같은 것이 이루어지지 않도록 모드를 조정해준 것이다.

 

개인적인 생각으로는 STRICT_TRANS_TABLES와 같은 엄격한 규칙의 적용이 사라지게 되어 해결된 것으로 보이지만 해당 부분은 스토리지 엔진이 다르면 테이블이 생성되지 않도록 하는 기본적인 모드라고 생각해 이런 식으로 변경하게 했던 것 같다.

 

결과

데이터베이스를 덤프하고 사용하려고 하면 꼭 SQL 모드를 한 번 확인해본다.