read_buffer_크기 인 터 럽 트 복사

11446 단어 buffer
링크
There are some variables that can affect the replication behavior and sometimes cause some big troubles. In this post I’m going to talk about read_buffer_size and how this variable together with max_allowed_packet can break your replication.
일부 매개 변 수 는 복사 상태 에 영향 을 주 고 큰 문 제 를 일 으 킬 수 있다.이 글 에서 read 를 말씀 드 리 겠 습 니 다.buffer_size 및 그것 과 maxallowed_패 킷 이 함께 있 을 때 어떻게 복 사 를 중단 합 니까?
The setup is a master-master replication with the following values:  다음 인자 로 M-M 복사 설정:
max_allowed_packet = 32M

read_buffer_size = 100M

To break the replication I’m going to load the 4 million rows with LOAD DATA INFILE:
복 사 를 중단 하기 위해 서 저 는 LOAD DATA INFILE 로 4 백만 줄 의 데 이 터 를 불 러 올 것 입 니 다.
MasterA (test) > LOAD DATA INFILE '/tmp/data' INTO TABLE t;

Query OK, 4510080 rows affected (26.89 sec)

After some time the SHOW SLAVE STATUS on Master A gives us this output:잠시 기다 린 후 MASTERA 에서 SHOW SLAVE STATUS 를 실행 하여 아래 출력 을 받 습 니 다.
Last_IO_Error: Got fatal error 1236 from master when reading data from 
binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event
'mysql-bin.000002' at 74416925, the last event read from './mysql-bin.000004' at 171,
the last byte read from
'./mysql-bin.000004' at 190.'

Very strange! We have loaded the data on MasterA and now it has the replication broken with a error on max_allowed_packet. The next step is to check the binary logs of both masters.
너무 신기해!우 리 는 MASTETA 에 데 이 터 를 불 러 왔 는데,지금 은 max 가 있 습 니 다.allowed_패 킷 오류 로 복사 가 중단 되 었 습 니 다.다음 단 계 는 이 두 master 의 바 이 너 리 로 그 를 검사 하 는 것 입 니 다.
MasterA:
 masterA> mysqlbinlog data/mysql-bin.000004 | grep block_len

 #Begin_load_query: file_id: 1 block_len: 33554432

 #Append_block: file_id: 1 block_len: 33554432

 #Append_block: file_id: 1 block_len: 33554432

 #Append_block: file_id: 1 block_len: 4194304

 #Append_block: file_id: 1 block_len: 33554432

 #Append_block: file_id: 1 block_len: 10420608

No block is larger than the max_allowed_packet(33554432).max 를 초과 하지 않 았 습 니 다.allowed_패 킷(33554432)의 블록 입 니 다.
MasterB:
 masterB> mysqlbinlog data/mysql-bin.000004 | grep block_len

 #Begin_load_query: file_id: 1 block_len: 33555308

 #Append_block: file_id: 1 block_len: 33555308

 #Append_block: file_id: 1 block_len: 33555308

 #Append_block: file_id: 1 block_len: 4191676

 #Append_block: file_id: 1 block_len: 33555308

 #Append_block: file_id: 1 block_len: 10419732

Do you see the difference? 33555308 is larger than the max_allowed_packet size 33554432 so the Master2 has written the some blocks 876 bytes larger than the safe value. Then, MasterA tries to read again the binary log from MasterB and the replication breaks because packets are too large. No, the replicate_same_server_id is not enabled
다른 점 봤 어?33555308 비 maxallowed_packet(33554432)이 커서 MASTERB 는 안전 치보다 876 byte 큰 블록 을 썼 다.그리고 MATERA 는 MASTERB 에 가서 바 이 너 리 로 그 를 읽 으 려 고 했 습 니 다.읽 은 블록 이 너무 커서 복사 가 중단 되 었 습 니 다.replicate_same_server_id 인자 가 활성화 되 지 않 았 습 니 다.
What is the relation between read_buffer_size and this bug? 이 버그 와 readbuffer_사이즈 간 의 관 계 는 어 떻 습 니까?
Again, an example is best than words. These are the new values:  다시 한 번,예 가 더욱 설득력 이 있 습 니 다.새로운 매개 변 수 는 다음 과 같 습 니 다.
max_allowed_packet = 32M

read_buffer_size = 16M

We run the LOAD DATA INFILE again and now this is the output on both servers:  LOAD DATA INFILE 을 다시 실행 합 니 다.두 서버 의 출력 은 다음 과 같 습 니 다.
 #Begin_load_query: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 16777216

 #Append_block: file_id: 1 block_len: 14614912

The maximum size of the data blocks are based on the read_buffer_size value so they are never larger than the max_allowed_packet
Therefore, a read_buffer_size value larger than max_allowed_packet can break your replication while importing data to MySQL. This bug affects from 5.0.x to the latest 5.5.25 release and the easiest workaround is to not have a read_buffer_size larger than max_allowed_packet. The bug http://www.mysqlperformanceblog.com/2012/06/06/read_buffer_size-can-break-your-replication/ seems not to be really solved.
가장 큰 데이터 블록 크기 는 read 기반 입 니 다.buffer_size 값,그래서 max 보다 크 지 않 습 니 다.allowed_packet
그래서 MYSQL 에서 데 이 터 를 가 져 올 때 readbuffer_size maxallowed_패 킷 시 복사 가 중 단 됩 니 다.이 버그 는 5.0.X 에서 최신 5.5.25 까지 존재 합 니 다.가장 간단 한 해결 방법 은 read 를buffer_size max 이상allowed_packet。BUG 30435  제대로 해결 되 지 않 은 것 같다.
And remember, 30435 .
기억 하 세 요.

좋은 웹페이지 즐겨찾기