중복 키 쿼리에서 mysql 크래시가 발생했습니다.

Question

최근에 5.5에서 5.7.19로 업그레이드 한 후 프로덕션 MySQL 서버가 가끔 충돌했습니다. 다음은 오류 로그에있는 스택 추적과 문제가있는 쿼리와 관련된 테이블입니다. 일반적인 로그를 표시하고 MySQL이 충돌 할 때마다 표시됩니다. 마지막 몇 개의 로그 항목에 매우 큰 insert on duplicate key 쿼리가있었습니다.

0xf4bd75 my_print_stacktrace + 53 
0x7d0144 handle_fatal_signal + 1188 
0x34d8a0f710 _end + -693094128 
0x800b23 Field_blob::copy_blob_value(st_mem_root*) + 51 
0xe9af6e mysql_prepare_blob_values(THD*, List<Item>&, st_mem_root*) + 686 
0xe9b575 write_record(THD*, TABLE*, COPY_INFO*, COPY_INFO*) + 565 
0xe9c952 Sql_cmd_insert::mysql_insert(THD*, TABLE_LIST*) + 2146 
0xe9d16e Sql_cmd_insert::execute(THD*) + 222 
0xd10279 mysql_execute_command(THD*, bool) + 4025 
0xd1481d mysql_parse(THD*, Parser_state*) + 1005 
0xd160ac dispatch_command(THD*, COM_DATA const*, enum_server_command) + 6188 
0xd16a74 do_command(THD*) + 404 
0xdea70c handle_connection + 668 
0xf69d64 pfs_spawn_thread + 372 
0x34d8a079d1 _end + -693126191 
0x311e4e8b6d _end + 475909485 


CREATE TABLE `t` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `col2` varchar(128) DEFAULT NULL, 
    `col3` int(11) DEFAULT NULL , 
    `col4` int(11) DEFAULT NULL , 
    `col5` int(11) DEFAULT NULL , 
    `col6` int(11) DEFAULT NULL , 
    `col7` varchar(128) DEFAULT NULL , 
    `col8` varchar(1024) DEFAULT NULL , 
    `report` longtext , 
    `create_date` datetime DEFAULT NULL , 
    `start_date` datetime DEFAULT NULL , 
    `finish_date` datetime DEFAULT NULL , 
    `state` varchar(128) DEFAULT NULL , 
    `col9` text , 
    `col10` int(11) DEFAULT NULL , 
    `col11` int(11) DEFAULT NULL , 
    `col12` text , 
    `count_post` int(11) DEFAULT NULL , 
    `count_reply` int(11) DEFAULT NULL , 
    `count_link` int(11) DEFAULT NULL , 
    `remark` text , 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `col2` (`col2`), 
    KEY `col4` (`col4`), 
    KEY `col5` (`col5`), 
    KEY `col6` (`col6`), 
    KEY `col7` (`col7`), 
    KEY `create_date` (`create_date`), 
    KEY `finish_date` (`finish_date`) 
) ENGINE=InnoDB AUTO_INCREMENT=405597973 DEFAULT CHARSET=utf8' 

5.7.19의 버그입니까? 관련 문제가 발견되었습니다. Crash on UPDATE ON DUPLICATE KEY하지만 반복 할 수는 없습니다. 이 문제를 어떻게 피할 수 있습니까? 아니면 어떻게 해결할 수 있습니까?

로 윌슨 Hauck는 지적, threads_%

mysql> SHOW GLOBAL STATUS LIKE 'threads_%'; 
+-------------------+-------+ 
| Variable_name  | Value | 
+-------------------+-------+ 
| Threads_cached | 1  | 
| Threads_connected | 2530 | 
| Threads_created | 5920 | 
| Threads_running | 2  | 
+-------------------+-------+ 

mysql> SHOW GLOBAL VARIABLES LIKE 'thread_%'; 
+-------------------+---------------------------+ 
| Variable_name  | Value      | 
+-------------------+---------------------------+ 
| thread_cache_size | 8       | 
| thread_handling | one-thread-per-connection | 
| thread_stack  | 262144     | 
+-------------------+---------------------------+ 

Answer 1

https://bugs.mysql.com/bug.php?id=79243 및 https://bugs.launchpad.net/percona-server/+bug/1667552와 동일하게 보입니다. 업스트림 버그에 대한 의견을 제안하고 해당 버그를 따르고 '영향'을 클릭하십시오.

Answer 2

MySQL의 5.7.19 변경 로그에 관한 다음 가지 버그에서이 고정 말한다 :

잘못된 동작이 실행 된 INSERT 문에 발생할 수 ON DUPLICATE KEY UPDATE 절의 VALUES 부분이 INSERT C 럼 목록의 BLOB 값을 참조하는 경우 저장된 프로그램 또는 prepared-statement 문에서. (버그 # 24538207, 버그 # 25361251, 버그 # 25530880, 버그 # 25684790)

는 분명 그들이 5.7.19에서 완전히 해결되지 않았다.

하지만 :-(그것은 나에게 해결 방법을 제시

이 같은 문이있는 경우 :. 당신은 UPDATE 절에 블롭 값을 사용하지 않도록를 다시 작성할 수 있습니다

INSERT INTO t (id, report) VALUES (1234, 'report report report') 
ON DUPLICATE KEY UPDATE report='report report report'; 

을 :

INSERT INTO t (id, report) VALUES (1234, 'report report report') 
ON DUPLICATE KEY UPDATE report=VALUES(report); 

이 구문은 보고서 열을 첫 번째 줄에 삽입하려고했던 것과 동일한 값으로 설정한다는 것을 의미합니다. 단지 약어 일 뿐이므로 리터럴 값을 반복하지 않아도됩니다 각 열에 대해 두 번.

저장 프로 시저 또는 준비된 문에서이 작업을 수행하면 충돌이 발생합니다. 나는 VALUES() 트릭을 사용하기를 좋아하지만, 5.7.19의 저장 프로 시저에서 블롭으로 시도했다고 말할 수는 없다.

"BLOB 값을 참조하는 ON DUPLICATE KEY UPDATE 절의 VALUES 부분이 ..."인 경우, 전체 BLOB 값을 명시 적으로 반복하면 문제를 해결할 수 있다고 생각합니다. VALUES() 속기를 사용하는 대신

그렇지 않으면 저장 프로 시저에서이 작업을 수행하지 마십시오 (문제가있는 경우).

Answer 3

threads_connected ~ 2500 +는 클라이언트가 시스템 사용을 마칠 때 로그 아웃/로그 오프 연결이 처리되지 않음을 나타냅니다.

스레드의 생성/종료 이탈을 방지하기 위해,이 인스턴스에서 생성 된 5,000 개 이상의 스레드를 지원하기 위해 8.0 에서 제안 CAP 8에서 /의 my.ini에 CNF thread_cache_size = 100 #을 변경합니다.

더 자세한 분석을 위해,

RAM on your server 
SHOW GLOBAL STATUS; 
SHOW GLOBAL VARIABLES; 
SHOW ENGINE INNODB STATUS; 

하고 일반 로그 1 분을 게시하시기 바랍니다.