从库crash一直自动重启(mysqld got signal 11)问题解决
一：问题描述 今天收到邮件报警，遂进数据库查看slave状态，发现io进程和sql进程都为NO. mysql show slave status \G;*************************** 1. row*************************** Slave_IO_State: Master_Host: 此处不予显示，哈哈 Master_User: replic
一：问题描述
今天收到邮件报警，遂进数据库查看slave状态，发现io进程和sql进程都为NO.
mysql> show slave status \G;
*************************** 1. row***************************
Slave_IO_State:
Master_Host: 此处不予显示，哈哈
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File:master1-bin.001191
Read_Master_Log_Pos: 29214749
Relay_Log_File:web_appdb_10-relay-bin.000663
Relay_Log_Pos: 29213639
Relay_Master_Log_File: master1-bin.001191
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table: ccda.%,eip_fileservice.%
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 29213491
Relay_Log_Space: 29215212
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
1 row in set (0.01 sec)
ERROR:
No query specified尝试启动，然后再次查看状态，竟然报错，说连不上数据库。
mysql> start slave; Query OK, 0 rows affected (0.00 sec) mysql> show slave status \G; ERROR 2006 (HY000): MySQL server has goneaway No connection. Trying to reconnect... ERROR 2002 (HY000): Can't connect to localMySQL server through socket '/tmp/mysql.sock' (2) ERROR: Can't connect to the server ERROR: No query specified
连续尝试多次，可以登录数据库了，再次查询复制，发现状态还是NO.
mysql> show slave status \G;
No connection. Trying to reconnect...
Connection id: 1
Current database: *** NONE ***
*************************** 1. row***************************
Slave_IO_State:
Master_Host: 10.0.3.34
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File:master1-bin.001191
Read_Master_Log_Pos: 29214749
Relay_Log_File:web_appdb_10-relay-bin.000663
Relay_Log_Pos: 29213639
Relay_Master_Log_File: master1-bin.001191
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table: ccda.%,eip_fileservice.%
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 29213491
Relay_Log_Space: 29215426
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 0
1 row in set (0.00 sec)
ERROR:
No query specified发现只要start slave，该服务器数据库就会自动重启。
而且start slave io_thread没问题，当start slave sql_thread时，才会导致数据库自动重启。
查看错误日志：
160429 9:09:00 [Note] Event Scheduler: Loaded 0 events 160429 9:09:00 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.5.19-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 160429 11:04:47 [Note] Slave SQL threadinitialized, starting replication in log 'master1-bin.001191' at position29213491, relay log './web_appdb_10-relay-bin.000663' position: 29213639 160429 11:04:47 - mysqld got signal 11 ; This could be because you hit a bug. It isalso possible that this binary or one of the libraries it was linkedagainst is corrupt, improperly built, or misconfigured. This error can also becaused by malfunctioning hardware. We will try our best to scrape up some infothat will hopefully help diagnose the problem, but since we have alreadycrashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=6291456 max_used_connections=3 max_threads=2000 thread_count=2 connection_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size +sort_buffer_size)*max_threads = 20764878 K bytes of memory Hope that's ok; if not, decrease somevariables in the equation. Thread pointer: 0x2ab2f1b54740 Attempting backtrace. You can use thefollowing information to find out where mysqld died. If you see no messagesafter this, something went terribly wrong... stack_bottom = 0x594310e8 thread_stack0x30000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x33)[0x765df3] /usr/local/mysql/bin/mysqld(handle_segfault+0x36e)[0x4ee4fe] /lib64/libpthread.so.0[0x31a640ebe0] /usr/local/mysql/bin/mysqld(_ZNK9table_def15compatible_withEP3THDP14Relay_log_infoP5TABLEPS5_+0x31a)[0x74c29a] /usr/local/mysql/bin/mysqld(_ZN14Rows_log_event14do_apply_eventEPK14Relay_log_info+0xcdc)[0x6f0d3c] /usr/local/mysql/bin/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x14d)[0x5021ed] /usr/local/mysql/bin/mysqld[0x504b19] /usr/local/mysql/bin/mysqld(handle_slave_sql+0xc0a)[0x5061ea] /lib64/libpthread.so.0[0x31a640677d] /lib64/libc.so.6(clone+0x6d)[0x31a54d49ad] Trying to get some variables. Some pointers may be invalid and cause thedump to abort. Query ((nil)): is an invalid pointer Connection ID (thread ID): 353 Status: NOT_KILLED The manual page athttp://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find outwhat is causing the crash. 160429 11:04:48 mysqld_safe Number ofprocesses running now: 0 160429 11:04:48 mysqld_safe mysqldrestarted 160429 11:04:48 InnoDB: The InnoDB memoryheap is disabled 160429 11:04:48 InnoDB: Mutexes andrw_locks use GCC atomic builtins 160429 11:04:48 InnoDB: Compressed tablesuse zlib 1.2.3 160429 11:04:48 InnoDB: Initializing bufferpool, size = 32.0G 160429 11:04:50 InnoDB: Completedinitialization of buffer pool 160429 11:04:50 InnoDB: highest supportedfile format is Barracuda. InnoDB: The log sequence number in ibdatafiles does not match InnoDB: the log sequence number in theib_logfiles! 160429 11:04:50 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information fromthe .ibd files... InnoDB: Restoring possible half-writtendata pages from the doublewrite InnoDB: buffer... InnoDB: Last MySQL binlog file position 0112571, file name ./mysql-bin.048292 160429 11:04:52 InnoDB: Waiting for the background threads tostart 160429 11:04:53 InnoDB: 1.1.8 started; logsequence number 5992159806777 160429 11:04:53 [Note] Recovering after acrash using mysql-bin 160429 11:04:53 [Note] Starting crashrecovery... 160429 11:04:53 [Note] Crash recoveryfinished. 160429 11:04:53 [Warning] Neither--relay-log nor --relay-log-index were used; so replication may break when thisMySQL server acts as a slave and has his hostname changed!! Please use'--relay-log=web_appdb_10-relay-bin' to avoid this problem. 160429 11:04:53 [Note] Event Scheduler:Loaded 0 events 160429 11:04:53 [Note]/usr/local/mysql/bin/mysqld: ready for connections. Version: '5.5.19-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
对于这个错误”mysqld got signal 11”，我在网上查了，有的说是磁盘空间满了，有的说是内存问题，也有可能是硬件错误，也有可能是中继日志重放位置的sql导致的。
查看中继日志该位置执行的语句：
Relay_Log_File:web_appdb_10-relay-bin.000663
Relay_Log_Pos: 29213639
# at 29213639 #160428 21:29:32 server id 1 end_log_pos 29213559 Query thread_id=624506 exec_time=0 error_code=0 SET TIMESTAMP=1461850172/*!*/; /*!\C utf8mb4 *//*!*/; SET@@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=33/*!*/; BEGIN /*!*/; # at 29213707 #160428 21:29:32 server id 1 end_log_pos 29213657 Table_map: `ccda`.`ess_accounting_relation`mapped to number 311993 # at 29213805 #160428 21:29:32 server id 1 end_log_pos 29213757 Table_map:`ccda`.`ess_accounting_relation_1` mapped to number 311994 # at 29213905 #160428 21:29:32 server id 1 end_log_pos 29214051 Update_rows: table id 311993 flags:STMT_END_F BINLOG ' PBAiVxMBAAAAYgAAANnDvQEAALnCBAAAAAEABGNjZGEAF2Vzc19hY2NvdW50aW5nX3JlbGF0aW9u AA4DDw8PDw8PDw8PDw8MAxYsATwAPAAGACwBPAAsAZYAlgCWAJYA/D8= PBAiVxMBAAAAZAAAAD3EvQEAALrCBAAAAAEABGNjZGEAGWVzc19hY2NvdW50aW5nX3JlbGF0aW9u XzEADgMPDw8PDw8PDw8PDwwDFiwBPAA8AAYALAE8ACwBlgCWAJYAlgD8Pw== PBAiVxgBAAAAJgEAAGPFvQEAALnCBAAAAAEADv////8Q4Dnl7wATADEyMTEwMTAxMTE1MTEwMDE2 MzUS5bqU5LuY5LuY5qy+5Yet6K+BA0VBUwAACeaKpei0puWNlRYAemhhbmd5MTA0NzE1MTExODEz MTYyMhcxMTExMDExNTExMTg1MDUyMzA2MjE2MQAAAI3GveRVEgAAEOA55e8AEwAxMjExMDEwMTEx NTExMDAxNjM1EuW6lOS7mOS7mOasvuWHreivgQNFQVMUADExMTEwMTE1MTEwOTEwMzgwMDg5CeaK pei0puWNlRYAemhhbmd5MTA0NzE1MTExODEzMTYyMhcxMTExMDExNTExMTg1MDUyMzA2MjE2MQAA AI3GveRVEgAA '/*!*/; ### UPDATE `ccda`.`ess_accounting_relation` ### WHERE ### @1=15721785 ### @2='1211010111511001635' ### @3='应付付款凭证' ### @4='EAS' ### @5=NULL ### @6='' ### @7='报账单' ### @8='zhangy1047151118131622' ### @9='11110115111850523062161' ### @10='' ### @11='' ### @12='' ### @13=2016-01-19 16:25:09 ### @14=NULL ### SET ### @1=15721785 ### @2='1211010111511001635' ### @3='应付付款凭证' ### @4='EAS' ### @5=NULL ### @6='11110115110910380089' ### @7='报账单' ### @8='zhangy1047151118131622' ### @9='11110115111850523062161' ### @10='' ### @11='' ### @12='' ### @13=2016-01-19 16:25:09 ### @14=NULL
先备份一下该记录，然后手动在从库上更新一下，看是否报错。
UPDATE `ccda`.`ess_accounting_relation`
SET attachId='11110115110910380089'
WHERE id = 15721785;
结果发现在从库上也可以正常update呀。
后来我想查看下该表表结构，结果出现错误：
mysql> show create table`ccda`.`ess_accounting_relation` \G;
ERROR 144 (HY000): Table'./ccda/ess_accounting_relation_1' is marked as crashed and last (automatic?)repair failed
ERROR:
No query specified
mysql> select count(*) fromccda.ess_accounting_relation_1;
ERROR 144 (HY000): Table'./ccda/ess_accounting_relation_1' is marked as crashed and last (automatic?)repair failed
诡异，刚才还能更新呢，现在却又不能正常访问了。
然后，尝试修复出问题的表：
check table ccda.ess_accounting_relation_1;
repair table ccda.ess_accounting_relation_1;
修复成功后，查看ccda.ess_accounting_relation 表结构，发现该表是个合并表，ess_accounting_relation_1是myisam引擎：
CREATE TABLE `ess_accounting_relation` (
……)
ENGINE=MRG_MyISAM DEFAULT CHARSET=utf8 INSERT_METHOD=LASTUNION=(`ess_accounting_relation_1`)
原本以为修复该表成功后，start slave，就正常了。结果还是会导致数据库重启。
此时，再检查ess_accounting_relation_1,也是正常的，没有显示崩溃。
我试验，在从库跳过该表的操作（用change master to或者set global sql_slave_skip_counter=n），当执行其他表的操作时，并没有导致从库重启。
我试验在从库配置文件里添加参数：replicate_ignore_table=ccda.ess_accounting_relation过滤掉这个表，然后重启数据库，再start slave,没有导致从库重启。
最后，我大胆试验下，在主库直接操作ess_accounting_relation_1的某条数据（前提是已经注释掉了上面的参数replicate_ignore_table），发现从库在应用相应数据时，并没有导致重启。
所以，问题就出在了这个mrg_myisam存储引擎。
这个表，其实每天也都有update，可是为什么最近才出现了这个问题，那就不知道了。因为这个表引用的子表数据量太大了吗？该表大概1600万数据。不晓得。
二：出错原因
一个mrg_myisam存储引擎的合并表，引用了一个myisam引擎的子表，更新前者导致slave数据库一直自动重启，且偶尔子表也会发生崩溃。
这估计是mysql的一个bug吧。
三：解决办法
由于ess_accounting_relation表数据只来源于ccda.ess_accounting_relation_1这一个表，实际上并没有合并的意义，而且，通过了解发现，这个myisam表经常更新。myisam容易崩溃，且不支持行锁，故建议将ccda.ess_accounting_relation_1改成innodb存储引擎（可以先mysqldump备份下这个表，然后在备份文件里将MyISAM改成innodb），删掉ccda.ess_accounting_relation，将ccda.ess_accounting_relation_1重命名为ccda.ess_accounting_relation。
--关于mrg_myisam介绍，请参考http://blog.csdn.net/yabingshi_tech/article/details/51320701
--备注：mysql版本5.5.19
핫 AI 도구
Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱
AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.
Undress AI Tool
무료로 이미지를 벗다
Clothoff.io
AI 옷 제거제
AI Hentai Generator
AI Hentai를 무료로 생성하십시오.
인기 기사
뜨거운 도구
메모장++7.3.1
사용하기 쉬운 무료 코드 편집기
SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.
스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경
드림위버 CS6
시각적 웹 개발 도구
SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)
뜨거운 주제
7478
15
1377
52
77
11
50
19
19
33
Samsung s24Ultra 전화를 다시 시작하는 방법은 무엇입니까?
Feb 09, 2024 pm 09:54 PM
Samsung S24 Ultra 휴대폰을 사용할 때 가끔 문제가 발생하거나 장치를 재설정해야 할 수 있습니다. 이 경우 전화를 다시 시작하는 것이 일반적인 해결 방법입니다. 그러나 단계에 대해 잘 모르면 혼란스러울 수 있습니다. 하지만 걱정하지 마세요. Samsung S24 Ultra 휴대폰을 올바르게 다시 시작하는 방법을 알려 드리겠습니다. Samsung s24 Ultra를 다시 시작하는 방법 1. 제어 메뉴를 불러와 종료: 삼성 화면 상단에서 아래로 밀어 바로가기 도구 메뉴를 불러오고, 전원 아이콘(호와 수직선의 조합)을 클릭하여 종료합니다. 종료 및 다시 시작 선택 인터페이스를 실행하려면 그냥 다시 시작을 클릭합니다. 2. 종료하려면 키 조합을 사용합니다. 볼륨 키와 전원 키를 길게 눌러 종료 및 다시 시작 선택 메뉴를 불러오고 클릭하여 종료를 선택합니다. 길게 누르면
컴퓨터 프롬프트 '재부팅 및 적절한 부팅 장치 선택'을 해결하는 방법
Jan 15, 2024 pm 02:00 PM
시스템을 다시 설치하는 것이 완벽한 해결책은 아닐 수 있지만 다시 설치한 후 컴퓨터를 켜면 검은색 배경에 흰색 텍스트가 표시되고 재부팅하고 적절한 부팅 장치를 선택하라는 메시지가 표시됩니다. 무슨 일이 일어나고 있는 걸까요? 이러한 프롬프트는 일반적으로 부팅 오류로 인해 발생합니다. 모두를 돕기 위해 편집자가 해결책을 제시했습니다. 컴퓨터 사용이 점점 더 대중화되고 컴퓨터 오류가 점점 더 흔해지고 있습니다. 아니요, 최근 일부 사용자에게 컴퓨터를 켤 때 검은색 화면이 나타나고 재부팅하고 적절한 부팅 장치를 선택하라는 메시지가 표시되어 컴퓨터 시스템을 시작할 수 없습니다. 보통. 무슨 일이야? 어떻게 해결하나요? 사용자는 혼란스러워하고 다음으로 편집자가 따릅니다.
nginx를 다시 시작하는 방법
Jul 27, 2023 pm 05:21 PM
nginx를 다시 시작하는 방법: 1. Linux에서 Nginx를 다시 시작하고 systemd를 사용하여 Nginx를 다시 시작하고 새 구성 변경 사항을 읽습니다. 2. Windows에서 Nginx를 다시 시작하면 구성 변경 사항이 적용됩니다. , 서버를 완전히 중지하고 시작하지 않고도 3. Mac에서 Nginx를 다시 시작합니다. 그러면 Nginx가 다시 시작되고 새로운 구성 변경 사항 등이 적용됩니다.
컴퓨터를 다시 시작하는 Python 스크립트
Sep 08, 2023 pm 05:21 PM
컴퓨터를 다시 시작하는 것은 문제 해결, 업데이트 설치 또는 시스템 변경 사항 적용을 위해 자주 수행하는 일반적인 작업입니다. 컴퓨터를 다시 시작하는 방법에는 여러 가지가 있지만 Python 스크립트를 사용하면 자동화와 편의성이 제공됩니다. 이 기사에서는 간단한 실행으로 컴퓨터를 다시 시작할 수 있는 Python 스크립트를 만드는 방법을 살펴보겠습니다. 먼저 컴퓨터를 다시 시작하는 것의 중요성과 이로 인해 얻을 수 있는 이점에 대해 논의하겠습니다. 그런 다음 Python 스크립트의 구현 세부 사항을 살펴보고 관련된 필수 모듈과 기능을 설명합니다. 이 기사 전체에서 명확한 이해를 돕기 위해 자세한 설명과 코드 조각을 제공할 것입니다. 컴퓨터 다시 시작의 중요성 컴퓨터를 다시 시작하는 것은 다음을 수행할 수 있는 기본적인 문제 해결 단계입니다.
유비소프트 주가는 실망스러운 스타워즈: 아웃로즈 출시 이후 10년 만에 최저치로 하락
Sep 07, 2024 am 06:30 AM
프랑스 비디오 게임 개발사 유비소프트(Ubisoft)의 주가는 목요일 사상 최저치를 기록했습니다. 주당 약 15.50유로의 가격으로 가치는 약 10% 하락했습니다. 그 결과 회사의 시가총액은 20억 유로 아래로 떨어졌습니다. ~ 안에
Linux에서 서비스를 다시 시작하는 올바른 방법은 무엇입니까?
Mar 15, 2024 am 09:09 AM
Linux에서 서비스를 다시 시작하는 올바른 방법은 무엇입니까? Linux 시스템을 사용하다 보면 서비스를 다시 시작해야 하는 상황이 자주 발생하지만, 서비스를 다시 시작할 때 서비스가 실제로 중지되지 않거나 시작되지 않는 등의 문제가 발생할 수도 있습니다. 따라서 서비스를 다시 시작하는 올바른 방법을 익히는 것이 매우 중요합니다. Linux에서는 일반적으로 systemctl 명령을 사용하여 시스템 서비스를 관리할 수 있습니다. systemctl 명령은 systemd 시스템 관리자의 일부입니다.
win10에서 비밀번호 입력 후 루프에서 다시 시작되는 문제 해결
Dec 29, 2023 pm 09:53 PM
실수로 잘못된 작업을 수행하거나 시스템 자체에 특정 오류가 있는 경우 비밀번호를 입력하고 계속 다시 시작한 후 데스크탑에 들어가지 못할 수 있습니다. 이때는 안전 모드에서 복구할 수 있습니다. 아래에서 구체적인 방법을 살펴보겠습니다. 암호를 입력한 후 Win10이 바탕 화면에 들어갈 수 없고 계속 다시 시작됩니다. 해결 방법 1. 먼저 키보드의 "Shift"를 길게 누르고 오른쪽 하단에 있는 전원 버튼을 클릭한 다음 복구 인터페이스가 나타날 때까지 컴퓨터를 다시 시작하도록 선택합니다. 그런 다음 "shift" 키를 놓습니다. 2. 오른쪽 하단에 전원 버튼이 없는 경우 컴퓨터 호스트의 전원 버튼을 사용할 수도 있지만 세 번 이상 연속으로 다시 시작해야 합니다. 3. 복구 인터페이스가 나타나면 "고급 복구 옵션 보기"를 클릭합니다. 4. "문제 해결"을 선택하십시오. 5
Windows 10 부팅 시 검은색 화면이 무한 회전하고 다시 시작되는 문제에 대한 해결 방법
Dec 26, 2023 pm 07:10 PM
win10 운영 체제를 설치한 후 일부 친구에게 검은 화면이 나타나고 시스템을 사용하는 동안 커서가 계속 원 모양으로 회전하는 경우 걱정하지 마십시오. 편집자는 이러한 상황이 당사 컴퓨터의 설정 때문일 수 있다고 생각합니다. 먼저 시스템의 고급 옵션에 들어가서 설정해야 할 해당 옵션을 찾아 설정하면 됩니다. 특정 단계에서 편집자가 무엇을 했는지 살펴보겠습니다~ win10이 무한한 검은색 화면으로 시작되고 다시 시작하기 전에 원을 그리며 회전하는 경우 어떻게 해야 할까요? 방법 1: 1. 하드 종료를 세 번(10초 동안 강제로 누르기) ) 시스템이 자동으로 복구되고 아래와 같은 인터페이스가 나타납니다. 2. 문제 해결 중심점 - "고급 옵션" 3. 고급 옵션에서 "시작 설정"을 클릭합니다. 4. "다시 시작" 버튼을 클릭합니다. 5. 이때 컴퓨터가 다시 시작됩니다.
