乐趣区

关于mysql:故障分析-Federated-存储引擎表导致监控线程处于-Opening-table-状态

作者:李鹏博

爱可生 DBA 团队成员,次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着,为客户负责。

本文起源:原创投稿

* 爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。

最近发现客户的一台 MySQL 5.7.32 实例的监控线程状态始终处于 Opening table 状态,且都是在对 information_schema.tables 表做相干查问,如图:

通过 show open tables ; 语句发现 opened tables 并不算太多:

相干参数也没有太大的不合理性:

尽管 ulimit 设置不是很大,然而也不会对此产生什么影响

查看 MySQL Error 日志也没有发现与此相关的异样。

因而只能应用 pstack 工具对 MySQL 打堆栈来进行剖析,堆栈日志如下:

通过剖析堆栈日志发现,问题呈现在进行查问时会应用 Federated 存储引擎表对近程实例进行查问。

查看数据库应用 Federated 存储引擎的表,发现有两张表应用了 Federated 存储引擎:

通过在实例服务器上 Telnet Feferated 服务端的实例 IP 和端口发现是不通的:

所以揣测问题起因为:监控线程在查问 information_schema.tables 表时,当须要获取 Federated 存储引擎表的信息时须要连贯远端 Server,而因为网络或其余起因无奈连贯时,就会导致本地监控线程处于 Opening table 状态。

接下来设计试验验证咱们的想法:

  1. 启用 Federated 存储引擎

  1. 创立一张 Federated 存储引擎的表,连贯的 server 不存在

  1. 查问 information_schema.tables 表,线程卡住

  1. 线程状态处于 Opening table 状态

这刚好验证了咱们的想法是正确的。

退出移动版