错误 2013 (HY000):仅查询一个表期间与 MySQL 服务器的连接丢失

ERROR 2013 (HY000): Lost connection to MySQL server during query for one table only

提问人:Majte 提问时间:10/1/2023 最后编辑:Majte 更新时间:10/1/2023 访问量:165

问:

几个月来一直在 Almalinux 上运行 Mysql,没有任何问题。在使用 Workbench 进行远程查询期间,表的重要更新失败。在那之后,我只盯着这张表得到这个错误。

错误 2013 (HY000):在查询期间丢失与 MySQL 服务器的连接 否 连接。正在尝试重新连接...

错误 2002 (HY000):无法通过套接字连接到本地 MySQL 服务器 '/var/lib/mysql/mysql.sock' (111)

错误:无法连接到服务器

远程访问表和通过服务器上的 localhost 以 root 身份登录时都会出现此错误。对于远程,错误略有不同:“错误代码:2013。在查询期间丢失了与MySQL服务器的连接”。

我只为这张表(user_mails)得到这个。任何其他表都可以正常工作,我可以读取、访问、更新等。我可以创建新表。它不是一个关键表。只是能够下降会有所帮助。

但要提供更多细节。我无法访问、读取、更改、重命名、转储或删除此表。因此,我什至无法转储或删除整个数据库。我猜是该表可能在远程更新期间已损坏。

换言之,套接字错误消息仅针对此表显示,而对于任何其他表都没有任何异常。因此,该错误似乎与我在互联网上找到的建议解决方案不同。我想知道这是否是套接字错误。

在我转储并备份了架构上的任何其他表后,我尝试了以下操作但没有成功:

  • 杀死了所有mysql进程。
  • 已从镜像站点替换该表的 ibd 文件。
  • 删除了袜子文件并重新启动了服务。
  • 编辑了 my.cfn 文件以将另一个文件夹用于 sock 文件,从 127.0.0.1 更改为 localhost 以及我踩到的其他编辑建议。

我现在已经备份了所有其他表。但是卸载并重新安装mysql是我想避免的最后手段。有什么想法吗?仅仅能够删除此架构可能就足够了,因为我可以使用备份。

请求的日志:

2023-10-01T13:50:46.465427Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.34) starting as process 30934
2023-10-01T13:50:46.478844Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-10-01T13:50:46.607584Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2023-10-01T13:50:46.782680Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2023-10-01T13:50:46.782712Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2023-10-01T13:50:46.799516Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.34'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.
/opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = short unsigned int; _Alloc = std::allocator<short unsigned int>; reference = short unsigned int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
2023-10-01T13:52:49Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=0b168807aaca44fa650560191d175e4fd878ff78
Thread pointer: 0x7f3d2c000fc0
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 = 7f3da4653c10 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x2131091]
/usr/sbin/mysqld(print_fatal_signal(int)+0x2a2) [0xfee7e2]
/usr/sbin/mysqld(handle_fatal_signal+0xa5) [0xfee995]
/lib64/libpthread.so.0(+0x12cf0) [0x7f3dab0cbcf0]
/lib64/libc.so.6(gsignal+0x10f) [0x7f3da947aacf]
/lib64/libc.so.6(abort+0x127) [0x7f3da944dea5]
/usr/sbin/mysqld() [0x2b6b800]
/usr/sbin/mysqld(dict_index_add_to_cache_w_vcol(dict_table_t*, dict_index_t*, dict_add_v_col_t const*, unsigned int, bool)+0x1c33) [0x245f773]
/usr/sbin/mysqld() [0x24637f3]
/usr/sbin/mysqld(dd_fill_dict_index(dd::Table const&, TABLE const*, dict_table_t*, THD*)+0x83) [0x2480d13]
/usr/sbin/mysqld(dict_table_t* dd_open_table_one<dd::Table>(dd::cache::Dictionary_client*, TABLE const*, char const*, dd::Table const*, THD*, std::deque<char const*, ut::allocator<char const*, ut::detail::allocator_base_pfs<char const*> > >&)+0x10d8) [0x2483d28]
/usr/sbin/mysqld(dict_table_t* dd_open_table<dd::Table>(dd::cache::Dictionary_client*, TABLE const*, char const*, dd::Table const*, THD*)+0x97) [0x2485597]
/usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int, dd::Table const*)+0x1464) [0x218ef34]
/usr/sbin/mysqld(handler::ha_open(TABLE*, char const*, int, int, dd::Table const*)+0x57) [0x10fb957]
/usr/sbin/mysqld(open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, dd::Table const*)+0x10e8) [0xf98f48]
/usr/sbin/mysqld(open_table(THD*, Table_ref*, Open_table_context*)+0x1029) [0xde4d39]
/usr/sbin/mysqld(open_tables(THD*, Table_ref**, unsigned int*, unsigned int, Prelocking_strategy*)+0x509) [0xde60e9]
/usr/sbin/mysqld(open_tables_for_query(THD*, Table_ref*, unsigned int)+0x91) [0xde74a1]
/usr/sbin/mysqld(Sql_cmd_dml::prepare(THD*)+0x105) [0xed7bc5]
/usr/sbin/mysqld(Sql_cmd_dml::execute(THD*)+0xfc) [0xee381c]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0xae7) [0xe7f677]
/usr/sbin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x51b) [0xe82e6b]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x2341) [0xe857a1]
/usr/sbin/mysqld(do_command(THD*)+0x15b) [0xe8631b]
/usr/sbin/mysqld() [0xfde9f8]
/usr/sbin/mysqld() [0x2844714]
/lib64/libpthread.so.0(+0x81ca) [0x7f3dab0c11ca]
/lib64/libc.so.6(clone+0x43) [0x7f3da9465e73]
MySQL 的Linux

评论

1赞 nbk 10/1/2023
按问题始终在错误日志中首先查找
0赞 Majte 10/1/2023
日志对我来说不是很有启发性。一切都很好,然后开始。“最有可能的是,你遇到了一个错误,但这个错误也可能是由硬件故障引起的。无法理解它。MySQL死了...一些打开open_table命令。最后一个是 /lib64/libc.so.6(clone+0x43) [0x7f3da9465e73]..”
0赞 nbk 10/1/2023
在前面的几行中一定是原因,请发布日志,有时很难阅读
0赞 Majte 10/1/2023
完成后,请参阅我原始帖子的编辑。我无法做出正面和反面。该表似乎只是损坏了,并且 scocket 错误是红鲱鱼,因为同一架构上的所有其他表都很好。
1赞 Majte 10/1/2023
我尝试了力恢复的建议。现在整个架构停止工作,我失去了对其中所有表的访问权限,并出现相同的错误。无论如何,非常感谢您的帮助。我现在将尝试 pysical 删除,如果没有,请重新安装所有内容。

答: 暂无答案