FAQ系列 | 复制线程长时间Opening tables

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS MySQL,高可用系列 2核4GB
简介: FAQ系列 | 复制线程长时间Opening tables

0、导读

在slave上,发现SQL thread长时间处于Opening tables状态

1、问题描述

朋友的数据库,做了主从replication复制。在slave实例上,SQL thread的长时间处于Opening tables状态,复制进程异常。

mysql> show processlist;

+----+-------------+-----------+------+---------+-------+----------------------------------------+------------------+

| Id | User | Host | db | Command | Time | State | Info |

+----+-------------+-----------+------+---------+-------+----------------------------------------+------------------+

| 1 | system user | | NULL | Connect | 554 | Queueing master event to the relay log | NULL |

| 2 | system user | | NULL | Connect | 59212 | Opening tables | NULL |


整个实例大概20个database,总共300G左右。

master是5.5版本,slave是5.6版本,master上执行xtrabackup全库备份后搭建的slave。

2、原因分析

我的第一反应是table cache是不是太小了,导致open table比较慢,所以才长时间处于这个状态。无论如何,先一层层排查吧。

先看下slave status(部分无用信息我隐掉了):

mysql> show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Queueing master event to the relay log

Master_Log_File: master-bin.000618

Read_Master_Log_Pos: 614915856

Relay_Log_File: replicate.000008

Relay_Log_Pos: 2384117

Relay_Master_Log_File: master-bin.000617

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 252048331

Relay_Log_Space: 1438994074

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Seconds_Behind_Master: 59240

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: 1

Master_UUID:

Master_Info_File: /home/mysql/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Opening tables

Master_Retry_Count: 86400

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0


看不出来有什么异常的。

再看下系统负载情况:

[root@localhost mysql]# vmstat -S m 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 2 1 19591 458 230576 0 0 11 20 0 0 0 0 100 0 0

1 1 1 19587 458 230579 0 0 2032 2528 1645 584 1 1 93 4 0

1 1 1 19583 458 230582 0 0 1664 2712 1773 461 1 1 93 4 0

0 2 1 19578 458 230585 0 0 2080 3376 1810 660 1 1 93 4 0

2 0 1 19576 458 230587 0 0 2224 1804 1634 594 1 1 94 4 0

3 1 1 19569 458 230590 0 0 1968 3488 1693 566 1 1 93 4 0

1 1 1 19567 458 230593 0 0 2016 2632 1775 515 1 1 93 4 0

[root@localhost mysql]# sar -d 1

Linux 2.6.32-431.el6.x86_64 (localhost.localdomain) 03/21/2015 _x86_64_ (24 CPU)

03:21:57 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

03:21:58 PM dev8-0 185.86 5753.54 64.65 31.30 1.20 6.48 5.08 94.44

03:21:58 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

03:21:59 PM dev8-0 197.03 6114.85 95.05 31.52 1.16 5.88 4.48 88.32

03:21:59 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

03:22:00 PM dev8-0 188.89 5882.83 88.89 31.61 1.14 6.03 5.09 96.16

03:22:00 PM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

03:22:01 PM dev8-0 166.00 5152.00 80.00 31.52 1.42 8.56 5.58 92.70


也看不出来异常,继续看看mysql的日志吧:

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'objects_summary_global_by_type' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Incorrect definition of table performance_schema.rwlock_instances: expected column 'WRITE_LOCKED_BY_THREAD_ID' at position 2 to have type bigint(20), found type int(11).

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'setup_actors' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'setup_objects' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_io_waits_summary_by_index_usage' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_io_waits_summary_by_table' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'table_lock_waits_summary_by_table' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Column count of mysql.threads is wrong. Expected 14, found 3. Created with MySQL 50524, now running 50623. Please use mysql_upgrade to fix this error.

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_current' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_history' has the wrong structure

2015-04-21 14:51:04 18667 [ERROR] Native table 'performance_schema'.'events_stages_history_long' has the wrong structure

2015-04-21 15:05:17 7f5997fff700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.

2015-04-21 15:05:17 7f5997fff700 InnoDB: Error: Fetch of persistent statistics requested for table "db_anonymous_info_10"."t_friend_info_3" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

2015-04-21 15:05:17 7f7beb0cd700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found.

2015-04-21 15:05:17 7f7beb0cd700 InnoDB: Error: Fetch of persistent statistics requested for table "db_user_trade_1"."t_trade_15" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.


