【MySQL】错误信息写入slave_relay_log.index 案例一则

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
日志服务 SLS,月写入数据量 50GB 1个月
云数据库 RDS MySQL,高可用系列 2核4GB
简介:
第一次遇到MySQL 将错误信息写入 slave-relay-log.index 中,slave io thread 启动成功,而sql thread 失败的案例,记录下来。
【现象】

生产环境突然报警,slave sql进程停止,登陆服务器检查,master-error.log 包含如下信息:


#tail -f /home/mysql/data3008/mysql/master-error.log
 
140507 20:59:29 [ERROR] log 10:44:23 UTC - mysqld got signal 11 ; listed in the index, but failed to stat

140507 20:59:29 [ERROR] Error counting relay log space

140507 21:04:29 [ERROR] log 10:44:23 UTC - mysqld got signal 11 ; listed in the index, but failed to stat

140507 21:04:29 [ERROR] Error counting relay log space

140507 21:09:29 [ERROR] log 10:44:23 UTC - mysqld got signal 11 ; listed in the index, but failed to stat

140507 21:09:29 [ERROR] Error counting relay log space

140507 21:14:29 [ERROR] log 10:44:23 UTC - mysqld got signal 11 ; listed in the index, but failed to stat

140507 21:14:29 [ERROR] Error counting relay log space

140507 21:15:29 [ERROR] log 10:44:23 UTC - mysqld got signal 11 ; listed in the index, but failed to stat

140507 21:15:29 [ERROR] Error counting relay log space 

关于 mysqld got signal 11 的错误案例 请见 mysqld got signal 11 案例一则  ,这里遇到Error counting relay log space 报错,于是检查 slave-relay-log.index 文件


#more slave-relay-log.index
 
/home/mysql/data3008/mysql/slave-relay.023481

/home/mysql/data3008/mysql/slave-relay.023482

10:44:23 UTC - mysqld got signal 11 ;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also beay fail.

key_buffer_size=16777216

read_buffer_size=262144

max_used_connections=10

max_threads=230

thread_count=8

connection_count=7

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 136546 K bytes of memory

Hope that's ok; if not, decrease some variables in the equation. 
Thread pointer: 0x5580000

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

stack_bottom = 2b74017d3e58 thread_stack 0x40000

/u01/mysql/bin/mysqld(my_print_stacktrace+0x29) [0x903c24]

/u01/mysql/bin/mysqld(handle_fatal_signal+0x3f6) [0x703916]

/lib64/libpthread.so.0() [0x313f80f4a0]

/u01/mysql/bin/mysqld(Query_cache::free_memory_block(Query_cache_block*)+0x58) [0x73c5e0]

/u01/mysql/bin/mysqld(Query_cache::free_query_internal(Query_cache_block*)+0x164) [0x73ca8a]

/u01/mysql/bin/mysqld() [0x73db00]

/u01/mysql/bin/mysqld(query_cache_insert(st_net*, char const*, unsigned long)+0x1e7) [0x740b2b]

/u01/mysql/bin/mysqld(net_real_write+0x39) [0x5e2531]

/u01/mysql/bin/mysqld() [0x5e29a3]

/u01/mysql/bin/mysqld(my_net_write+0xda) [0x5e2f91]

/u01/mysql/bin/mysqld(Protocol::write()+0x1e) [0x5e4192]

/u01/mysql/bin/mysqld(select_send::send_data(List&)+0x17c) [0x5dd204]

/u01/mysql/bin/mysqld() [0x652f13]

/u01/mysql/bin/mysqld() [0x654a73]

/u01/mysql/bin/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x81) [0x65a2c3]

/u01/mysql/bin/mysqld() [0x65f5ed]

/u01/mysql/bin/mysqld(JOIN::exec()+0x466) [0x675e58]

/u01/mysql/bin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long lon

g, select_result*, st_select_lex_unit*, st_select_lex*)+0x700) [0x671ff7]

/u01/mysql/bin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x18b) [0x677f22]

/u01/mysql/bin/mysqld() [0x601685]

/u01/mysql/bin/mysqld(mysql_execute_command(THD*)+0x18ee) [0x6066a4]

/u01/mysql/bin/mysqld(mysql_parse(THD*, char*, unsigned int, char const**)+0x419) [0x60a81c]

/u01/mysql/bin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xe94) [0x60b6c5]

/u01/mysql/bin/mysqld(do_command(THD*)+0x107) [0x60c16c]

/u01/mysql/bin/mysqld(handle_one_connection+0x237) [0x5fe1de]

/lib64/libpthread.so.0() [0x313f8077f1]

/lib64/libc.so.6(clone+0x6d) [0x313f4e570d] 

