从库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ヘンタイを無料で生成します。
人気の記事
ホットツール
メモ帳++7.3.1
使いやすく無料のコードエディター
SublimeText3 中国語版
中国語版、とても使いやすい
ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境
ドリームウィーバー CS6
ビジュアル Web 開発ツール
SublimeText3 Mac版
神レベルのコード編集ソフト（SublimeText3）
ホットトピック
7486
15
1377
52
77
11
19
38
Samsung s24Ultra電話を再起動するにはどうすればよいですか?
Feb 09, 2024 pm 09:54 PM
Samsung S24 Ultra 携帯電話を使用しているときに、問題が発生したり、デバイスをリセットする必要が生じることがあります。この場合、電話機を再起動するのが一般的な解決策です。ただし、手順をよく知らないと混乱する可能性があります。ただし、心配しないでください。Samsung S24 Ultra 携帯電話を適切に再起動する方法を説明します。 Samsung s24 Ultra を再起動する方法 1. コントロール メニューを表示してシャットダウンします。Samsung 画面の上部から下にスライドしてショートカット ツール メニューを表示し、電源アイコン (円弧と垂直線の組み合わせ) をクリックして表示します。シャットダウンと再起動の選択インターフェイスを表示し、[再起動] をクリックします。 2. キーの組み合わせを使用してシャットダウンします。音量キーと電源キーを長押しして、シャットダウンと再起動の選択メニューを表示し、クリックしてシャットダウンを選択します。長押しすると
コンピューターのプロンプト「再起動して適切な起動デバイスを選択してください」を解決する方法
Jan 15, 2024 pm 02:00 PM
システムの再インストールは確実な解決策ではないかもしれませんが、再インストール後、コンピュータの電源を入れると、黒の背景に白のテキストが表示され、次のプロンプトが表示されることがわかりました。「rebootandselectproperbootdevice、何が起こっていますか?」このようなプロンプトは通常、ブート エラーによって発生します。皆さんを助けるために、編集者が解決策を提案しました。コンピュータの使用がますます一般的になり、コンピュータの故障がますます一般的になってきています。いいえ、最近、一部のユーザーがコンピュータの電源を入れるときに黒い画面に遭遇し、再起動と適切なブート デバイスの選択を求められ、コンピュータ システムが起動できなくなりました。通常は。どうしたの？どうやって解決すればいいでしょうか？ユーザーは混乱しています。次に編集者がフォローします
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 スクリプトの実装の詳細を詳しく調べ、必要なモジュールと関連する機能について説明します。この記事では、明確な理解を確実にするために、詳細な説明とコード スニペットを提供します。コンピュータを再起動することの重要性 コンピュータを再起動することは、次のことを可能にする基本的なトラブルシューティング手順です。
『Star Wars: Outlaws』の期待はずれの発売を受け、ユービーアイソフトの株価は10年ぶりの安値に下落
Sep 07, 2024 am 06:30 AM
フランスのビデオゲーム開発会社ユービーアイソフトの株価は木曜日、過去最低値に達した。 1株当たりの価格は約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 回以上再起動する必要があります。 3. 修復インターフェイスが表示されたら、[詳細な修復オプションを表示] をクリックします。 4. 「トラブルシューティング」を選択します。 5
Linux システムにおける一般的なシステムクラッシュと自動再起動の問題とその解決策
Jun 29, 2023 pm 01:28 PM
Linux システムは、安定した効率的なオペレーティング システムとして、サーバー、組み込みデバイス、その他の分野で広く使用されています。それでも、依然としてシステムクラッシュや自動再起動に悩まされています。この記事では、システムのクラッシュと自動再起動に関する一般的な問題について説明し、解決策を示します。 1. システムクラッシュの問題 メモリの問題: Linux システムでは、過剰なメモリ使用量によりシステムがクラッシュする可能性があります。解決策には、コードの最適化、不要なメモリの解放、物理メモリ容量の増加などが含まれます。ソフトウェアの競合: Linux システムでは、異なるソフトウェアの組み合わせが発生します。
