운영서버 및 개발서버에서 겪었던 일이다.

테이블에 컬럼을 추가하고 테스트를 해야하는 상황이었다. 

운영서버 배포시 소스코드는 추가된 컬럼을 운영서버 테이블에 추가하지 않아 문제가 있던 경험이 있던지라

개발서버 DB, 운영서버 DB 모두 테이블에 컬럼을 추가해두었다.

 

이후 테스트를 위해 특정 데이터의 상태값을 DBeaver 툴을 이용해서 수정하였다.

그런데 아래와 같은 메세지와 함께 Update가 안되는 것이었다

Error Code: 1136. Column count doesn't match value count at row 1

 

해당 에러문을 들고 구글로 얼른 찾아가보았다...

그런데 잉? 

INSERT 문을 사용할 시 컬럼수와 Values 의 값이 맞지 않을때 나오는 에러라고 한다.

나는 데이터 수정을 했는데? 왠 INSERT ? 왜 수정이 안되지? 

DBeaver를 오래 켜두었을때 가끔 에러메세지를 이유없이 뿜어대던 경험이 있었기에 이놈의 DBeaver가 말썽을? 하는 생각이 들었다. 2시간 정도 끙끙대다가 컬럼 추가한것이 문제인가라는 생각에 추가한 테이블 컬럼을 삭제하자 Update 가 잘되었다.

 

퇴근하며 구글링을 하다 원인을 예측할 수 있었고, 다음날 확인한 결과 그 원인은 맞았다...

그리고 그 원인과 함께 운영서버의 데이터가 망가져 있었다 ! ㅠㅠ

 

원인은 바로 트리거 였다. 해당 테이블에 트리거가 걸려있었던 것이다.

트리거 내용은 해당 테이블이 A라 했을때 INSERT, UPDATE 가 일어날 경우 아래와 같은 INSERT 구문이 실행되는 것이었다.

INSERT INTO A_HISTORY
SELECT * FROM A

 

A 테이블에 대한 로그 테이블인 A_HISTORY 에 내역을 저장하기 위한 트리거 였고 * 을 이용하여 INSERT 하고있었다...

그런데 A 테이블에 내가 컬럼을 추가하여 A_HISTORY 테이블과 컬럼숫자가 맞지 않아 에러가 발생한 상황이었다.

슬프게도 운영서버 A 테이블에도 컬럼을 같이 추가하였었기에....

테이블을 되돌리기까지의 2시간동안 운영서버에서 해당 테이블을 UPDATE 하는 API 부분들이 롤백 되어버렸다.

다행이 많은 롤백이 일어나진 않았고, 한 건의 결제 롤백이 있어서 강제로 결제성공 API를 태워 데이터를 원상복구하였다.

 

트리거라는 존재에 대한 고려가 필요하다는 사실을 깨닫는 경험이었다...

운영서버 컬럼추가는 신중하게....

이전엔 컬럼 추가가 누락되어서 실행안되던 경험이 있어서 미리.. 열심히 추가했는데.. ㅠㅠ

이후엔 트리거도 고려한 후에 추가하여야 겠다!

 

한편으론 해당 트리거를 만들어둔 사람이 원망? 되었다 ㅋㅋ....

컬럼을 명시한 것이 아니라 * 을 사용함으로서 이러한 에러 발생의 가능성을 남겨둔것이 아닌가! 하는 생각...

하지만 또 한편으론 임의의 컬럼이 추가 되었을때 이렇게 에러가 발생함으로써 로그테이블에도 해당 컬럼을

추가해야함을 확인할 수 있기도 했다.

 

해당 형태와 같은 트리거를 만들때 컬럼을 명시하는 것이 좋을까 아니면 해당 트리거처럼 * 을 이용하는 것이 좋을까?
컬럼을 명시할 경우 내가 겪은 상황과 같은 문제는 발생하진 않지만 새로이 추가된 컬럼에 대한 히스토리 로그가 남지 않는 문제점이 있다. 반면에 * 을 이용하면 모든 컬럼에 대한 처리가 가능하며 내가 겪은 일과 같이 에러를 발생하면 에러 자체로 문제가 될수 있지만 한편으론 히스토리 테이블에도 컬럼 추가가 필요하단 사실을 깨닫게 할 수 있다.

 

개발에 있어서 방법론적인 부분들에 장단점이 있다라는 사실이 고민의 기로에 서게 만드는것 같다.

이 부분에 대한 정답이 무엇인지 결론을 내리진 못하겠지만

만일 내가 해당 형태의 트리거를 작성하게 된다면 팀원들과 잘 공유하고 인지시켜야 한다라는 생각이 들었다.

또한 테이블에 변경사항이 있을때는 DB 테이블 및 소스 코드뿐만 아니라 DB내의 로직들(프로시져, 트리거) 등을 고려를 잘해야겠다라는 교훈을 얻었다.

+ Recent posts