可以看到,这个实例中,P_S(performanc_schema)库的几个表结构都异常了。另外,mysql.innodb_table_stats表也异常了,导致InnoDB表数据收集异常,然后SQL thread也跟着异常了。

3、问题解决建议

造成上面问题主要原因是,没有用正确的方式来部署slave实例。从master上用xtrabackup物理备份到slave,启动实例后,应该再执行 mysql_upgrade 升级相关表结构,确保P_S(performanc_schema)、I_S(information_schema)以及 mysql 等几个系统库表结构都升级到最新版本。

            </div>
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
12月前
|
存储 人工智能 算法
数据结构实验之C 语言的函数数组指针结构体知识
本实验旨在复习C语言中的函数、数组、指针、结构体与共用体等核心概念,并通过具体编程任务加深理解。任务包括输出100以内所有素数、逆序排列一维数组、查找二维数组中的鞍点、利用指针输出二维数组元素,以及使用结构体和共用体处理教师与学生信息。每个任务不仅强化了基本语法的应用,还涉及到了算法逻辑的设计与优化。实验结果显示,学生能够有效掌握并运用这些知识完成指定任务。
232 4
|
存储 安全 数据安全/隐私保护
ERP系统的灾备与数据恢复:保障企业业务连续性
【7月更文挑战第29天】 ERP系统的灾备与数据恢复:保障企业业务连续性
611 2
|
9月前
|
人工智能 自然语言处理 运维
新员工培训全攻略:从战略解码到实战落地的深度拆解
当航天科工七〇六所通过InfoQ的“线上+线下混合式培训”将200名新员工的岗位胜任周期缩短40%,当某芯片巨头用“铸造成长·一苇可航”主题培训将企业文化转化率达78%,我们不得不思考:在AI重构生产关系的今天,如何让培训计划既承载战略意图,又点燃个体价值?
|
9月前
|
自然语言处理 Cloud Native Serverless
Q&A | 零门槛,即刻拥有DeepSeek-R1满血版
在博文发布后,博主醇青酱提出了关于DeepSeek-R1模型部署的问题。本文针对其疑问进行详细解答,并补充说明了其他三种方案同样支持DeepSeek-R1的部署,具体操作可参考官方文档。文中还提供了详细的命令行示例和图片指引,帮助用户更好地理解和部署模型。若还有其他问题,欢迎继续提问。 原文路径:[零门槛、百万token免费用,即刻拥有DeepSeek-R1满血版](https://developer.aliyun.com/article/1652705?spm=a2c6h.13046898.publish-article.4.220b6ffa53YMKA)
|
10月前
|
机器学习/深度学习 人工智能 自然语言处理
《解码AI大模型涌现能力:从量变到质变的智能跃迁》
人工智能大模型的涌现能力是当今科技的焦点。其产生依赖于四大关键因素:1) 海量数据提供丰富的训练素材,涵盖多样化的文本和图像;2) 强大算力如GPU、TPU加速模型训练,突破性能瓶颈;3) 精妙架构如Transformer引入自注意力机制,提升语义理解;4) 过参数化与优化策略使模型不断进化,展现未曾预设的能力。这些因素协同作用,推动大模型在复杂任务中表现出色,为未来带来更多可能。
541 11
|
机器学习/深度学习 人工智能 搜索推荐
人工智能在医疗领域的伦理困境与未来展望
【8月更文挑战第10天】本文深入探讨了人工智能技术在医疗领域应用中所面临的伦理挑战,并展望了其未来的发展趋势。通过分析AI在提高诊断准确性、个性化治疗和药物研发等方面的积极作用,同时指出了数据隐私、责任归属和机器偏见等伦理问题,文章旨在促进对AI技术在医疗领域应用的全面理解和审慎态度。
|
机器人
AC/DC电源模块的工作原理、特点和应用
AC/DC电源模块的工作原理、特点和应用。
AC/DC电源模块的工作原理、特点和应用
|
存储 SQL 分布式计算
MaxCompute 在大规模数据仓库中的应用
【8月更文第31天】随着大数据时代的到来,企业面临着海量数据的存储、处理和分析挑战。传统的数据仓库解决方案在面对PB级甚至EB级的数据规模时,往往显得力不从心。阿里云的 MaxCompute(原名 ODPS)是一个专为大规模数据处理设计的服务平台,它提供了强大的数据存储和计算能力,非常适合构建和管理大型数据仓库。本文将探讨 MaxCompute 在大规模数据仓库中的应用,并展示其相对于传统数据仓库的优势。
379 0