우리의 친구 MySQL에는 내부적으로 런타임 때(즉, 프로그램이 시작될 때)
설정되는 내부 변수들을 가지고 있다.

이러한 내부 변수의 설정은,
mysql 명령어를 이용하여 프로그램을 시작할 때, 직접 입력할 수도 있지만,

my.cnf에 넣어두면 DEFAULT로 읽기 때문에,
미리미리 입력해 놓으면, 까먹거나 하는 사태가 발생하지 않는다.

그 중 오늘 살펴 볼 것은 max_allowed_packet 이다.

왜 하필 이 놈을???? 이라고 생각할 수도 있지만,
내가 오늘 이 놈때문에 고초를 겪었기 때문이라고 말할 수 밖에.......
-0-;;;;

일단 ERROR가 발생한 Log를 보자..
아래 로그는 Replication이 설정 되어 있는 두 서버가 있고,

이 중 Slave에서 Master의 Log를 다 읽지 못하고,
max_allowed_packet 탓을 하고 있는 장면이다.

##################################################################
80715 15:02:00 [ERROR] Error reading packet from server: Got packet bigger than 'max_allowed_packet' bytes ( server_errno=2020)
80715 15:02:00 [ERROR] Log entry on master is longer than max_allowed_packet (1048013) on slave. If the entry is correct, restart the server with a higher value of max_allowed_pac
et
####################################################################
(설정을 바꾸면, MySQL 데몬을 죽이고 다시 시작해야 한다고 나오지?)


이에 대해서,
MySQL REFERENCE 에는 max_allowed_packet에 대해 다음과 같이 말한다.

####################################################################
max_allowed_packet
서버에 전달 또는 서버로부터 받게 되는 패킷의 최대 길이. (디폴트는 16MB임.)
####################################################################

즉, 이 말인 즉슨 한 번에 오고 가는 packet의 사이즈가 정해져 있다는 말씀이다.

그런데 여기서 궁금한 것 !!!!

Q.
TCP/IP 통신이 DEFAULT 인 MySQL의 패킷은,
TCP에 의해 통신시 분명히 패킷이 쪼개져서 움직일 테인데,
그것의 사이즈를 왜 정한다니..

A.
< MySQL Packet Too large>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

그런 점에 대해서 위의 링크에서 또 설명이 나온다.
쏼라쏼라 풀어보면..

---------------------------------------------------------------------------
대저 MySQL에서의 Packet이라 함은
Single SQL 문 또는,
Replication이 이루어지는 Master에서 Slave로의 Binary Log Event를 의미한다.
..... MySQL 5.0 은 최대 1GB의 패킷을 허용하고 ......
---------------------------------------------------------------------------

흠.. 그렇다면, TCP로 쪼개져서 들어온 패킷들이,
뭉쳐져서 1개로 합쳐질 수 있는 한도 크기라는 의미로 보이는데....

그렇게 된다면,
TCP가 쪼개는 패킷의 사이즈와는 전혀 상관없다는 말씀이로군..
쩝... --;; 그걸 왜 햇갈리게 Packet이라고 부르는거냣!!!!!

암튼간에... '그런거였군!!!!' 하며 뒷목을 부여잡고,
10 + 8 을 몇 번 한 후에,
다음에 든 의문점을 알아 내기로 했다.



Q.
왜 max_allowed_packet의 크기가 Default 16M라면서,
실제 설치 후 값은 1M(1,048,576) 인 것이냐!!!!!

A.
그런데... 두둥!! 이것 역시 아래 링크에 있더라..

<MySQL Packet Too large - 위 링크랑 동일하다 -0-;;;>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

또 한 번, 쏼라쏼라 말 중 찝어 오자면...
프로그램은 DEFAULT max_allowed_packet 이
--------------------------------------------------------------------------------
MySQL CLIENT 프로그램은 DEFAULT max_allowed_packet 이16M.
MySQL SERVER 의 DEFAULT max_allowed_packet 은 1M....(이런 우라질리아 --;;)
--------------------------------------------------------------------------------

라고 하더군.... 
쩝... 뒷 목이 뽀사지겠다 이눔아!!!!!!
서버쯤 되면 사이즈 좀 크게 잡아줄 것이지... 쪼잔하게.. 1메가가 모니 --;;



그러면... 다음 질문..

Q.
그런데, MySQL이 아무리 븅~ 이라고 할 지라도,
어떻게 Packet을 쏘길래, 받지도 못 할만큼의 사이즈로 쏘는 것인가?

A.
얼래.... 이것 역시 아래 링크에 나온다...

<MySQL Packet Too large - 다른 링크 아니다. 위랑 똑같다 --;;>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

--------------------------------------------------------------------------------
Client 와 Server는 각각 max_allowed_packet을 가지고 있다.
만약,네넘이 커~~다란 사이즈의 Packet을 날리고 싶다면,
Client와 Server의 max_allowed_packet을 모두 바꿔 주어야 할 것이다..... ㅋㅋㅋ
--------------------------------------------------------------------------------

이런 뒌장 맞을.....

이 글을 읽고 조사해보니...
역시나, Master 녀석의 max_allowed_packet의 사이즈가 자그만치....
128M..............
쿠헬헬헬~~ 이 정도 되야 서버라고 부를 수 있지.... 하면서.. 역시나... 10+8 --;;

결국, slave 서버의 my.cnf에서
max_allowed_packet = 128M 로 바꿔 주고,
아무도 모르게 슬쩍 죽였다 살리기..... -0-;;;;

흐흐흐.. 사건은 종결 되었다.... 아무도 모르게....


흠흠... 다시 한 번 말하지만,
변경된 값을 적용하려면 MySQL을 다시 시작해야하기 때문에,
서비스 중인 장비에겐 치명적일 수 있다는 것.....

잘못하면...... 고객의 Complain에 몸져 누울 수 있다는 것!!!!

잊지말고 기억해 두자.. (-0-)/

출처 : http://blackbull.tistory.com/12