由于MySQL slave 在启动时需要检查relay log index 文件中的relay log信息,并进行applay到本地,由于该文件包含无误信息导致MySQL无法识别读取不到relay log ,sql thread 启动报错。
【解决】
检查 发现错误信息写入relay-log.index文件中,清理slave-relay-log.index 中的异常信息,MySQL 会自动将slave sql thread起来 ,除非刚刚开始问题定位不准导致误判。   
(none)@3008 21:24:19>
(none)@3008 21:24:51>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
               .........
              Master_Log_File: mysql-bin.001221
          Read_Master_Log_Pos: 319331681
               Relay_Log_File: slave-relay.023504
                Relay_Log_Pos: 319331826
        Relay_Master_Log_File: mysql-bin.001221
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             .....
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)
【疑问】
什么导致MySQL 将错误日志写入relay_log.index 中的?


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
2月前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器,操作系统为windows server。服务器上部署mysql单实例,innodb引擎,独立表空间。未进行数据库备份,未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句,导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份,也未开启binlog日志,无法直接还原数据库。
|
2月前
|
SQL 运维 关系型数据库
深入探讨MySQL的二进制日志(binlog)选项
总结而言,对MySQL binlogs深度理解并妥善配置对数据库运维管理至关重要;它不仅关系到系统性能优化也是实现高可靠性架构设计必须考虑因素之一。通过精心规划与周密部署可以使得该机能充分发挥作用而避免潜在风险带来影响。
121 6
|
3月前
|
存储 关系型数据库 MySQL
使用命令行cmd查询MySQL表结构信息技巧分享。
掌握了这些命令和技巧,您就能快速并有效地从命令行中查询MySQL表的结构信息,进而支持数据库维护、架构审查和优化等工作。
373 9
|
8月前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
644 90
|
6月前
|
SQL 监控 关系型数据库
MySQL日志分析:binlog、redolog、undolog三大日志的深度探讨。
数据库管理其实和写小说一样,需要规划,需要修订,也需要有能力回滚。理解这些日志的作用与优化,就像把握写作工具的使用与运用,为我们的数据库保驾护航。
285 23
|
7月前
|
存储 监控 API
【Azure App Service】分享使用Python Code获取App Service的服务器日志记录管理配置信息
本文介绍了如何通过Python代码获取App Service中“Web服务器日志记录”的配置状态。借助`azure-mgmt-web` SDK,可通过初始化`WebSiteManagementClient`对象、调用`get_configuration`方法来查看`http_logging_enabled`的值,从而判断日志记录是否启用及存储方式(关闭、存储或文件系统)。示例代码详细展示了实现步骤,并附有执行结果与官方文档参考链接,帮助开发者快速定位和解决问题。
228 22
|
7月前
|
关系型数据库 MySQL 大数据
大数据新视界--大数据大厂之MySQL 数据库课程设计:MySQL 数据库 SQL 语句调优的进阶策略与实际案例(2-2)
本文延续前篇,深入探讨 MySQL 数据库 SQL 语句调优进阶策略。包括优化索引使用,介绍多种索引类型及避免索引失效等;调整数据库参数,如缓冲池、连接数和日志参数;还有分区表、垂直拆分等其他优化方法。通过实际案例分析展示调优效果。回顾与数据库课程设计相关文章,强调全面认识 MySQL 数据库重要性。为读者提供综合调优指导,确保数据库高效运行。
|
7月前
|
SQL 运维 关系型数据库
MySQL Binlog 日志查看方法及查看内容解析
本文介绍了 MySQL 的 Binlog(二进制日志)功能及其使用方法。Binlog 记录了数据库的所有数据变更操作,如 INSERT、UPDATE 和 DELETE,对数据恢复、主从复制和审计至关重要。文章详细说明了如何开启 Binlog 功能、查看当前日志文件及内容,并解析了常见的事件类型,包括 Format_desc、Query、Table_map、Write_rows、Update_rows 和 Delete_rows 等,帮助用户掌握数据库变化历史,提升维护和排障能力。
|
9月前
|
关系型数据库 MySQL 数据库
图解MySQL【日志】——两阶段提交
两阶段提交是为了解决Redo Log和Binlog日志在事务提交时可能出现的半成功状态,确保两者的一致性。它分为准备阶段和提交阶段,通过协调者和参与者协作完成。准备阶段中,协调者向所有参与者发送准备请求,参与者执行事务并回复是否同意提交;提交阶段中,若所有参与者同意,则协调者发送提交请求,否则发送回滚请求。MySQL通过这种方式保证了分布式事务的一致性,并引入组提交机制减少磁盘I/O次数,提升性能。
673 4
图解MySQL【日志】——两阶段提交
|
8月前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
210 16

热门文章

最新文章

推荐镜像

更多