一:问题描述 今天收到邮件报警,遂进数据库查看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

MySQL索引基数对查询性能有显着影响:1.高基数索引能更有效地缩小数据范围,提高查询效率;2.低基数索引可能导致全表扫描,降低查询性能;3.在联合索引中,应将高基数列放在前面以优化查询。

MySQL学习路径包括基础知识、核心概念、使用示例和优化技巧。1)了解表、行、列、SQL查询等基础概念。2)学习MySQL的定义、工作原理和优势。3)掌握基本CRUD操作和高级用法,如索引和存储过程。4)熟悉常见错误调试和性能优化建议,如合理使用索引和优化查询。通过这些步骤,你将全面掌握MySQL的使用和优化。

MySQL在现实世界的应用包括基础数据库设计和复杂查询优化。1)基本用法:用于存储和管理用户数据,如插入、查询、更新和删除用户信息。2)高级用法:处理复杂业务逻辑,如电子商务平台的订单和库存管理。3)性能优化:通过合理使用索引、分区表和查询缓存来提升性能。

MySQL中的SQL命令可以分为DDL、DML、DQL、DCL等类别,用于创建、修改、删除数据库和表,插入、更新、删除数据,以及执行复杂的查询操作。1.基本用法包括CREATETABLE创建表、INSERTINTO插入数据和SELECT查询数据。2.高级用法涉及JOIN进行表联接、子查询和GROUPBY进行数据聚合。3.常见错误如语法错误、数据类型不匹配和权限问题可以通过语法检查、数据类型转换和权限管理来调试。4.性能优化建议包括使用索引、避免全表扫描、优化JOIN操作和使用事务来保证数据一致性

InnoDB通过undolog实现原子性,通过锁机制和MVCC实现一致性和隔离性,通过redolog实现持久性。1)原子性:使用undolog记录原始数据,确保事务可回滚。2)一致性:通过行级锁和MVCC确保数据一致。3)隔离性:支持多种隔离级别,默认使用REPEATABLEREAD。4)持久性:使用redolog记录修改,确保数据持久保存。

MySQL在数据库和编程中的地位非常重要,它是一个开源的关系型数据库管理系统,广泛应用于各种应用场景。1)MySQL提供高效的数据存储、组织和检索功能,支持Web、移动和企业级系统。2)它使用客户端-服务器架构,支持多种存储引擎和索引优化。3)基本用法包括创建表和插入数据,高级用法涉及多表JOIN和复杂查询。4)常见问题如SQL语法错误和性能问题可以通过EXPLAIN命令和慢查询日志调试。5)性能优化方法包括合理使用索引、优化查询和使用缓存,最佳实践包括使用事务和PreparedStatemen

MySQL适合小型和大型企业。1)小型企业可使用MySQL进行基本数据管理,如存储客户信息。2)大型企业可利用MySQL处理海量数据和复杂业务逻辑,优化查询性能和事务处理。

InnoDB通过Next-KeyLocking机制有效防止幻读。1)Next-KeyLocking结合行锁和间隙锁,锁定记录及其间隙,防止新记录插入。2)在实际应用中,通过优化查询和调整隔离级别,可以减少锁竞争,提高并发性能。


热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

Dreamweaver CS6
视觉化网页开发工具

螳螂BT
Mantis是一个易于部署的基于Web的缺陷跟踪工具,用于帮助产品缺陷跟踪。它需要PHP、MySQL和一个Web服务器。请查看我们的演示和托管服务。

DVWA
Damn Vulnerable Web App (DVWA) 是一个PHP/MySQL的Web应用程序,非常容易受到攻击。它的主要目标是成为安全专业人员在合法环境中测试自己的技能和工具的辅助工具,帮助Web开发人员更好地理解保护Web应用程序的过程,并帮助教师/学生在课堂环境中教授/学习Web应用程序安全。DVWA的目标是通过简单直接的界面练习一些最常见的Web漏洞,难度各不相同。请注意,该软件中

MinGW - 适用于 Windows 的极简 GNU
这个项目正在迁移到osdn.net/projects/mingw的过程中,你可以继续在那里关注我们。MinGW:GNU编译器集合(GCC)的本地Windows移植版本,可自由分发的导入库和用于构建本地Windows应用程序的头文件;包括对MSVC运行时的扩展,以支持C99功能。MinGW的所有软件都可以在64位Windows平台上运行。

SecLists
SecLists是最终安全测试人员的伙伴。它是一个包含各种类型列表的集合,这些列表在安全评估过程中经常使用,都在一个地方。SecLists通过方便地提供安全测试人员可能需要的所有列表,帮助提高安全测试的效率和生产力。列表类型包括用户名、密码、URL、模糊测试有效载荷、敏感数据模式、Web shell等等。测试人员只需将此存储库拉到新的测试机上,他就可以访问到所需的每种类型的列表。