어제 밤에 장애가 나서.. 두시간동안 DB쪽에서 처리를 하게 됐습니다..ㅎ
DB쪽에서 남긴 에러메시지는 없었고 WAS단에 있는 catalina.out에서 에러가 찍혔습니다.
SQL Exception SQL : SELECT last_insert_id()
getMessage : '2.147747853E9' in column '1' is outside valid range for the datatype INTEGER.
이 메시지가 떠서 다들 그냥 DB 문제라고 인식을 했습니다..ㅎ
전에 구매로그에 대해 insert를 하고 insert한 값을 last_insert_id()로 받아온 후 처리하는 로직이었거든요 ㅎ
하지만 해당 Table의 Schema는 Big int로 되어 있었기 때문에 이상했죠 ㅎ
여기서 MySQL의 Data Type을 보면 (5.5ver)
Type |
Storage |
MinimumValue |
Maximum Value |
|
(Byte) |
(Signed/Unsigned) |
(Signed/Unsigned) |
TINYINT |
1 |
-128 |
127 |
|
|
0 |
255 |
SMALL INT |
2 |
-32768 |
32767 |
|
|
0 |
65535 |
MEDIUMINT |
3 |
-8388608 |
8388607 |
|
|
0 |
16777215 |
INT |
4 |
-2147483648 |
2147483647 |
|
|
0 |
4294967295 |
BIGINT |
8 |
-9223372036854775808 |
9223372036854775807 |
|
|
0 |
18446744073709551615 |
이와 같습니다. 마지막으로 insert된 auto_increment 값은 2147483647값이었습니다.
그래서 DB 버그라고 생각하던 차에.. 오늘 출근하면서 생각을 해보니...
DB는 insret test를 했을 때 잘 되었고.. 결국 받아오는쪽에서 문제가 되지 않았을까 생각이 났죠 ㅎ
다음은 last_insert_id()의 범위를 알아 보게 되었는데요.
http://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_last-insert-id
이 곳을 참고해 보시면 됩니다.
인수를 사용한 경우 5.5.29 버전에서는 unsigned integer 범위를 지원하고 그 이전은 signed integer입니다.
인수를 사용하지 않은경우 5.5.29버전에서 unsigned bigint 를 지원하고, 그 이전은 signed bigint를 지원합니다.
저는 인수를 사용하지 않은 경우였기때문에 bigint를 지원하는 경우였지만..ㅎ 에러가 난 것이었고 개발서버에서 insert를 했을경우 많이 들어가는 것을 알 수 있었습니다.
그럼 이제 남은 것은!? jsp 로직이죠.
가장 의심스러웠던 것은 last_insert_id() 결과값을 받는 변수의 data type이었습니다. int로 되어 있을거같은 경향이 없지 않아 있어서..ㅎ 그래서 java의 data type을 보았는데
Type |
Bit |
Range |
Values |
byte |
8bits |
-2^7 ~ 2^7-1 |
-128 ~ 127 |
short |
16bits |
-2^15 ~ 2^15-1 |
-32768 ~ 32767 |
int |
32bits |
-2^31 ~ 2^31-1 |
-2147483648 ~ 2147483647 |
long |
64bits |
-2^63 ~ 2^63-1 |
-9223372036854775808 ~ 9223372036854775807 |
예상대로 int형은 mysql의 signed int와 똑같이 2147483647을 지원하는 것을 확인 했습니다.
그리고! 로직을 처리하는 웹페이지에서도 int형으로 변수가 선언이 되어 있는 것을 확인..ㅎ
이미 DB쪽에서 seq_no를 줄이는 작업을 한 상태라 웹페이지 변수를 바꾸는 사태가 일어나진 않았지만..
저는 작업을..ㅎ 다음에 이런경우가 발생하면 바로 web부터 봐야겠습니다 ㅎㅎ
'MySQL > MySQL Error Note' 카테고리의 다른 글
MYSQL_BIN_LOG::purge_logs was called with file (0) | 2015.04.01 |
---|